With CDI Extensions, You Can Build Your Own Java 7

Five years down the road, when developers look back on Java EE 6, they'll realize that it introduced things to the Java platform that are just as important as the features that debuted Java EE 5 and 4.  They'll remember that it was the first version to add built-in extensibility.  Dan Allen, the author of "Seam in Action" and a Seam Community Liaison, gave an excellent presentation on CDI (Contexts and Dependency Injection, JSR-299), Weld (the CDI reference implementation), and Seam.  The presentation, available on slideshare with audio, dives deep into the functionality added by the EE 6 specs using real world examples (You should definitely check it out!).  DZone had an interview several months ago with the Weld project lead at JBoss, Pete Muir, about CDI extensions, and now Weld has released an alpha implementation of them.  

CDI's main goal is to enable the Web Tier (JSF) to communicate directly with the Transactional Tier (EJB) to simplify web programming in JavaEE.  The theme was to have loose coupling with strong typing.  For JEE components, CDI provides these services:

• Lifecycle management of stageful beans bound to well-defined contexts (including conversation context) - Where the class of an instance is stored and how it is managed is just as important as the instance itself.  A place to store the state is crucial in web applications.
• A type-safe approach to dependency injection - The spec extends the typing system by taking annotation and generic type parameters to form a composite type.  No XML, no field names.
• Interaction via an event notification facility - Developers can register lifecycle listeners and asked to be notified when events happen, such as start up/shut down, class processing, and bean creation.
• Reduced coupling between interceptors and beans
• Decorators, which intercept specific bean instances
• Unified EL (expression language) integration (bean names)

These features didn't feel as much like new frontiers, but instead they were really just badly needed functionality that Java EE had been missing.  There was no way of knowing, for example, whether an application was starting or ending, and there was no way of knowing what Beans there were in the application and what classes were being deployed as part of the application.

                                   

The last, and possibly the most exciting feature left in CDI is the SPI (service provider interface) for developing extensions to the JavaEE platform.  The Metadata has already added some powerful hooks into the JEE platform as a result of these extensions.  The idea behind extensions, Muir says, is that you can very easily write and add functionality (e.g. excel spreadsheet generation and security modules) that will run in any container that supports JSR-299.  Before Java EE 6, it was very difficult to build extensions to the built-in functionality.  During the deliberations within JEE Expert Groups, people wanted to implement things that were considered too cutting-edge.  Instead of forcing them to wait for Java 7, the concept of extensions to make the platform flexible and extensible.  

To build an extension, you implement an interface and then the container will look at your interface and use that as part of the platform itself.  At startup time you can add new functionality.  You could, for example, make the platform recognize new annotations that it never recognized before, modify the beans that are there, or add things to JNDI that weren't there before the application was deployed.  The best thing about these extensions is that they're portable to any JSR-299 -supporting architecture.  You can take the portable extension and add it to your application server,  or your application, and it's as if you're upgrading to Java 7, says Dan Allen, because you're adding new features to the platform.  The for the first time ever, the bare-bones Java EE architecture is now flexible, extensible, and portable.

Pete Muir says the inspiration for extensions came from JBoss' work on the Seam Framework.  Muir said the Seam security module could be a good example of an existing solution that could be added to Java EE through an extension.  This was a good example, he said, because the Java EE security module is powerful, but not easy to use - Seam security could make it easy though.  Vendors won't be the only parties who build extensions through JSR-299, Muir said.  Anybody can build an extension; it's not limited to just vendors.  You can add extra functionality to the Java EE platform or you can, in fact, replace quite a lot of the core functionality with something that you think is better.  That's a lot of new power for developers.

Weld currently has an alpha implementation of CDI extensions including an Injectable Logger and Managed Resource Streams.  Only resources can be loaded from the classpath currently, but JBoss will add support for loading resources from the servlet context soon.  This will greatly simplify using input streams.