In Relation To

William Drai has blogged about his experience integrating Granite DS and CDI.

I've written a couple of posts about using @Alternative to achieve deployment-time polymorphism. What I've never really talked about is its role in CDI modularity.

This is just too cool. That's a test coverage report. It doesn't report coverage of the RI code by the TCK. It reports coverage of the CDI specification by the TCK.

The question of backward compatibility is something that all framework developers wrestle with. The term means different things to different people:

Today, Red Hat submitted the final draft of JSR-299[1], which now goes under the moniker CDI (Contexts and Dependency Injection), along with the Reference Implementation and TCK. Check out the spec[1] and Javadoc.

I just noticed that CDI makes it possible to write properties files in Java, instead of plain text. I'm not sure if this is useful, but it is cute.

I put a whole bunch of work into the Javadoc for CDI recently. You can see it here. There's a good overview of the spec in the package doc for javax.enterprise.inject.

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.

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:

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.