We've been busy with the JSR-299 specification (Contexts and Dependency Injection for Java EE) over the last couple of weeks, preparing to submit a Proposed Final Draft in early June. At this point I would like to solicit feedback from the community on the recent changes, so I'm posting a current revision of the specification[1] here.
Since the revised public draft, we've made the following changes:
- Removed the XML configuration format, since we would prefer to define a new, unified, XML deployment descriptor incorporating metadata for both EJB and CDI as part of a future JSR, and because the expert group was unable to achieve consensus upon the merits of the typesafe XML format.
- Significantly enhanced the SPIs that provide for integration of third-party frameworks, allowing portable extensions to define their own metadata facilities and integrate fully with the container initialization lifecycle. A portable extension might define an XML-based metadata format, or even Java-based configuration. Indeed, it would be possible to support Guice modules or Spring XML as portable extensions to CDI. See chapter 11.
- Added support for Java-based declaration of dependencies to Java EE component environment resources, persistence contexts, persistence units, remote EJBs and web services, and for Java-based declaration of JMS event mappings. Previously XML was required. See sections 3.6.1, 3.7.2 and 10.7.
- Required that all Java EE component classes supporting injection (as defined by the EE spec) support the typesafe dependency injection mechanism defined by CDI.
- Improved support for resolution of dependencies based upon parameterized types.
- Enhanced the Instance and Event APIs, and introduced the special @Any binding. See sections 5.5 and 10.4.
- Slightly changed the definition of @New. See section 3.11.
- Minimized constraints upon implementations, by separating the definition of the CDI services from the portable extension SPI.
- Updated the spec to refer to the new platform-level Managed Bean and Interceptors specifications.
JCDI is not just a set of annotations that lets you inject things. It's the key to an ecosystem that allows Java EE developers to easily wire together their Java EE components and services using portable code, framework developers to write portable extensions that integrate with the container, and deployers to reconfigure the system with minimal XML.
Meanwhile, the Web Beans team has made great progress on the RI and TCK and a usable release is already available.
Please send feedback on this new spec draft to jsr-299-comments@jcp.org. Enjoy!
UPDATE: I updated the draft to include the license agreement.
| Attachments: | ||||
|---|---|---|---|---|
|
JSR-299-19May.pdf (JSR-299-20090519.pdf, 534 KiB, application/pdf) |
Looking at Appendix B, is Conversation part of javax.enterprise.context.spi ?
Oops, that's an error, thanks. Should be javax.enterprise.context, of course.
please please,please try to consider the Java SE subset as a separate profile in this JSR ,this will help prevent DI comunity fragmentation
thanks a lot
Unfortunately our JSR is not written to allow us to address the SE usecase in the specification. And certain EC members strongly objected when we started trying to characterize this JSR as being . So that won't be possible in this rev of the spec.
On the other hand, Web Beans (the RI) will have excellent support for execution in Java SE.
I'm not sure if the SPI should be defined in the Spec at all (at least not at such a granularity level).
OpenWebBeans also has a SPI for modularisation but it is pretty different to yours!
While having common SPIs would make building vendor independent plugins easier, in praxis it's also a burden since it cannot be extended easily. So people will probably start to use native APIs instead and all the portability is gone...
LieGrue, strub
Right, which is precisely why this needs to be defined in the spec! The three current implementations each have SPIs to allow integration with the container initialization, but frameworks can't easily make use of these SPIs since they're totally proprietary.
Not , the word you're looking for is . A portable SPI is the key to bootstrapping an ecosystem of portable extensions. I want Seam3 to run on any appserver, without the kind of portability problems that have dogged frameworks that were built for Java EE in the past.
eh? The proposed SPI is very easy to extend to add support for vendor-specific functionality.
Since JSR 299 EDR, there are so many excellent and exciting changes.
Gavin, is there a way to see (textual) delta's in the spec? This would make tracking spec changes so much easier....
Unfortunately no, since the PDF is generated by docbook.
Hi Gavin,
you're talking about three current implementations. I only know WebBeans and OpenWebBeans. Which is third one?
Greets Benjamin
docbook actually makes it easier ;) http://www.sagehill.net/docbookxsl/Changebars.html
--max
Resin. In some ways that's the coolest of the three ;-)
There's some info on their blog.
A better link
JSR-299 is really exciting.
I understand the political issues behind this. However, features like 'decorator ordering' require external configuration. Will this be addressed in Java EE deployment descriptors. When will we be able to see how descriptors will support this feature ?
Yes. It's the bean-level configuration that's been removed. The level configuration stays in beans.xml.
Good news. Hope that we can get that in Java EE 6. I can't imagine how it couldn't be in Java EE 6, anyway.
JSR-299 is amazing: simple, yet powerful. Concepts and namings are very consistent and easy to remember. Extensibility is really impressive, with meta-annotations, and also SPIs. Decorators and also enhanced intercptors finally bring most important AOP features to the masses.
So, let me get this straight, with the removal of XML, the only mechanism for interpretable configuration is through the crap legacy EE 5 and earlier XML env-entry and such?
I don't understand what means.