Help

I just submitted the Proposed Final Draft of JSR-299, Contexts and Dependency Injection, to the JCP. Download it here[1]. We're gearing up for a final release in August, in time for the Java EE 6 release in September. Thanks to everyone who put so much effort into this!

If you have not being paying attention to 299, now is a great time to get up to date. This is arguably the most significant enhancement in EE 6, providing the following suite of functionality:

  • a completely general typesafe dependency injection model,
  • contextual lifecycle management for injectable objects,
  • an event notification model,
  • interceptor bindings via user-defined annotations,
  • typesafe decorators,
  • a complete SPI for integration of third-party web or component frameworks, and
  • integration with JSF, servlets and JSP, including
  • a conversation context for JSF

Best of all, this functionality is provided with a clean, simple, uniform programming model that emphasizes two primary values: typesafety, and loose coupling. JSR-299 doesn't use strings or XML to wire together beans, events, interceptors and decorators. Instead, it uses the Java type system and user defined binding annotations to discover the relationships between loosely coupled components.

Now is a good time to clear up some misconceptions I've seen floating about.

JSR-299 is just for EJBs

This isn't true at all.

Out of the box you can inject into just about any kind of thing in the Java EE environment, including servlets, servlet filters, servlet event listeners, JAX-WS web service endpoints and JAX-RS resources. Even better, there's an SPI so that any third-party framework (for example, a web framework like Wicket) can easily ask the 299 implementation to perform injection upon objects managed by the framework.

The kinds of objects you can inject include:

  • managed beans (plain Java classes),
  • local EJB session beans,
  • objects obtained from a producer method or producer field, and
  • Java EE component environment resources (datasources, connectors, persistence contexts, JMS message destinations, web services, remote EJBs, etc.)

In case you're trying to not believe me (you know who you are), here is a class that can be injected:

final class Head {}

Here's a class that uses injection:

final class Person {
    private Head head;

    @Initializer 
    Person(Head head) { 
        this.head=head; 
    }

}

There's also a simple SPI to allow third-party frameworks (including other container like Spring) to offer their own objects up for injection via the 299 container.

JSR-299 is tied to JSF

Also not true. In an EE 6 environment, JSR-299 comes pre-integrated with Java Servlets, JSP and JAX-RS, in addition to JSF. And 299 provides SPIs to enable integration with your favorite web framework. These SPIs make it easier than ever before to integrate third-party web frameworks with the rest of the EE environment.

JSR-299 is tied to heavyweight Java EE containers

Obviously, integration with the Java EE environment was an extremely high priority for the expert group, so you'll come across lots of information about Java EE integration when you read the specification. Certain functionality defined by JSR-299 is specific to certain other EE technologies. For example, if there's no EJB container, we can't inject EJBs! But this doesn't mean that JSR-299 is only available in a traditional Java EE container like JBoss or GlassFish.

Instead, 299 was designed to be suitable for inclusion in a variety of execution environments, for example:

  • Java EE 6 defines a web profile for servlet containers along the lines of Caucho Resin, JBoss Web Platform or SpringSource dm server that don't want to support the full set of legacy EE 5 technologies. It is proposed that the web profile will require support for JSR-299.
  • EJB 3.1 defines an embeddable container that runs in the Java SE environment. The embeddable container will also support JSR-299.

However, JSR-299 does not currently define a bootstrap API for starting and running the container standalone in the SE environment. Instead, this API is being defined by JSR-330. Unlike JSR-299, JSR-330 is not defining everything that is needed in order to write portable applications. So you'll still need JSR-299 if you want your application to be portable to other container implementations. Therefore, we plan a maintenance release of JSR-299 that includes support for the JSR-330 bootstrap API. For now, if you want to run JSR-299 in the SE environment, you'll need to use a vendor-specific bootstrap API.

JSR-299 uses a lot of annotations

We've been very careful to not require the use of many annotations in simple usecases. Let's take dependency injection as an example of this.

Almost any Java class may be injected by the container without the need for any annotation on the class. Most injection points require a single annotation to indicate to the container that injection should be performed. The container uses the Java type of the injection point to decide what object should be injected.

