In my previous little rant, I showed you how to use @Alternative and alternative stereotypes to easily change bean implementations based upon deployment scenario. But that's not the end of the story. There's two other things I would sometimes like to be able to change at deployment time:
Suppose we have an external resource, a database, let's say, that we want to be able to change depending upon the deployment environment. In CDI, we declare resources using a producer field declaration.
I'm trying really hard to emphasize to the community that CDI and Weld are not just a dependency injection solution. We did not come at this from the point of view of trying to solve dependency injection, or of trying to build a better Spring.
CDI (JSR-299) and Weld 1.0 are almost a reality. We've got word from Sun that CDI and the rest of Java EE 6 will be submitted to the JCP on November 9. I've spent the last few days filling out the Javadoc for the CDI API and SPI packages and making some last-minute cleanups to the spec. Meanwhile, Pete and the others are fixing bugs in the RI and TCK. This process has taken more than 3 years, and an incredible amount of pain, but we're now looking at one of the most well-reviewed JCP specifications ever.
Steven Boscarine has written a nice short tutorial on getting up and running with Weld and JSF on Jetty, using Maven. Note that there's a bit more boilerplate here than there would be in a Java EE environment, since integration of Weld in Jetty requires explicit configuration. Nevertheless, I think Steven does a good job of demonstrating that it's easy to get up and running with this stuff.