Skip to main content

[jsr342-experts] Re: CDI positioning

  • From: Pete Muir <pmuir@...>
  • To: jsr342-experts@...
  • Subject: [jsr342-experts] Re: CDI positioning
  • Date: Fri, 31 Aug 2012 16:37:57 +0100


On 31 Aug 2012, at 16:30, Werner Keil wrote:

> Good points. Where those are part of existing active JSRs, there should be 
> coordination and guidance. I remember, EC Members including myself and some 
> from the EE6 EG like Mike Keith mediated between @Inject and CDI in the 
> first place.
> Chances are, we can find a few more such cross-EG experts here this time?;-)
> 
> I am also both in JSF and CDI, so that could help in those cases. JAX-RS I 
> so far mainly use as consumer in projects like Agorava. Where we also try 
> to leverage CDI the best way possible. As the Spec Lead I believe is 
> Oracle, too, there should be ways to reach them.
> 
> Werner
> 
> Am 31.08.2012 17:22 schrieb "Antonio Goncalves" <antonio.goncalves@...>:
> Well, that would be awesome, but is there anybody here who is part of 
> JAX-RS Expert Group and could tell us if it's doable or not ? 

:-) I'll ask Bill Burke, our JAX-RS EG rep.

> 
> Same, do we know what the JSF 2.2 EG plans to do with @ManagedBean vs 
> @Named ?
> 
> On Fri, Aug 31, 2012 at 5:10 PM, Pete Muir <pmuir@...> wrote:
> Well, I think based on D, injection is something that CDI provides, and 
> JAX-RS is fully functional without injection, so JAX-RS shouldn't provide 
> @Context at all as it duplicates functionality from CDI.
> 
> On 31 Aug 2012, at 16:06, Antonio Goncalves wrote:
> 
> > Pete, what would that mean for the following example ? This is the way 
> > you inject UriInfo with JAX-RS :
> >
> >
> > @Path(
> > "/resource"
> > )
> >
> > public
> >  class Resource {
> >
> > @Context
> >
> >
> > private UriInfo info;
> >
> >
> >
> >
> > Injection is made with @Context in a standalone mode without CDI. But in 
> > a Java EE container I would really like to use @Inject rather than 
> > @Context (so the code is not portable anymore without CDI) :
> >
> >
> > @Path(
> > "/resource"
> > )
> >
> > public
> >  class Resource {
> >
> > @Inject
> >
> >
> > private UriInfo info;
> >
> >
> > Antonio
> > On Fri, Aug 31, 2012 at 4:55 PM, Pete Muir <pmuir@...> wrote:
> > Bill, et al
> >
> > We would like to propose a slight variant on option C:
> >
> > D. Technologies that can be standalone specifications (JMS, JAX-RS) 
> > should be fully functional without CDI, but they should not duplicate any 
> > features of CDI.  When CDI is present, these technologies should leverage 
> > and integrate with CDI where appropriate.
> >
> > On 30 Aug 2012, at 21:58, Bill Shannon wrote:
> >
> > > 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?
> >
> >
> >
> >
> > --
> > Antonio Goncalves
> > Software architect and Java Champion
> >
> > Web site | Twitter | LinkedIn | Paris JUG | Devoxx France
> 
> 
> 
> 
> -- 
> Antonio Goncalves 
> Software architect and Java Champion
> 
> Web site | Twitter | LinkedIn | Paris JUG | Devoxx France



[jsr342-experts] CDI positioning

Bill Shannon 08/30/2012

[jsr342-experts] Re: CDI positioning

Werner Keil 08/30/2012

[jsr342-experts] Re: CDI positioning

Antonio Goncalves 08/31/2012

[jsr342-experts] Re: CDI positioning

Pete Muir 08/31/2012

[jsr342-experts] Re: CDI positioning

Antonio Goncalves 08/31/2012

[jsr342-experts] Re: CDI positioning

Pete Muir 08/31/2012

[jsr342-experts] Re: CDI positioning

Antonio Goncalves 08/31/2012

[jsr342-experts] Re: CDI positioning

Werner Keil 08/31/2012

[jsr342-experts] Re: CDI positioning

Antonio Goncalves 08/31/2012

[jsr342-experts] Re: [javaee-spec users] Re: CDI positioning

Linda DeMichiel 08/31/2012

[jsr342-experts] Re: CDI positioning

Pete Muir 08/31/2012

[jsr342-experts] Re: CDI positioning

Pete Muir 08/31/2012
 
 
Close
loading
Please Confirm
Close