In Relation To

One of the nicest features of CDI is the portable extension SPI. According to the spec:

In case you're like me, and you missed this when it was first published, check out Andy Schwartz's summary of what's new in JSF2. (Andy's one of the good guys on the JSF EG.) It's fun to compare the final product to my wishlist from back in '07. Oh, what innocent, carefree days...

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.

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: