Feature:

The JSF 2.0, CDI, JSR 299 Fiasco

There's a real annoying conflict that has happened between JSF and the broader, enterprise Java
community; I hate talking about it because it's just so darned frustrating and annoying, but you
can't really talk about JSF without dealing with the great, big, CDI elephant in the room.

When the big brains in the Java world put together the JSF 2.0 specification, they realized that
the use of crazy and bewildering XML files for managing configuration wasn't always the best way to
go, and as such, they introduced a variety of new annotations, such as @ManagedBean and
@SessionScoped, with which you could decorate your JavaBeans. These annotations would describe to
the JSF framework how to manage your beans at runtime, essentially placing the information that was
previously placed externally in a faces-config.xml file right there into the JavaBeans themselves.
Brilliant!

But here's the thing. As the JSF 2.0 specification was picking up some steam, a new specification,
JSR 299, a specification for managing JavaBeans and doing things such as dependency injection
arose, and frustratingly, much of the functionality we see in JSF annotations are duplicated by the
JSR 299 spec.

Now, one of the things about JSR 299 is that when a bean is decorated by the the CDI equivalent of
a ManagedBean annotation, (CDI uses the 'Named' annotation), the container as a whole manages the
bean, whereas with a JSF annotation, it is actually the JavaServer Faces framework itself, which is
running within the container, that manages the bean. As a result, a bean decorated with a CDI
annotation has a broader scope, being managed by the broader application server and all, as opposed
to simply being managed within the scope of the JSF application itself; for his reason, amongst
others, many developers are choosing to use CDI annotations instead of those defined in the JSF
spec.

The CDI specification also does quite a bit more than scooping and indicating a given bean should
have its lifecycle managed by the container, so there are other compelling reasons as to why CDI is
growing in popularity, but I don't think this is the time and place to go into that. The point I'm
trying to make is that in many JSF applications, you may see the use of CDI annotations instead of
the standard JSF ones.

In your own JSF applications, you can use the JSF annotations or the CDI annotations, and it really
won't make much of a difference. But if you are interested in using some JSR 299 stuff, you'll need
to know how to set it up. You see, CDI will be part of any Java EE 6 enterprise server, but if
you're just using a Servlet engine like Tomcat, you won't be able to get CDI annotations to work
out of the box. But there are a few easy fixes, one of them being to use the MyFaces CODI project,
while the other is to incorporate Weld, the standard implementation of the CDI specification, into
your web applications.

Any Java EE 6 container supports the Context and Dependency Injection specification, but Tomcat 7
and other standard servlet engines do not. For those who are interested, the following tutorial
shows you how you can set up Tomcat 7 to support CDI using Weld.

TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective purchase decisions and managing their organizations technology projects - with its network of technology-specific websites, events and online magazines.