Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<h1>Use CDI.</h1> <p>As per JSF 2.3, <code>@ManagedBean</code> is <strong>deprecated</strong>. See also <a href="https://github.com/javaee/javaserverfaces-spec/issues/1417" rel="noreferrer">spec issue 1417</a>. This means that there's not anymore a reason to choose <code>@ManagedBean</code> over <code>@Named</code>. This was first implemented in Mojarra 2.3.0 beta version m06.</p> <p><a href="https://i.stack.imgur.com/YdG3r.png" rel="noreferrer"><img src="https://i.stack.imgur.com/YdG3r.png" alt="enter image description here"></a></p> <hr> <h3>History</h3> <p>The core difference is, <a href="http://docs.oracle.com/javaee/7/api/javax/faces/bean/ManagedBean.html" rel="noreferrer"><code>@ManagedBean</code></a> is managed by JSF framework and is only via <a href="https://docs.oracle.com/javaee/7/api/javax/faces/bean/ManagedProperty.html" rel="noreferrer"><code>@ManagedProperty</code></a> available to another JSF managed beans. <a href="http://docs.oracle.com/javaee/7/api/javax/inject/Named.html" rel="noreferrer"><code>@Named</code></a> is managed by application server (the container) via CDI framework and is via <a href="http://docs.oracle.com/javaee/7/api/javax/inject/Inject.html" rel="noreferrer"><code>@Inject</code></a> available to any kind of a container managed artifact like <code>@WebListener</code>, <code>@WebFilter</code>, <code>@WebServlet</code>, <code>@Path</code>, <code>@Stateless</code>, etc and even a JSF <code>@ManagedBean</code>. From the other side on, <code>@ManagedProperty</code> does <strong>not</strong> work inside a <code>@Named</code> or any other container managed artifact. It works really only inside <code>@ManagedBean</code>.</p> <p>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 <code>@ManagedProperty</code>. JSF "injects" here the physical instance directly by invoking a setter (that's also exactly why a setter is required, while that is <strong>not</strong> required with <code>@Inject</code>).</p> <p>While not directly a disadvantage &mdash; there are other ways &mdash; the scope of <code>@ManagedBean</code> is simply limited. From the other perspective, if you don't want to expose "too much" for <code>@Inject</code>, you can also just keep your managed beans <code>@ManagedBean</code>. It's like <code>protected</code> versus <code>public</code>. But that doesn't really count.</p> <p>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 <code>@ViewScoped</code>. The <code>@ConversationScoped</code> comes close, but still requires manually starting and stopping and it appends an ugly <code>cid</code> request parameter to outcome URLs. MyFaces CODI makes it easier by fully transparently bridging JSF's <code>javax.faces.bean.ViewScoped</code> to CDI so you can just do <code>@Named @ViewScoped</code>, however that appends an ugly <code>windowId</code> request parameter to outcome URLs, also on plain vanilla page-to-page navigation. <a href="http://omnifaces.org" rel="noreferrer">OmniFaces</a> solves this all with a true CDI <a href="http://showcase.omnifaces.org/cdi/ViewScoped" rel="noreferrer"><code>@ViewScoped</code></a> which really ties the bean's scope to JSF view state instead of to an arbitrary request parameter.</p> <p>JSF 2.2 (which is released 3 years after this question/answer) offers a new fully CDI compatible <code>@ViewScoped</code> annotation out the box in flavor of <code>javax.faces.view.ViewScoped</code>. JSF 2.2 even comes along with a CDI-only <code>@FlowScoped</code> which doesn't have a <code>@ManagedBean</code> equivalent, hereby pushing JSF users towards CDI. The expectation is that <code>@ManagedBean</code> and friends will be deprecated as per Java EE 8. If you're currently still using <code>@ManagedBean</code>, 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 <a href="http://balusc.omnifaces.org/2013/10/how-to-install-cdi-in-tomcat.html" rel="noreferrer">How to install CDI in Tomcat?</a></p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload