You should not have any other @ManagedBean beside @Named.

Provocative title, I know. But this is what my mind came up with, reading about @EdBurns latest survey where the JSF EG asks the community: "Should we deprecate Managed Beans in #JSF 2.2?". Seeing the first intermediate direction from today, it's the majority of the voters (roughly 80%), which vote for removing/deprecating them.
Great indication not only for the JSF EG but also for the whole EE 7 EG. Why?

What's all this about?
It's about the Faces Managed Beans. It defines a couple of Annotations for automatically registering classes with the runtime as a managed bean class within specific scopes. Classes must be scanned for the presence of this annotation at application startup, before any requests have been serviced. As you can see from the comments, it has been planned to extract the specification for managed beans from JSF and place it into its own specification since the 2.0 (Java EE 6). If you compare the features with the ones provided by Contexts and Dependency Injection (CDI). CDI defines a set of contextual services, provided by Java EE containers, that make it easy for developers to use enterprise beans along with JavaServer Faces technology in web applications. Designed for use with stateful objects, CDI also has many broader uses, allowing developers a great deal of flexibility to integrate different kinds of components in a loosely coupled but type-safe way. If you compare the scopes in javax.enterprise.context.* and javax.faces.bean.* (Weld API Docs, DI API) you see some common names. And that basically is the problem here. You can achieve mostly the same using the javax.faces.bean.ManagedBean or any javax.inject.Named with a CDI Context. This multiple solutions space not only covers JSF but also the javax.annotation.ManagedBean (API) and with it the complete platform. The ManagedBean annotation marks a POJO (Plain Old Java Object) as a ManagedBean. A javax.annotation.ManagedBean supports a small set of basic services such as resource injection, lifecycle callbacks and interceptors. It seems as if this was intended to be a first draft of the new container objects which don't have to implement interfaces or conform to any container requirements except the fact, that they have a special annotation with them.

What does it mean to remove the Faces Managed Beans?
Depending on you view onto the platform it could either be a first step into consolidation of the different ManagedBean approaches with Java EE or even a step to make JSF completely dependent on the Java EE Web Profile. If the Faces Managed Beans feature is dropped, you need any kind of Managed Bean service to the core JSF functionality. A standalone appserver which does not contain one of the mechanisms JSF will depend on (CDI/DI or EE ManagedBeans) will not be able to run it anymore. So, you decide weather or not JSF could be used without a EE profile or not.

What do the experts say?
I can only speak for myself here, rate for yourself if you still need the answer from an expert :) I personally voted for removing the Faces Managed Beans. They cause confusion with developers. Removing them force the EE 7 EG to think about a general approach for other specs being in a comparable situation (present and future). The drawback is, you will probably lose the ability to run on very lightweight Java appserver which do not conform to one of the defined profiles and can't provide DI/CDI features.
Further on, there are still complaints about the quality and performance of WELD being the RI for CDI. So, in the end, I believe a couple of actions have to be taken to make the removal of the Faces Managed Beans a success story. But it will be worth it: Looking at the complete Java EE 7 platform!

Cast your vote here! Help shape Java EE 7 and beyond!

I would love to read about your thoughts! Please take a minute to express your ideas and rating on that in the comments! 

From http://blog.eisele.net/2011/04/you-should-not-have-any-other.html