Then, in more complex cases where knowledge of the type system alone is not sufficient to unambiguously express a dependency, the container can use additional user-defined annotations to resolve the ambiguity. The good news is that the user-defined annotation usually expresses something meaningful in terms of the application business logic. They therefore improve code readability.

For example, this is neither typesafe, nor very readable:

@PersistenceContext(unitName="userDB") EntityManager em;

So in JSR-299, you can write this instead:

@UserDatabase EntityManager em;

A very similar model is followed for interceptor bindings and event observation, and for decorator bindings, which are just a special case of dependency injection.

32 comments:
11. Jun 2009, 07:24 CET | Link
Hernán Moreno | hmo.msg(AT)gmail.com

Congratulations, excellent work guys. 299 rocks ..really...

 
11. Jun 2009, 07:24 CET | Link
Jeremy Norris | jnorris(AT)pattern73.com

Thanks for all your hard work Gavin (and EG team), this spec is really looking great.

 
11. Jun 2009, 15:47 CET | Link
Benjamin

Great work! Hopefully JSR-299 integration into JEE6 won't suffer by delaying JSR-330 spec. Reading IBMs vote statement makes me doubt in keeping the timeline. :-( Please make me think wrong!

 
11. Jun 2009, 17:04 CET | Link

Woo hoo. Great work JSR-299 EG members :-)

 
11. Jun 2009, 17:28 CET | Link

Congratulations to the EG for bringing an unprecedented improvement to the Java world. JSR299 is an intelligent spec that extensively addresses real world issues, and will make our lives easier in the end. Thank you.

 
11. Jun 2009, 18:53 CET | Link
Drew Arrigoni

Are there going to be any dead-tree format books available to show how to use all of these new features for launch out of curiousity?

Looking really interesting.

 
11. Jun 2009, 21:48 CET | Link
Mark Little | mlittle(AT)redhat.com

Congratulations! A great contribution.

 
11. Jun 2009, 23:40 CET | Link
Erik Mattheis

What's the latest on the possibility of preemptively adopting the proposed JSR-330 annotations for injection? I don't understand exactly why the JSR-330 proponents didn't choose to work within the JSR-299 project, but it seems to me that a lot of it has to do with the EE stigma attached to JSR-299. I'm sure it's easier said than done, but perhaps formalizing javax.inject instead of javax.enterprise.inject might alleviate some of this?

 
12. Jun 2009, 01:37 CET | Link

What's the summary of changes between this final and the previous specification?

I'm not sure 330 will get anywhere without a reference implementation, TCK, and detailed specification. Are these forthcoming? Without these pieces, the JSR just seems like namespace pollution.

 
12. Jun 2009, 02:05 CET | Link
What's the latest on the possibility of preemptively adopting the proposed JSR-330 annotations for injection?

We're working on it. The current thinking is to deliver the set of annotations which are common between 330 and 299 in a rev of the Common Annotations for the Java Platform specification. Doing this would have very minimal impact upon 299, since the main differences between the annotations are their names, not their semantics.

It's something that Red Hat, Sun and Oracle are very strongly in favor of, and that I believe has the complete support of the 299 EG.

I'm sure it's easier said than done, but perhaps formalizing javax.inject instead of javax.enterprise.inject might alleviate some of this?

Yes, the package names are definitely not my first choice, but the EG did not end up having a lot of choice on this stuff.

 
12. Jun 2009, 02:18 CET | Link
What's the summary of changes between this final and the previous specification?

I listed most of the changes here. But, you're right, there have been a couple of more recent changes:

  • Removal of special JMS support which can instead be provided by a portable extension
  • Removal of the notion of activities from this release of the specification
  • Further revision of the extension SPI

Along with various other minor changes.

I'm not sure 330 will get anywhere without a reference implementation, TCK, and detailed specification. Are these forthcoming?

Of course. Have you read the JCP process document? This stuff is required as part of the final release, which we plan for August. The RI and TCK are being developed here.

 
12. Jun 2009, 02:25 CET | Link
Nik
Gavin King wrote on Jun 11, 2009 20:18:
Of course. Have you read the JCP process document? This stuff is required as part of the final release, which we plan for August. The RI and TCK are being developed here.

That would be for 299 and not 330 ;-)

