Skip to main content

[jsr342-experts] Re: CDI positioning

  • From: Antonio Goncalves <antonio.goncalves@...>
  • To: jsr342-experts@...
  • Subject: [jsr342-experts] Re: CDI positioning
  • Date: Fri, 31 Aug 2012 10:40:59 +0200

Hi all,

At my customers I've never seen a EE 6 application running without CDI, it really doesn't make sense. As you said, people where reluctant when annotations first came, and now they use it everywhere : same thing should happen with CDI. CDI should be enabled by default in EE 7 (even without a beans.xml file) and we should encourage the other specs to use it. I would even go further : javax.faces.bean.ManagedBean in JSF 2.2 should be deprecated as developers get confused with @Named. With CDI enabled by default, we could use more implicit producers : 

@Inject PersistenceContext em;
@Inject ConnectionFactory conn;
@Inject Queue q;
@Inject Principal loggedInUser

and who knows, one day, @Inject Logger log;

As for JAX-RS not willing to embrace CDI, I will try to sell (again) my idea of a minimal profile. I've talked about it many times in this mailing list, but what about creating a minimal profil with Servlet/JSP/EL and CDI ? That will maybe encourage web containers such as Tomcat, Jetty to implement this profile. This would also encourage people to use CDI. JAX-RS could then run on any "Minimal Profile" container out of the box with CDI enabled.

To summarize, CDI should become central to EE 7 and spread to the other specs (even dormant one such as JAX-WS)

My 2 cents
Antonio

On Thu, Aug 30, 2012 at 10:58 PM, Bill Shannon <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 | TwitterLinkedInParis JUG | Devoxx France


[jsr342-experts] CDI positioning

Bill Shannon 08/30/2012

[jsr342-experts] Re: CDI positioning

Werner Keil 08/30/2012

[jsr342-experts] Re: CDI positioning

Antonio Goncalves 08/31/2012

[jsr342-experts] Re: CDI positioning

Pete Muir 08/31/2012

[jsr342-experts] Re: CDI positioning

Antonio Goncalves 08/31/2012

[jsr342-experts] Re: CDI positioning

Pete Muir 08/31/2012

[jsr342-experts] Re: CDI positioning

Antonio Goncalves 08/31/2012

[jsr342-experts] Re: CDI positioning

Werner Keil 08/31/2012

[jsr342-experts] Re: CDI positioning

Antonio Goncalves 08/31/2012

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

Linda DeMichiel 08/31/2012

[jsr342-experts] Re: CDI positioning

Pete Muir 08/31/2012

[jsr342-experts] Re: CDI positioning

Pete Muir 08/31/2012
 
 
Close
loading
Please Confirm
Close