Core JavaServer Faces、第3版を読み始めたところです。そして彼らはこれを言う（私の強調）：

JSFページで使用できるBeanには、CDI BeanとJSF管理Beanの2つの別個のメカニズムがあるのは歴史的な事故です。アプリケーションがTomcatなどのプレーンサーブレットランナーで動作する必要がない限り、CDI Beanを使用することをお勧めします。

どうして？彼らは提供していない任意の正当性を。私は@ManagedBeanGlassFish 3で実行されているプロトタイプアプリケーションのすべてのBean を使用してきましたが、これに関する問題に気づきませんでした。から@ManagedBeanへの移行は特に問題ではありませんが@Named、なぜ煩わしいのかを知りたいのです。

CDIではJavaEE全体の依存性注入が可能であるため、プレーンなJSFよりもCDIが推奨されます。POJOを挿入して管理することもできます。JSFでは、CDIでできることのサブセットのみを注入できます。

CDIを使用します。

JSF 2.3に従い、@ManagedBeanは非推奨です。仕様の問題1417も参照してください。もう選択する理由がないことを、この手段@ManagedBeanを超えます@Named。これはMojarra 2.3.0ベータバージョンm06で最初に実装されました。

歴史

中心的な違いは、@ManagedBeanJSFフレームワークによって管理され@ManagedProperty、別のJSF管理Beanでのみ使用できることです。@NamedCDI・フレームワークを介してアプリケーションサーバ（コンテナ）で管理を介してである@Injectようなコンテナ管理アーチファクトの任意の種類の利用可能な@WebListener、@WebFilter、@WebServlet、@Path、@Stateless、などともJSF @ManagedBean。反対側から見ると、またはその他のコンテナ管理のアーティファクト内で@ManagedPropertyは機能しません@Named。内部でのみ機能します@ManagedBean。

もう1つの違いは、CDIは実際に、ターゲットスコープの現在のインスタンスに委任するプロキシを、リクエスト/スレッドごとに（EJBの注入方法などのように）注入することです。このメカニズムにより、より狭いスコープのBeanをより広いスコープのBeanに挿入できますが、これはJSFでは不可能@ManagedPropertyです。JSFは、ここで、setterを呼び出すことによって物理インスタンスを直接「注入」します（それが、setterが必要であるのとまったく同じ理由ですが、では必要ありません@Inject）。

直接の欠点ではありませんが、他の方法があります—の範囲@ManagedBeanは単に制限されています。別の見方をすると、について「あまりにも」公開したくない場合は@Inject、マネージドBeanだけを保持することもできます@ManagedBean。protected対のようなものpublicです。しかし、それは実際には重要ではありません。

少なくとも、JSF 2.0 / 2.1では、JSFバッキングBeanをCDIで管理することの主な欠点は、に相当するCDIがないことです@ViewScoped。@ConversationScoped近づくが、それでも手動起動と停止要求し、それが醜い追加しcid、結果のURLへのリクエストパラメータを。MyFaces CODIは、JSFを完全に透過的javax.faces.bean.ViewScopedにCDIにブリッジして簡単にできるようにします@Named @ViewScoped。ただし、windowId単純なページ間のナビゲーションでも、結果のURLに醜い要求パラメーターを追加します。OmniFaces@ViewScopedは、Beanのスコープを任意のリクエストパラメータではなくJSFビューステートに実際に結び付ける真のCDI でこれをすべて解決します。

JSF 2.2（この質問/回答から3年後にリリースされます）は、の@ViewScopedフレーバーで、完全なCDI互換の新しいアノテーションを提供しますjavax.faces.view.ViewScoped。JSF 2.2に@FlowScopedは、@ManagedBean同等のものがないCDIのみが付属しているため、JSFユーザーはCDIに向かっています。@ManagedBeanJava EE 8に従って、友人は非推奨になると予想されます。現在をまだ使用している場合は@ManagedBean、将来のアップグレードパスに備えてCDIに切り替えることを強くお勧めします。CDIは、WildFly、TomEE、GlassFishなどのJava EE Webプロファイル互換コンテナーですぐに利用できます。Tomcatの場合は、JSFの場合とまったく同じように、個別にインストールする必要があります。TomcatにCDIをインストールする方法も参照してください。

Java EE 6とCDIでは、マネージドBeanに異なるオプションがあります

• @javax.faces.bean.ManagedBeanJSR 314を参照し、JSF 2.0で導入されました。主な目標は、faces-config.xmlファイルの構成を回避して、JSFページ内でBeanを使用することでした。
• @javax.annotation.ManagedBean(“myBean”) JSR 316によって定義されています。これは、Java EEの他の場所で使用するためにJSF管理対象Beanを一般化します
• @javax.inject.Named(“myBean”) CDIをアクティブ化するには、web / WEB-INFフォルダーにbeans.xmlファイルが必要であることを除いて、上記のものとほとんど同じです。

GlassFish 3.0.1でCDIを使用していましたが、それを機能させるにはSeam 3フレームワーク（Weld）をインポートする必要がありました。それはかなりうまくいきました。

GlassFish 3.1では、CDIが機能しなくなり、Seam Weldがそれを使用しなくなりました。私はこれに関するバグをオープンしましたが、まだ修正されているのを見ていません。すべてのコードをjavax.faces。*アノテーションを使用するように変換する必要がありましたが、機能するようになったらCDIに戻る予定です。

CDIを使用する必要があることに同意しますが、まだ解決されていない問題の1つは、@ ViewScopedアノテーションをどうするかです。それに依存するコードがたくさんあります。@ManagedBeanを使用していない場合に@ViewScopedが機能するかどうかは明確ではありません。誰かがこれを明確にできるならば、私はそれを感謝します。

CDIに移行する理由の1つは、@InjectJSFマネージドBeanとRESTサービス（Jersey / JAX-RSなど）の両方に共通のセッションスコープのリソース（ユーザープロファイルなど）を設定できることです。

一方で、@ViewScopedJSFに固執するのはやむを得ない理由@ManagedBeanです。特に、重要なAJAXがあるものには特にそうです。CDIには、これに代わる標準はありません。

@ViewScopedCDI Beanの-likeアノテーションをある程度サポートしているようですが、私は個人的には使用していません。

http://seamframework.org/Seam3/FacesModule