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.


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.


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.

23. Jan 2009, 21:05 CET | Link

Wow! This is great news! I'm really looking forward to a finalized JSR 299.

23. Jan 2009, 21:23 CET | Link


23. Jan 2009, 21:54 CET | Link

Congratulations Gavin. It is great to see investment in putting the concepts introduced by Seam and Guice into a standard specification has paid off with this significant name change.


23. Jan 2009, 22:43 CET | Link
Ciro Cavani


I think this will be a very nice technology!


23. Jan 2009, 23:25 CET | Link

Thanks a lot!

I hope much more technologies and framework will adopt this great Semantic Java approach. It's shame there weren't annotations in Java from the beginning. I wish I could use @Public @Private @Protected or @Final annotations instead of modifiers to suite more the JSR 299 concept.

24. Jan 2009, 06:15 CET | Link


how soon the reference implementation would be available? or is the Seam/Guice that should be considered as RI ?

24. Jan 2009, 08:04 CET | Link

The RI is being developed here.

25. Jan 2009, 12:03 CET | Link

I just can't hold back my excitement. I really see a tremendously bright future for Java EE thanks to the innovative work done on this specification. Despite some grumbling early on about objections to the spec, those voices were heard and honestly the specification is better today because of the debates that took place. I'm with Gavin in that I'm really looking forward to Java EE 7 when these concepts can be leveraged in other areas of the platform. For those of you who were ready to give up on Java because it seems too old, I say that its best days certainly lie ahead.

Putting the technology aside for the moment, I've also been impressed by how open the 299 EG have been in developing this spec. The mailing list is publicly accessible, the RI is being developed as an open source project, and members of the EG, in particular Gavin, have used numerous other channels to communicate with the Java EE community regarding this spec, including interviews, the blog, and speaking at conferences. Perhaps as a role model, this spec can improve more than just the technology aspect of the platform.

26. Jan 2009, 05:52 CET | Link

There's a cross post on The Aquarium blog to this entry. The post also talks about the web profile and other updates with regard to the Java EE 6 platform.

27. Jan 2009, 01:25 CET | Link

Awesome! Can't wait to use this in a project.

Is there a demo out there on how to integrate the RI with jsf 2? That would be really helpful...

Thanks! Patrick

28. Jan 2009, 05:13 CET | Link

So interceptors will be defined in EJB specification?

28. Jan 2009, 22:36 CET | Link
Bill Burke wrote on Jan 27, 2009 23:13:
So interceptors will be defined in EJB specification?

In a standalone document.

29. Jan 2009, 20:39 CET | Link

Good work ... Looking really how to use it before adoption in Java EE 6. Can we have a sample of BusinessContext or BusinessProcessContext scoped implementation using the current Bean RI ? Thanks again.

04. Feb 2009, 12:39 CET | Link

Thanks for the update.

06. Feb 2009, 12:46 CET | Link

HI Gavin,

As you have mentioned in the blog, is it the chapter 4 is completely new in the latest version of JSR 299. How it can bring in more advantage? just curious to know more details from you.

20. Feb 2009, 01:34 CET | Link
Mike Wilson | mikewse(AT)
Where does one send comments on the spec?
Thanks / Mike
Post Comment