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.
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
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.