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

From: Antonio Goncalves <>
Date: Sun, 28 Oct 2012 10:21:52 +0100

Hi all,

I'm coming back to this topic which I would like to broad a bit to :
injecting context in general. At the moment we have to use @Resource to
inject different types of context and other tricks in Servlets or JAX-RS :

On a SAOP Web Service :

public class MyWS {

    private WebServiceContext context;

In an EJB :

public class MyEJB {

    private SessionContext context;

In a Servlet

public class MyServlet {

    private ServletContext context;

    protected void doGet(HttpServletRequest request, HttpServletResponse
response) {
        context = request.getContext();

REST Service
We've already talked about @Context

public class MyResource {
    private UriInfo info;

Wouldn't it be clearer to unify all these injections with @Inject ?


On Thu, Oct 11, 2012 at 5:18 AM, Yoon Kyung Koo <>wrote:

> Hi, all.
> Sorry for late feedback.
> I think CDI is more and more important feature of Java EE and should be
> aligned with annotations in other SPECs.
> Though there may be some backward compatibility issues, I prefer the
> option C.
> And I have some concerns in annotations and CDI with respect to deployment
> performance.
> I hope the annotation features can be more finely defined and can be
> scoped in view of the deployment performance in the future.
> --
> --------------------
> Software Innovation Evangelist
> Researcher & Executive Director / WAS Lab / TmaxSoft R&D Center
> 2012. 9. 21., 오후 3:56, Bill Shannon <> 작성:
> 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?

Antonio Goncalves
Software architect and Java Champion
Web site <> |
LinkedIn <> | Paris
JUG<> |
Devoxx France <>