Mitch Pronschinske is a Senior Content Analyst at DZone. That means he writes and searches for the finest developer content in the land so that you don't have to. He often eats peanut butter and bananas, likes to make his own ringtones, enjoys card and board games, and is married to an underwear model. Mitch is a DZone Zone Leader and has posted 2573 posts at DZone. You can read more from them at their website. View Full User Profile

With CDI Extensions, You Can Build Your Own Java 7

05.18.2010
| 18042 views |
  • submit to reddit
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.

Comments

Dan Allen replied on Thu, 2010/05/20 - 2:25am

It's probably more accurate to say that you can build your own Java EE 7 using CDI.

On the other hand, we can only guess what innovative things people are going to do with CDI. It will be interesting to see how far they can stretch it, perhaps to the point where it's being used to contribute language features (the line may certainly blurred).

Btw, we encourage people who want to see examples of CDI extensions in practice to also check out Seam 3 (http://sfwk.org/Seam3). Weld extensions provide common utilities that extension writers need (logger, resource loading, class reloading), whereas Seam is a collection of modules for the application developer (security, JSF enhancements, deeper JMS integration, etc).

Dan Allen replied on Fri, 2010/05/21 - 4:50pm

Support for loading resources from the servlet context is now available in the Alpha2 release of Weld Extensions (org.jboss.weld:weld-extensions:1.0.0.Alpha2 in Maven central). Documentation is expected in Alpha3.

Rick Hightower replied on Wed, 2011/03/30 - 11:55am

This post was very inspiring by the way. I would love to see CDI blossom along with Java EE 6. I think they did an excellent job with the design an implementations of CDI. I hope CDI gets used inside and outside of Java EE 6.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.