Having Spec Leads informed makes sense,
I'm not sure, if they must officially join the EG, but at least using the
already present notion of "Observer" might help.
If you think some other role or way to participate for Spec Leads was
missing, please let me know, I'm more than happy to discuss with JSR 358
(EC) and PMO in Prague.
Werner
Am 31.08.2012 17:36 schrieb "Antonio Goncalves" <antonio.goncalves_at_gmail.com
>:
> <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>
>