jsr342-experts@javaee-spec.java.net

[jsr342-experts] Re: CDI positioning

From: Markus Eisele <myfear_at_web.de>
Date: Fri, 21 Sep 2012 09:08:49 +0200

Hi all,

that somehow slipped through my unread-filter. Sorry. I need to find a
better way of tracking the "open" issues.
Any ideas to make this easier appreciated.

Anyway. Reading this over and thinking about this since some time now
I believe I prefer Pete's idea. (referred to as D)
We do have technologies which have a reach outside Java EE. There has
to be a chance for them to
decide if this is going to be a hard dependency or if they try to
duplicate stuff on their own.

The recent projects I have seen always facilitate CDI and it turns out
that _not_ having it enabled by default is error-prone. This is the
number one feature everybody knows about and is willing to use!

Bottom line: CDI should be mandatory for all JSRs contained the
umbrella. But they are free to provide alternative
implementations running standalone. I would love to think about
another requirement which could prevent unintended usage of the
standalone-alternatives.
What about defining kind of a container indicator which could be used for that?

- M

On 21 September 2012 08:56, Bill Shannon <bill.shannon_at_oracle.com> wrote:
> 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?
>>
>