The 330 RI/TCK will have to be rushed through in order to make August. And even when rushed, I think the timeline is...interesting

 
12. Jun 2009, 02:43 CET | Link
That would be for 299 and not 330 ;-)

Oh, apologies, I misread. No, of course August timeline is for 299.

The 330 RI/TCK will have to be rushed through in order to make August.

Right, that's certainly not the plan for 330.

That's why we're trying to establish the shared annotations in the Common Annotations spec.

12. Jun 2009, 08:52 CET | Link
Hernan Moreno

Gavin, the Portable Extensions are really cool. What are you planning for the future? Can we expect XML configuration for Web beans? , or maybe as a module of Seam 3?.

12. Jun 2009, 11:28 CET | Link
Gavin, the Portable Extensions are really cool. What are you planning for the future? Can we expect XML configuration for Web beans? , or maybe as a module of Seam 3?.

We have a whole long list of portable extensions that we want to start work on the minute that 299 goes final. Some of that stuff - for example, Seam Security, or Seam i18n - will be branded as part of Seam3. But the plan is that the various bits of Seam3 won't be dependent upon each other and will be independently usable. Some other portable extensions, like the XML configuration facility, might get a slightly different branding if we think it makes more sense for them to be thought of as extensions to the core programming model of 299, rather than as part of the Seam framework.

12. Jun 2009, 19:00 CET | Link
Ryan de Laplante

Just to confirm... I will be able to use CDI features in JSF phase listeners, jsf converters, jsf validators, EL resolvers, servlet filters, servlet context listeners, etc.? I understand that CDI will work in plain servlets and JSF managed beans, but this other stuff is just as important and I have to jump through hoops to make Spring DI work in them.

I haven't looked at the RI yet, but please make sure there are plenty of examples of using it in a unit testing environment including work with EJB 3.1 for transaction support.

12. Jun 2009, 19:18 CET | Link
Ryan de Laplante wrote on Jun 12, 2009 13:00:
I haven't looked at the RI yet, but please make sure there are plenty of examples of using it in a unit testing environment including work with EJB 3.1 for transaction support.

They are on the roadmap - but better yet, why not join in, and write some :-)

 
12. Jun 2009, 19:42 CET | Link
Thats a great new for Seam lovers !

Waiting for this time since last few months
http://www.seamframework.org/Community/JSR299

Tons of congratulations for your and whole team's effort to bring JSR-299 to JEE world. I hope to find few good books/tutorials available on the same time :)

- Pragun.

13. Jun 2009, 00:19 CET | Link
Ryan de Laplante wrote on Jun 12, 2009 13:00:
Just to confirm... I will be able to use CDI features in JSF phase listeners, jsf converters, jsf validators, EL resolvers, servlet filters, servlet context listeners, etc.? I understand that CDI will work in plain servlets and JSF managed beans, but this other stuff is just as important and I have to jump through hoops to make Spring DI work in them.

Servlets, servlet filters, servlet context listeners and JSF managed beans are Java EE component classes supporting injection according to the Java EE spec, so yes, you can inject into them.

JSF phase listeners, converters and validators are not Java EE component classes supporting injection, so you can't inject into them directly. You can obtain the BeanManager from JNDI instead.

Not sure what you mean by EL resolvers. JSR-299 requires that the container provide an ELResolver to JSF and JSP that resolves beans by their @Name.

 
13. Jun 2009, 02:15 CET | Link

Are there going to be strings attached to using EJB 3.1 in an SE versus pure EE environment? For example, will some annotations work in EE but not in SE?

 
13. Jun 2009, 02:47 CET | Link
Chris wrote on Jun 12, 2009 20:15:
Are there going to be strings attached to using EJB 3.1 in an SE versus pure EE environment? For example, will some annotations work in EE but not in SE?

The only functionality that is required by the spec for the SE environment is the EJB Lite subset. Of course, some containers may provide more than that.

13. Jun 2009, 12:17 CET | Link
Ryan de Laplante
Gavin King wrote on Jun 12, 2009 18:19:
Servlets, servlet filters, servlet context listeners and JSF managed beans are Java EE component classes supporting injection according to the Java EE spec, so yes, you can inject into them. JSF phase listeners, converters and validators are not Java EE component classes supporting injection, so you can't inject into them directly. You can obtain the BeanManager from JNDI instead. Not sure what you mean by EL resolvers. JSR-299 requires that the container provide an ELResolver to JSF and JSP that resolves beans by their @Name.

