I just got done presenting on JSR-299 at the SDC conference in Gotenborg, Sweden. Here's the latest slide set[1]!

The revised Public Review Draft of Contexts and Dependency Injection (JSR-299, the spec formerly known as Web Beans) was approved by the EC with all EC members voting Yes, except for Nortel and SpringSource who did not vote.

As expected, there were comments from several EC members:

IBM:

IBM has serious reservations about introducing another competing component model into the EE platform when this JSR was supposed to be focused on integrating technologies into the platform. Aside from the duplication and confusion caused by this, the specification has expanded to cover a large spectrum of technology that is somewhat ambitious to fully define within a single specification. However, we acknowledge that the spec lead has made substantial progress in addressing feedback and therefore, we are willing to vote yes to allow the specification to move forward on the assumption that the spec lead will continue to address feedback and concerns.

Oracle:

We believe this specification has the potential to augment the platform with useful functionality. However, we feel strongly that it must be properly and sufficiently integrated with the overall Java EE platform, specifically in the areas of XML definition, annotation usage, interceptors and events, and most particularly with respect to the perceived introduction of an additional component model. We therefore support the continuance of this specification on the conditions that the component model issues be resolved and that the integration of these aspects of the specification be completed. We appreciate Red Hat's ongoing work to address these issues with the community.

SAP:

There are a number of good concepts, but we are missing an overarching principle for a number of diverging goals that this JSR tries to address. In our opinion, Web Beans would be a great addition to the Java EE platform, in both capabilities and ease-of-use, but only if its ideas are better aligned and integrated into the existing Java EE world. We have communicated the details of our concerns to the Spec Lead. There is enough goodness that well justifies this JSR to proceed for now and we want to thank the Spec Lead for listening to our concerns.

I would like to thank everyone who worked on the Public Review Draft and everyone who has supported the specification in other ways. 299 has had a somewhat difficult ride, but it looks like we're moving toward a very satisfying outcome.

A revised public draft of JSR-299 is now available. This draft was produced with input from several people from the EE 6 expert group and aims to address a number of criticisms surrounding the relationship between 299 and the rest of the EE platform.

Terminology and name changes

The name of the spec - along with some terminology - has been changed to better reflect the fact that the focus of 299 is the definition of services that apply to all EE component types, rather than the creation of a new component model.

The new name of the specification is Java Contexts and Dependency Injection. The term web bean is no longer used in the specification.

Removal of pluggability contract

The concept of an independent web bean manager was removed from the specification. It is now assumed that the functionality defined by 299 is always provided by the Java EE or embeddable EJB Lite container. It is no longer possible to create a pluggable implementation of 299.

This helped resolve a number of problems with the specification and enabled a number of functional improvements.

Note that the Manager framework integration SPI still exists and it remains possible to integrate third-party frameworks with Java EE via 299.

Repackaging

The APIs defined by 299 have been broken down into the following packages:

• Scopes and contexts: javax.context
• Dependency injection service: javax.inject
• Framework integration SPI: javax.inject.manager
• Event notification service: javax.event

See appendix C for more information.

Injection of all Java EE resources types

It is now possible to inject Java EE resources, remote EJB references, web service references, persistence contexts and persistence units using typesafe 299-style injection. For example, we can inject a persistence context like this:

@UserDatabase EntityManager entityManager;

Where @UserDatabase is a binding type.

See section 3.6 of the specification for more information.

Asynchronous and distributed event notifications

Event observers may now receive event notifications asynchronously. See section 7.5.7.

Event types may now be mapped to JMS topics enabling state synchronization related events to propagate around a cluster or between application tiers. See section 7.8.

Clarification of metadata inheritance rules and generic bean realization

The rules for inheritance of metadata between beans is now well-defined in the brand new chapter 4. In addition, there is now a new notion of a framework-provided generic bean that provides a template for other beans which realize it in a certain system.

There are therefore two different special patterns of code reuse recognized by 299: specialization and realization.

The spec now features by far the most sophisticated annotation and XML based metadata reuse and overriding scheme ever devised. However, the rules, though somewhat complex to explain in specish language, are very usecase driven and should therefore seem quite transparent in practice.

In future (EE 7?), the metadata facility defined in 299 can be extended to encompass other metadata including EJB and JAX-RS metadata. I'm truly looking forward to the day we can deprecate the existing EJB deployment descriptor format.

Support for activities

It's now possible for a third-party framework, especially an orchestration engine, to register beans that apply only within the scope of a certain activity, for example, a workflow task, business process or web interaction. See section 11.6.

Injection point metadata

The introduction of the InjectionPoint interface enables certain special injection cases. See section 5.6 for more information.

Unification of interception APIs

Finally, I'm currently working with Ken Saks, the EJB 3.1 spec lead to produce a single document encapsulating and generalizing the interceptor functionality currently defined by EJB and the extensions that were defined by 299. To reflect this plan, the interceptor/decorator chapter has been moved to appendix A and will eventually be removed from the spec.

We may go through a similar process with the definition of simple bean in 299, but this is something that is still under discussion.

Conclusion

Muchisimas gracias to everyone involved in the production of this latest draft, and to everyone who was involved in the very difficult and complex negotiations surrounding the future of 299. I know everyone involved has felt frustrated at times, but the end result is a much better spec and a better EE 6 platform.