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.

Oh, I also did the Javadoc for javax.interceptor, but that's not available anywhere yet.

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.

We define our properties in a class. Of course, since the properties are going to be deployment-specific, we should declare the class @Alternative. (Unless it holds the default values, I suppose.)

@Alternative 
class TestSettings {
   @Produces @Named String adminUser = "admin";
   @Produces @Named String adminPassword = "nimda";
   @Produces @Named int maxRetries = 100;
}

Now, we can inject these properties. Into fields:

@Inject @Named int maxRetries;

Or even into constructors or methods:

@Inject 
Connection(@Named("adminUser") String user, 
           @Named("adminPassword") String pass) { 
   ... 
}

To select the right settings class for a deployment, we list it in beans.xml:

<beans>
   <alternatives>
      <class>settings.TestSettings</class>
   </alternatives>
</beans>

You could even write a really simple portable extension that would weave in the necessary @Alternative, @Produces and @Named annotations to the following class:

@Properties 
class TestSettings {
   String adminUser = "admin";
   String adminPassword = "nimda";
   int maxRetries = 100;
}

(If you want to know how to do this, go read up on the ProcessAnnotatedType event that is part of the CDI portable extension SPI.)

Well, I suppose it would be more typesafe to create a Settings interface with getter methods for all the properties, and inject that. Still, for an accidental feature, this is kinda cool.

UPDATE: hrrrm ... this feature makes somewhat more sense, when you realize that TestSettings is also a perfect place to declare all your deployment specific resources.

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.

What I was really thinking about when I started working on Seam was state management in event driven architectures. How can you ensure that an event is processed with the correct set of state for the context(s) it carries with it? I wanted to get away from the awful front controller pattern, where some big stupid stateless method is responsible for coordinating everything involved in processing the event, from state retrieval and storage, to service location, to orchestration.

There were a couple of frameworks which were ahead of their time in this respect. The one that got me started was XWork, a dependency injection solution that was part of earlier versions of WebWork. That's why I was kind of excited when I saw the same ideas in JSF (setting aside many other problems with JSF 1.0).

It's also why I pushed back so hard when some people questioned the existence of the event notification facility in CDI. Though it appeared to some folks to be a kind of cute feature stuck on the side of a dependency injection container, that's not what it was to me at all. Indeed, the idea of event processing was right at the core of what we were trying to achieve in JSR-299.

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.

UPDATE: Steven has extended the tutorial to cover deployment to Tomcat.