Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Backing beans (@ManagedBean) or CDI Beans (@Named)?

I've just started reading through Core JavaServer Faces, 3rd Ed. and they say this (emphasis mine):

It is a historical accident that there are two separate mechanisms, CDI beans and JSF managed beans, for beans that can be used in JSF pages. We suggest that you use CDI beans unless your application must work on a plain servlet runner such as Tomcat.

Why? They don't provide any justification. I've been using @ManagedBean for all the beans in a prototype application running on GlassFish 3, and I haven't really noticed any issues with this. I don't especially mind migrating from @ManagedBean to @Named, but I want to know why I should bother.

like image 452
Matt Ball Avatar asked Dec 03 '10 16:12

Matt Ball


People also ask

What are CDI beans?

A CDI bean is a POJO, plain old java object, that has been automatically instantiated by the CDI container, and is injected into all, and any qualifying injection points in the application. The CDI container initiates the bean discovery process during deployment.

What are backing beans?

Backing Beans are Java Beans Components associated with User Interface Components in a JSF Page. It contains Action methods, Action Listeners and Value Change listeners that correspond to the UI components that initiate action events.

What is JSF CDI bean?

Getting Started with CDI and JSF 2.0 Contexts and Dependency Injection (CDI), specified by JSR-299, is an integral part of Java EE 6 and provides an architecture that allows Java EE components such as servlets, enterprise beans, and JavaBeans to exist within the lifecycle of an application with well-defined scopes.

What is the difference between managed bean and backing bean?

1) BB: A backing bean is any bean that is referenced by a form. MB: A managed bean is a backing bean that has been registered with JSF (in faces-config. xml) and it automatically created (and optionally initialized) by JSF when it is needed.


1 Answers

Use CDI.

As per JSF 2.3, @ManagedBean is deprecated. See also spec issue 1417. This means that there's not anymore a reason to choose @ManagedBean over @Named. This was first implemented in Mojarra 2.3.0 beta version m06.

enter image description here


History

The core difference is, @ManagedBean is managed by JSF framework and is only via @ManagedProperty available to another JSF managed beans. @Named is managed by application server (the container) via CDI framework and is via @Inject available to any kind of a container managed artifact like @WebListener, @WebFilter, @WebServlet, @Path, @Stateless, etc and even a JSF @ManagedBean. From the other side on, @ManagedProperty does not work inside a @Named or any other container managed artifact. It works really only inside @ManagedBean.

Another difference is that CDI actually injects proxies delegating to the current instance in the target scope on a per-request/thread basis (like as how EJBs are been injected). This mechanism allows injecting a bean of a narrower scope in a bean of a broader scope, which isn't possible with JSF @ManagedProperty. JSF "injects" here the physical instance directly by invoking a setter (that's also exactly why a setter is required, while that is not required with @Inject).

While not directly a disadvantage — there are other ways — the scope of @ManagedBean is simply limited. From the other perspective, if you don't want to expose "too much" for @Inject, you can also just keep your managed beans @ManagedBean. It's like protected versus public. But that doesn't really count.

At least, in JSF 2.0/2.1, the major disadvantage of managing JSF backing beans by CDI is that there's no CDI equivalent of @ViewScoped. The @ConversationScoped comes close, but still requires manually starting and stopping and it appends an ugly cid request parameter to outcome URLs. MyFaces CODI makes it easier by fully transparently bridging JSF's javax.faces.bean.ViewScoped to CDI so you can just do @Named @ViewScoped, however that appends an ugly windowId request parameter to outcome URLs, also on plain vanilla page-to-page navigation. OmniFaces solves this all with a true CDI @ViewScoped which really ties the bean's scope to JSF view state instead of to an arbitrary request parameter.

JSF 2.2 (which is released 3 years after this question/answer) offers a new fully CDI compatible @ViewScoped annotation out the box in flavor of javax.faces.view.ViewScoped. JSF 2.2 even comes along with a CDI-only @FlowScoped which doesn't have a @ManagedBean equivalent, hereby pushing JSF users towards CDI. The expectation is that @ManagedBean and friends will be deprecated as per Java EE 8. If you're currently still using @ManagedBean, it's therefore strongly recommend to switch to CDI to be prepared for future upgrade paths. CDI is readily available in Java EE Web Profile compatible containers, such as WildFly, TomEE and GlassFish. For Tomcat, you have to install it separately, exactly as you already did for JSF. See also How to install CDI in Tomcat?

like image 170
BalusC Avatar answered Oct 09 '22 01:10

BalusC