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.
Hibernate Validator 4.0.1 is now available and can be downloaded from here. This release addresses issues discovered by the JCP integration efforts for JSR-303. Of course we used this opportunity to also fix some bugs identified by the community. Thanks for all the feedback.