Hi all,
I think CDI is one of the base technologies for Java EE now and in the future.
If the spec is a part of Java EE, that should be designed based on CDI.
However, we had better keep existing feature that is similar to CDI
in consideration of standalone use and compatibility.
I think CDI is not mandatory in standalone environment.
Minehiko
> -----Original Message-----
> From: Bill Shannon [mailto:bill.shannon_at_oracle.com]
> Sent: Friday, September 21, 2012 3:56 PM
> To: jsr342-experts_at_javaee-spec.java.net
> Subject: [jsr342-experts] Re: CDI positioning
>
> I've heard from a few of you on this, but I'd like to get feedback
> from the rest of the expert group. There's 20 people on this
> expert group, surely you all joined the expert group because you had
> opinions about Java EE, right? You wanted to help us direct the
> future of Java EE. You wanted to give us the benefit of your experience.
> If you just wanted to watch, you could've joined the users list instead
> of the expert group...
>
> Let's hear it! What do you guys think?!?
>
> (If you already responded to this thread, please resist the temptation
> to jump in again. Let's let the others have their say.)
>
> Thanks.
>
>
> Bill Shannon wrote on 08/30/2012 01:58 PM:
> > From many of our recent discussions, it seems clear that CDI is
> > becoming more central to the Java EE programming model. For example:
> >
> > - The expanded use of @Stereotype in my previous message.
> >
> > - The use of CDI interceptors to provide container managed
> > transaction support beyond EJB.
> >
> > - The potential future use of CDI interceptors to provide container
> > managed security support beyond EJB.
> >
> > - The use of CDI interceptors to support Bean Validation method
> > level validation.
> >
> > - The discussion of "implicit producers" to allow use of @Inject
> > instead of @Resource to inject Java EE resources.
> >
> > - The discussion around alignment of CDI managed beans and the
> > separate @ManagedBean spec.
> >
> > - The introduction of a transaction scope and its use in the JMS
> > spec to simplify the programming model.
> >
> > - The change being considered by the CDI expert group to enable
> > CDI by default, making it more attractive to use it for all
> > the items above.
> >
> >
> > At the same time we're finding that some specs, e.g., JAX-RS, are
> > hesitant to introduce a hard, or even soft, dependency on CDI,
> > instead insisting that all their new features must work in an
> > environment where there is no CDI.
> >
> > In many ways this parallels what we saw with annotations. In
> > the beginning we found many people who didn't want to use annotations
> > and wanted us to make sure everything worked without use of
> > annotations. Now we're seeing many things that *only* work with
> > annotations, and annotations are well accepted by Java EE developers.
> > I suppose there's a natural lifecycle to acceptance of new
> > technologies, and I wonder where we are in that lifecycle with CDI?
> > Has CDI become a mature and accepted technology that we should use
> > widely?
> >
> >
> > I'd like to get a sense from this group as to what direction we
> > should provide to all the Java EE specs in regards to their use
> > of CDI. Here's a few obvious options:
> >
> > A. Technologies that see a significant standalone (non-Java EE) use
> > should be fully functional without CDI. If necessary, any
> > required features that are similar to CDI features should be
> > defined and implemented in a way that doesn't depend on CDI.
> >
> > B. Technologies should provide all major features in a way that
> > works without CDI. Some features may also be provided in a
> > different way that works well with CDI. Some less essential
> > features may only work with CDI. The implementation should
> > only have a soft dependency on CDI at most.
> >
> > C. Technologies should provide features that work well with CDI
> > without duplicating any functionality in CDI. Use CDI wherever
> > it fits. The implementation may have a hard dependency on CDI
> > and may require CDI even when used in a standalone environment.
> >
> > I'm sure you can think of other options as well.
> >
> > What advice do you think we should give to other Java EE specs?
> >