Skip to main content

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

  • From: Markus Eisele <myfear@...>
  • To: jsr342-experts@...
  • Subject: [javaee-spec users] [jsr342-experts] Re: CDI positioning
  • Date: Fri, 21 Sep 2012 09:08:49 +0200
  • List-id: <jsr342-experts.javaee-spec.java.net>

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@...> 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?
>>
>


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

Werner Keil 09/01/2012

<Possible follow-up(s)>

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

Bill Shannon 09/21/2012

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

Markus Eisele 09/21/2012

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

Werner Keil 09/21/2012
 
 
Close
loading
Please Confirm
Close