Ich habe gerade angefangen, Core JavaServer Faces, 3. Ausgabe, durchzulesen. und sie sagen dies (Hervorhebung von mir):

Es ist ein historischer Zufall, dass es zwei separate Mechanismen gibt, CDI-Beans und JSF-verwaltete Beans für Beans, die in JSF-Seiten verwendet werden können. Wir empfehlen, CDI-Beans zu verwenden, es sei denn, Ihre Anwendung muss auf einem einfachen Servlet-Runner wie Tomcat ausgeführt werden.

Warum? Sie liefern keine Rechtfertigung. Ich habe @ManagedBeanfür alle Beans in einer Prototyp-Anwendung verwendet, die auf GlassFish 3 ausgeführt wird, und ich habe keine wirklichen Probleme damit bemerkt. Es macht mir nichts aus @ManagedBean, von nach zu migrieren @Named, aber ich möchte wissen, warum ich mich darum kümmern sollte .

CDI wird gegenüber einfachem JSF bevorzugt, da CDI eine JavaEE-weite Abhängigkeitsinjektion ermöglicht. Sie können auch POJOs injizieren und verwalten lassen. Mit JSF können Sie nur eine Teilmenge dessen einfügen, was Sie mit CDI können.

Verwenden Sie CDI.

Gemäß JSF 2.3 @ManagedBeanist veraltet . Siehe auch Spezifikationsausgabe 1417 . Dies bedeutet , dass es nicht mehr ein Grund , wählen @ManagedBeanüber @Named. Dies wurde erstmals in der Beta-Version m06 von Mojarra 2.3.0 implementiert.

Geschichte

Der Hauptunterschied besteht darin, dass @ManagedBeanes vom JSF-Framework verwaltet wird und nur über @ManagedPropertyandere JSF-verwaltete Beans verfügbar ist. @Namedwird durch Anwendungsserver (der Behälter) über CDI Rahmen und ist über verwaltete zur @InjectVerfügung , um jede Art von einem Container verwaltet Artefakt wie @WebListener, @WebFilter, @WebServlet, @Path, @Stateless, etc. und sogar ein JSF @ManagedBean. Von der anderen Seite auf, @ManagedPropertywird nicht funktionieren innerhalb einer @Namedoder einem anderen Container verwaltet Artefakt. Es funktioniert wirklich nur drinnen @ManagedBean.

Ein weiterer Unterschied besteht darin, dass CDI tatsächlich Proxys, die an die aktuelle Instanz delegiert werden, im Zielbereich pro Anforderung / Thread injiziert (z. B. wie EJBs injiziert wurden). Dieser Mechanismus ermöglicht das Injizieren einer Bean eines engeren Bereichs in eine Bean eines breiteren Bereichs, was mit JSF nicht möglich ist @ManagedProperty. JSF "injiziert" hier die physische Instanz direkt durch Aufrufen eines Setters (genau deshalb ist auch ein Setter erforderlich, während dies bei nicht erforderlich ist @Inject).

Obwohl dies nicht direkt ein Nachteil ist - es gibt andere Möglichkeiten -, ist der Umfang @ManagedBeaneinfach begrenzt. Aus der anderen Perspektive können Sie, wenn Sie nicht "zu viel" aussetzen möchten, @Injectauch einfach Ihre verwalteten Bohnen behalten @ManagedBean. Es ist wie protectedgegen public. Das zählt aber nicht wirklich.

Zumindest in JSF 2.0 / 2.1 besteht der Hauptnachteil der Verwaltung von JSF-Backing-Beans über CDI darin, dass es kein CDI-Äquivalent zu gibt @ViewScoped. Das @ConversationScopedkommt nahe, erfordert aber immer noch das manuelle Starten und Stoppen und hängt einen hässlichen cidAnforderungsparameter an die Ergebnis-URLs an. MyFaces CODI macht es einfacher, indem JSFs vollständig transparent javax.faces.bean.ViewScopedmit CDI verbunden werden, sodass Sie dies einfach tun können. Dabei @Named @ViewScopedwird jedoch ein hässlicher windowIdAnforderungsparameter an die Ergebnis-URLs angehängt , auch bei der einfachen Vanilla-Navigation von Seite zu Seite. OmniFaces löst dies alles mit einer echten CDI, @ViewScopeddie den Gültigkeitsbereich der Bean wirklich an den JSF-Ansichtsstatus anstatt an einen beliebigen Anforderungsparameter bindet.

