<offTopic>
My point of view is that, to have a better integrated umbrella JSR (such as
EE), each sub spec-lead should be part of the umbrella EG (plus any
external welcome member)
</offTopic>
On Fri, Aug 31, 2012 at 5:30 PM, Werner Keil <werner.keil_at_gmail.com> 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_at_gmail.com>:
>
> 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 <http://www.antoniogoncalves.org> | Twitter<http://twitter.com/agoncal>|
>> LinkedIn <http://www.linkedin.com/in/agoncal> | Paris JUG<http://www.parisjug.org> |
>> Devoxx France <http://www.devoxx.fr>
>>
>
--
Antonio Goncalves
Software architect and Java Champion
Web site <http://www.antoniogoncalves.org> |
Twitter<http://twitter.com/agoncal>|
LinkedIn <http://www.linkedin.com/in/agoncal> | Paris
JUG<http://www.parisjug.org> |
Devoxx France <http://www.devoxx.fr>