After taking some time to go through various documents (see link list below) and do some coding samples about the topic CDI, the following things came into my mind:
"lots of annotations", "very abstract specification", "what role will CDI play in JavaEE within the next years?", "can become quite powerful", "I need some best practices".
The specification of CDI (CDI stands for Context and Dependency Injection) with its 92 pages is in my opinion not the right place to start if you want to learn CDI. It is an abstract specification, which shows all the elements a CDI capable container must implement. I really like the specification, but as the code samples didn't really help me (due to missing explanations), I think it is just not the best place to start.
Weld, the reference CDI implementation, offers a great documentation (see link below).
By the way, there are other implementations, too: Resin Candi and Apache Open Web Beans.
If you use Glassfish V3, Weld is included and if you develop using the WebProfile (see earlier post), Weld is even included.
But what is CDi all about? CDI offers..
- an improved lifecycle for stateful objects, bound to well-defined contexts
- a typesafe approach to dependency injection
- object interaction via an event notification facility
- a better approach to binding interceptors to objects, along with a new kind of interceptor, called a decorator, that is more appropriate for use in solving business problems
- an SPI for developing portable extensions to the container.
Gavin King mentioned in the interview:
Originally JSR 299 was called Web Beans, to emphasize its role in making the web technologies of Java EE 6 work better with the transactional access technologies. Originally, one of the key problems we wanted to solve was how can we build an application that uses JSF very easily together with technologies like EJB. So it was originally called Web Beans...It over‑emphasized that this was a web technology, when if you actually look at CDI, it's actually something much more general than that. So after much discussion, the name of the spec ended up being changed to “Context and Dependency Injection."
One of the main buzz words is (Managed) Bean. We have been using beans in Java a lot before. There are Enterprise Java Beans, Message Driven Beans or JSF managed beans. Now, in JavaEE 6 the word bean finally gets a well defined definition.
Managed Beans are defined as container managed objects which support a small set of basic services, such as resource injection, lifecycle callbacks and interceptors
With very few exceptions, almost every concrete Java class (also known as pojo) that has a constructor with no parameters (or a constructor designated with the annotation @Inject) is a bean. This includes every JavaBean and every EJB session bean.
To give you a short impression about what a Managed Bean can look like see my BeyonceBean :)
@Named
@SessionScoped
public class BeyonceBean implements Serializable {
@PrivateMusicLabel
@Inject
private Label label;
@Produces
@Named(value = "singBeyonce")
public String singBeyonce() {
return "Everywhere I am looking now, I am surrounded by your embrace...Halo Halo Halo";
}
public String getInjectedMusicLabelInfo() {
return label.toString();
}
}
If you want to learn CDI you should stick to the Weld Documentation provided by JBoss. There are many well described code samples. Maybe this code sample explains what first came into my mind: " lots of annotations" . I am sure it'll take some time to get used to this way of Java enterprise coding. With CDI you really focus on creating/using lots of annotations, either for type safety reasons, for interceptors or decorators.
UPDATE 01-23-2010
Reza Rahman, a Resin team member, provides some perfect articles for CDI beginners. I really like the way he explains the CDI features. So this link might be a perfect if you are new to CDI.
Another reflection I would like to share with you is my CDI experience with Netbeans 6.8 and Glassfish V3.
- If you don't annotate your Bean with @ManagedBean you don't get the JSF code completion feature. This is very inconvenient. But I am sure the Netbeans developers and community will provide a solution soon.
However, there is actually a more general problem with the @ManagedBeanAnnotation. The article Is @javax.faces.bean.ManagedBean Dead on Arrival?. describes that there are 3 different ways in JavaEE6 of how to define a ManagedBean in the source code: with JSR 316,250/JEE6Spec,AnnotationSpec javax.annotation.ManagedBean, with JSR 314/JSF2Spec javax.faces.bean.ManagedBean and with JSR299/CDISpec javax.inject.Named. So which one should we use? Use the @Named annotation!
- Then I had some problems with the Deploy on Save. When I changed the scope of the bean from request to session, I had to do a clean, otherwise I got a deployment error "Managed bean declaring a passivating scope must be passivation capable" -- which means must implement serializable (even though I added the Serializable interface).
I am going to take a closer look at this and see if there already are some open issues. Otherwise I will submit this problem.
My conclusion:
As I haven't figured out the full capacity of CDI and as it seems to have the power to change the way of writing Java EE applications essentially (or may even become the new JEE6 core programming model), I am very interested in CDI and I will continue reading about it.. As soon as ICEFaces 2.0 will be released I will update my training application from JavaEE5 to EE6 and focus on applying CDI features. As I will have to wait for at least another month I will keep an eye on how CDI is evolving.
Here are the links:
Specification - JCP 299 CDI
Weld documentation - JBOSS about CDI
Gavin King on CDI - tech discussion @ javalobby
CDI capable servers and deployment - see here
UPDATED 01-20-2010:
Java EE 6 Codecamp - Here you can do some CDI homework examples. A great way to learn Java EE.
Posts
