Are @ManagedBean's obsolete in JavaEE6 - because of @Named in CDI/Weld?

Question

Because of CDI (and its implementation Weld), every POJO in JEE6 can be annotated with @Named, which makes the POJO accessible to the view. Does that mean that ManagedBeans are completely obsolete now? Or do i miss something where @ManagedBean still makes sense?

Answer 1

As i Just read in the Weld Reference (p. 12), @ManagedBean is now superflous:

You can explicitly declare a managed bean by annotating the bean class @ManagedBean, but in CDI you don't need to. According to the specification, the CDI container treats any class that satisfies the following conditions as a managed bean:

• It is not a non-static inner class. It is a concrete class, or is annotated @Decorator.
• It is not annotated with an EJB component-defining annotation or declared as an EJB bean class in ejb-jar.xml.
• It does not implement javax.enterprise.inject.spi.Extension.
• It has an appropriate constructor—either:
• the class has a constructor with no parameters, or
• the class declares a constructor annotated @Inject.

Answer 2

You have a choice. Either use the @ManagedBean from JSF2 to bind beans into your forms, or use the @Named annotation from CDI. If you plan on only doing JSF, you can stick to @ManagedBean, but if you want to integrate with EJB's, or make use of CDI's @ConversationScoped, then go the CDI route.

Personally I feel the next version of JSF should deprecate the @ManagedBean, and standardize on CDI. The duality is confusing to newcomers.

Answer 3

In short, @ManagedBean makes sense for applications that use JSF but do not use JSR 299 (whatever the reason is). Below a longer explanation from Gavin King:

Re: Comparisons to @ManagedBean annotations in JSF2?:

While looking through the Weld examples, and the older WebBeans documentation, it looks like a competitor to the new @ManagedBean JSF 2.0 annotations. Is there any information on when we'd want to use one over the other?

It's a good question, and I'm not really in full agreement with the answers that have been posted so far.

The new EE Managed Beans specification defines a base component model for Java EE, together with a very basic set of container services (@Resource, @PostConstruct, @PreDestroy).

The idea is that other specifications (beginning with EJB, CDI, JSF and the new Java Interceptors spec) build upon this base component model and layer additional services, for example transaction management, typesafe dependency injection, interceptors. So at this level, the managed beans, CDI, interceptors and EJB specifications all work hand-in-hand and are highly complementary.

Now, the Managed Beans specification is quite open-ended with respect to identifying exactly which classes are managed beans. It does provide the @ManagedBean annotation as one mechanism, but it also allows other specifications to define different mechanisms. So, for example:

• The EJB specification says that a class obeying certain programming restrictions with a @Stateless or @Stateful annotation deployed in an EJB jar is a managed bean.

• The CDI specification says that any class with an appropriate constructor deployed in a "bean deployment archive" is a managed bean.

Given that EJB and CDI provide arguably more convenient ways to identify a managed bean, you might wonder precisely what @ManagedBean is needed for. The answer, as alluded to by Dan, is that if you have CDI available in your environment (for example, if you are using EE6), then @ManagedBean is just not really needed. @ManagedBean is really there for use by people who are using JSF2 without CDI.

OTOH, if you do annotate a bean @ManagedBean, and you do have CDI in your environment, you can still use CDI to inject stuff into your bean. It's just that the @ManagedBean annotation is not required in this case.

To summarize, if you do have CDI available to you, it provides a far superior programming model to the @ManagedBean/@ManagedProperty model that JSF2 inherits from JSF1. So superior, in fact, that the EE 6 web profile does not require support for @ManagedProperty etc. The idea being that you should just use CDI instead.