Good to hear that servlet context listeners and filters will support DI, because they are not automatically supported by Spring.

I wrote a custom EL resolver for #{theme_messages['multi.language.key']} that loads the value from the resource bundle of the theme used by the current screen. It needed to use some Spring beans and since the EL resolver is not manage by Spring, I had to load Spring's WebApplicationContext from ServletContext.

I had to do the same kinds of tricks for JSF PhaseListeners, converts and validators and was really hoping for JCDI to directly support them. I really can't understand what makes a JSF MBean more Java EE managed component than validators, converters and phase listeners. MBeans are specific to JSF too. I think this is a loose end that must be fixed, no matter how easy using BeanManager might be.

I'm a bit surprised to read about XML configuration of beans being removed from the spec, because I thought that was the only way to create multiple instances of a class with different configuration/values so that you can inject these instances into other classes. I haven't fully wrapped my mind around JCDI's way of doing dependency injection (read only part of the spec a while back) and will have to give it another look soon. I am really looking forward to having the functionality of JSR 299 built into Java EE6, and am also happy to see that Java EE6 can stand on its own now without needing multiple addon frameworks to accomplish basic things easily.

14. Jun 2009, 00:51 CET | Link
I had to do the same kinds of tricks for JSF PhaseListeners, converts and validators and was really hoping for JCDI to directly support them.

Then you need to send that feedback to the EE group, since this is defined in the EE spec, not in 299.

I'm a bit surprised to read about XML configuration of beans being removed from the spec, because I thought that was the only way to create multiple instances of a class with different configuration/values so that you can inject these instances into other classes.

It's been replaced with an SPI so that XML configuration can be done in a portable extension.

 
16. Jun 2009, 07:45 CET | Link

Great work, this has cleared lot questions and it looks like webbeans are headed toward JEE 6. It has also resolved lot issues in the current JEE such as EJB enjection in web tier.

Great work.

17. Jun 2009, 01:39 CET | Link
Joe

Hi dear First of all , Congratulation for thin really great spec second, i have some questions about licensing actually my company have some allergy towards the LGPL which prohibited us from using the great seam product,and stick with spring, but now as i can see, webbeans is apache licensed so we r planning to use it in our very next product, so can u give an unformal statment about the future licensing plans for webbeans? will it remain Apatche 2 licensed? can i get(download) a certified apache licensed product , by that i mean a distribution which also contains EJB 3.1 lite container under the Apache license thanks Joe

17. Jun 2009, 02:15 CET | Link

The RI will remain under the Apache2 license. Note that there is also a 299 implementation in the works at apache.org.

17. Jun 2009, 11:19 CET | Link
Joe

Hi dear Thanks for your reply Does that mean it will contain an EJB 3.1 lite container, which as i understands necessary for it to pass the TCK , or it will rely on external container? in the last case ,what is the status of integration with GlassFish (CDDL is accepted by our legal team)? thanks and Congratulations again Joe

17. Jun 2009, 16:09 CET | Link

The JBoss EJB 3.1 lite container will be LGPL licensed, but other containers like Glassfish will provide a CDDL licensed EJB 3.1 lite container I think.

Sun is working hard on integrating Web Beans into GlassFish atm, and has made quite a lot of progress.

 
22. May 2010, 23:54 CET | Link

Thanks for this interesting coverage on JSR-299, its been very informative.. Thanks once again

 
04. Nov 2014, 18:57 CET | Link

Click HELP for text formattingGreat work, this has cleared lot questions and it looks like webbeans are headed toward JEE 6. It has also resolved lot issues in the current JEE such as EJB enjection in web tier instructions. Then edit this text and check the preview.

 
04. Nov 2014, 18:59 CET | Link

Thanks for this interesting coverage on JSR-299, its been very informative

 
04. Nov 2014, 18:59 CET | Link
taslek wrote on Nov 04, 2014 12:59:
Thanks for this interesting coverage on JSR-299, its been very informative

Click HELP for text formatting instructions. Then edit this text and check the preview.