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.
