This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
I am posing this question because after quite a bit of reading, it seems to me that the only time CDI makes sense is if you absolutely will never ever port your JSF 2 app to a non-JEE container. I suppose in some cases this works, but it seems to me until a non-JEE container back ports CDI into their container (which would they ever?), using @ManageBean with the JSF 1.x scopes including ViewScope for ajax based JSF 2 apps, seems to be the best way to ensure your presentation layer will deploy on every container out there.
Is there a reason why you would want to use CDI in a JEE container over ManagedBean/Property? Do you gain anything extra by using CDI in the presentation layer in a JEE container? From what I've read I haven't found a good reason to use CDI other than if you are guaranteed never to deploy to a non-JEE container.
In the specification JSR #344 it already make clear that JSF API that is like CDI API will be removed in next version (2.3).
The advantage of CDI is a specific and high quality framework for Dependency Injection with context. You can do a lot of thing with that (many many many really). Take a look on DeltaSpike which are tons of Utils built only over CDI (due it extension property). Another good source is the spec JSR #346 =) There you can find the features of CDI.
This will be great when CDI is the only thing going, which I assume then that a JSF 2.3 container like Tomcat would support CDI at the time it's available. But that's years away given that 2.2 just came out, so for the forseeable future, if we're deploying in Tomcat, or Jetty, or what not, then ManagedBean seems the best route for now.