A bit late but I'm also in favor of option D.
On Fri, Oct 5, 2012 at 8:35 AM, Deepak Anupalli <deepak_at_pramati.com> wrote:
> All or some of the options (A, B, C or D) would either lead to duplication
> of CDI functionality into the respective specs or could add to
> incompatibility across containers in understanding the (non) CDI dependency.
>
> CDI has lot of features which may not appeal to every other specification,
> if there is a way we can subset essential CDI features i.e., Injection,
> Interceptors & Stereotypes (CDI Lite), there shouldn't be so much
> resistance from other spec leads to embrace it. I'm not sure given the
> timeframe for Java EE 7 this would be possible.
>
> @Context existed before @Inject came into existence and definitely needs
> standardization.
>
> -Deepak
>
>
> On Fri, Aug 31, 2012 at 10:16 PM, Pete Muir <pmuir_at_bleepbleep.org.uk>wrote:
>
>> We can't *actually* get rid of @Context, as it's in JAX-RS 1.0.
>>
>> What (D) means, in our opinion, is that @Context should work in CDI/EJB
>> beans and could be implemented as a CDI extension. What we're more
>> concerned with is duplicating BeanManager, @RequestScoped and other
>> annotations, component/config injection, etc...
>>
>> On 31 Aug 2012, at 16:22, Antonio Goncalves wrote:
>>
>> > 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 ?
>> >
>> > 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_at_bleepbleep.org.uk>
>> 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_at_bleepbleep.org.uk>
>> 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
>>
>>
>