JSF 2.2 (das 3 Jahre nach dieser Frage / Antwort veröffentlicht wird) bietet eine neue, vollständig CDI-kompatible @ViewScopedAnnotation im Geschmack von javax.faces.view.ViewScoped. JSF 2.2 wird sogar mit einem CDI-only geliefert, @FlowScopeddas kein @ManagedBeanÄquivalent hat, wodurch JSF-Benutzer in Richtung CDI gedrängt werden. Es wird erwartet, dass @ManagedBeanFreunde gemäß Java EE 8 veraltet sind. Wenn Sie derzeit noch verwenden @ManagedBean, wird dringend empfohlen, auf CDI zu wechseln, um sich auf zukünftige Upgrade-Pfade vorzubereiten. CDI ist in Java EE Web Profile-kompatiblen Containern wie WildFly, TomEE und GlassFish verfügbar. Für Tomcat müssen Sie es separat installieren, genau wie Sie es bereits für JSF getan haben. Siehe auch Wie installiere ich CDI in Tomcat?

Mit Java EE 6 und CDI haben Sie verschiedene Optionen für Managed Beans

• @javax.faces.bean.ManagedBeanbezieht sich auf JSR 314 und wurde mit JSF 2.0 eingeführt. Das Hauptziel war es, die Konfiguration in der Datei flags-config.xml zu vermeiden, um die Bean in einer JSF-Seite zu verwenden.
• @javax.annotation.ManagedBean(“myBean”) wird durch JSR 316 definiert. Es verallgemeinert die von JSF verwalteten Beans zur Verwendung an anderer Stelle in Java EE
• @javax.inject.Named(“myBean”) sind fast identisch mit der obigen, außer dass Sie eine beans.xml-Datei im web / WEB-INF-Ordner benötigen, um CDI zu aktivieren.

Ich habe CDI in GlassFish 3.0.1 verwendet, aber um es zum Laufen zu bringen, musste ich das Seam 3-Framework (Weld) importieren. Das hat ziemlich gut funktioniert.

In GlassFish 3.1 funktionierte CDI nicht mehr und die Nahtschweißung funktionierte nicht mehr damit. Ich habe einen Fehler in diesem Bereich geöffnet, aber noch keinen Fehler behoben. Ich musste meinen gesamten Code in die Annotationen javax.faces. * Konvertieren, aber ich plane, wieder zu CDI zu wechseln, sobald sie funktionieren.

Ich bin damit einverstanden, dass Sie CDI verwenden sollten, aber ein Problem, das ich noch nicht gelöst habe, ist die Vorgehensweise mit der Annotation @ViewScoped. Ich habe viel Code, der davon abhängt. Es ist nicht klar, ob @ViewScoped funktioniert, wenn Sie @ManagedBean nicht damit verwenden. Wenn jemand dies klarstellen kann, würde ich es begrüßen.

Ein guter Grund, auf CDI umzusteigen: Möglicherweise haben Sie eine gemeinsame Ressource mit Sitzungsbereich (z. B. Benutzerprofil) @Inject, die sowohl in JSF-verwaltete Beans als auch in REST-Services (z. B. Jersey / JAX-RS) integriert ist.

Auf der anderen Seite @ViewScopedist dies ein überzeugender Grund, sich an JSF zu halten @ManagedBean- insbesondere für alles, was mit AJAX zu tun hat. In CDI gibt es dafür keinen Standardersatz.

Es scheint, dass es eine Unterstützung für eine @ViewScopedähnliche Annotation für CDI-Beans gibt, aber ich habe nicht persönlich damit gespielt.

http://seamframework.org/Seam3/FacesModule