CDI(およびその実装Weld)により、JEE6のすべてのPOJOに、という注釈を付けることができます@Named。これにより、POJOがビューにアクセスできるようになります。
これは、ManagedBeansが完全に廃止されたことを意味しますか?@ManagedBeanそれとも、まだ意味のある何かを見逃しましたか?
CDI(およびその実装Weld)により、JEE6のすべてのPOJOに、という注釈を付けることができます@Named。これにより、POJOがビューにアクセスできるようになります。
これは、ManagedBeansが完全に廃止されたことを意味しますか?@ManagedBeanそれとも、まだ意味のある何かを見逃しましたか?
つまり、@ManagedBeanJSFを使用するが、JSR 299を使用しないアプリケーションには意味があります(理由が何であれ)。Gavin Kingからのより長い説明の下:
Re:JSF2の@ManagedBeanアノテーションとの比較?:
Weldの例と古いWebBeansのドキュメントを見ると、新しい@ManagedBeanJSF2.0アノテーションの競合相手のように見えます。いつ使用したいのかについての情報はありますか?
これは良い質問ですが、これまでに投稿された回答に完全には同意していません。
新しいEEManagedBeans仕様は、Java EEの基本コンポーネントモデルを、非常に基本的なコンテナサービスのセット(、、、)とともに定義
@Resourceし@PostConstructます@PreDestroy。他の仕様(EJB、CDI、JSF、および新しいJavaインターセプター仕様で始まる)は、この基本コンポーネントモデルに基づいて構築され、トランザクション管理、タイプセーフな依存性注入、インターセプターなどの追加サービスをレイヤー化します。したがって、このレベルでは、マネージドBean、CDI、インターセプター、およびEJB仕様はすべて連携して機能し、高度に補完的です。
現在、Managed Beans仕様は、どのクラスがManagedBeanであるかを正確に識別することに関して非常に制限がありません。注釈を1つのメカニズムとして提供しますが、
@ManagedBean他の仕様で異なるメカニズムを定義することもできます。したがって、たとえば:
@StatelessEJB仕様では、EJBjarにデプロイされたor アノテーションを使用して特定のプログラミング制限に従うクラス@StatefulはマネージドBeanであるとされています。CDI仕様では、「Beanデプロイメントアーカイブ」にデプロイされた適切なコンストラクターを持つクラスはすべてマネージドBeanであるとされています。
EJBとCDIが、マネージドBeanを識別するための間違いなくより便利な方法を提供することを考えると、何
@ManagedBeanが必要かを正確に疑問に思うかもしれません。ダンがほのめかしているように、その答えは、環境でCDIを使用できる場合(たとえば、EE6を使用している場合)、@ManagedBean実際には必要ないということです。@ManagedBeanCDIなしでJSF2を使用している人々が使用するために実際にあります。OTOH、Bean
@ManagedBeanに注釈を付け、環境にCDIがある場合でも、CDIを使用してBeanにデータを注入できます。この場合、@ManagedBean注釈は必要ありません。要約すると、CDIを使用できる場合は、JSF2がJSF1から継承する/モデルよりもはるかに 優れたプログラミングモデルを
@ManagedBean@ManagedProperty提供します。実際、非常に優れているため、EE6Webプロファイルは@ManagedPropertyなどのサポートを必要としません。代わりにCDIを使用する必要があるという考えです。
選択肢があります。JSF2の@ManagedBeanを使用してBeanをフォームにバインドするか、CDIの@Namedアノテーションを使用します。JSFのみを実行する場合は、@ ManagedBeanを使用できますが、EJBと統合する場合、またはCDIの@ConversationScopedを使用する場合は、CDIルートを使用します。
個人的には、JSFの次のバージョンは@ManagedBeanを廃止し、CDIで標準化する必要があると感じています。二元性は新参者を混乱させます。
CDIにはビューの概念がないため、ビュースコープがありません。したがって、そのスコープが必要な場合、純粋な形式のCDIではそれを実行できません。ビュースコープとは、基本的にリクエストスコープ+AJAX対応であることを意味します。JSFなどが表示されていても、という名前のページのようなJSFビューではありません。ビュースコープのBeanでよく使用されるのは、GETパラメーターをそのようなBeanに取り込む方法です。これも読んでください。xyz.xhtml<f:viewParam>
CDIは、JSF/プレゼンテーション層ではなくEJB/サービス層に存在することに注意してください。このブログには素晴らしい概要があります。
そのため、Bean@ManagedBeanを使用している場合は、CDIで完全に置き換えることはできません。@ViewScoped少なくとも、CDIを拡張したり、 Seam3Facesモジュールを使用したりする必要はありません。ビュースコープのBeanの使用は、RichFaces、PrimeFaces、IceFacesなどのAJAXedJSF2ベースのGUIツールキットを使用する場合にほとんど常に発生します。
間違ったJavaEE6パッケージのアノテーションを混在させると、RichFacesまたは同様のAPIを使用しているときに、予期せぬ問題が発生する可能性があります。
@javax.faces.bean.ManagedBean
@javax.faces.bean.[Jsf]Scoped
ここではRichFaces、PrimeFacesなどによってプレゼンテーション層でのみ使用されるコンポーネント用です。一部のリッチコンポーネントには、CDI注釈付きおよびJSF注釈付きのヘルパーBeanに問題があるようです。Bean(または何もしないように見えるBean)から奇妙な動作が発生した場合は、アノテーションの間違った組み合わせが原因である可能性があります。
JSFとCDIの混合
@javax.inject.Named
@javax.faces.bean.[Jsf]Scoped
可能であり、ほとんどの場合、JSFページから参照すると機能しますが、CDIにないJSFスコープを使用する場合など、あまり知られていない問題/欠点がいくつかあります。
また、この組み合わせ
@Named @ViewScopedは意図したとおりに機能しません。JSF固有@ViewScopedは、JSF固有との組み合わせで@ManagedBeanのみ機能します。CDI固有@Namedはこのように動作@RequestScopedします。@ManagedBeanの代わりに使用するか、の代わりに@NamedCDI固有を使用してください。@ConversationScoped@ViewScoped
それで
@javax.inject.Named
@javax.faces.bean.[Cdi]Scoped
JSFページAFAIKから直接参照されるCDIBeanに使用できます。私はこれまで上記の組み合わせに問題はなかったので、@ManagedBeanここでは廃止されたと見なすことができます。
残っているのはサービス層で、ここでは主にトランザクションEJBサービスBeanが次のように宣言されています。
@javax.ejb.*
主に@javax.ejb.Stateless。JSFページから直接EJBに注釈を付けて使用することもできますが、この設計が望ましいかどうかはわかりません。@ javax.ejb。*で注釈が付けられたコンポーネントを参照(挿入)するには、たとえば、ここで説明する@Statelessよりも優先@Injectします。(おそらくこの答えの祖先...)@EJB
最後に、Java EE 6アノテーションの非常に優れた概要は、次の場所にあります 。http ://www.physics.usyd.edu.au/~rennie/javaEEReferenceSheet.html
注:上記の情報は専門家からのものではなく、このばかばかしいほど紛らわしいJavaEE6アノテーションスパゲッティに関する新参者の視点からの私自身の見解です。より多くの洞察はまだ開発されていません。この回答が、元の質問の文脈では少し行き過ぎたとしても、この混乱に対する一般的で実用的な回答になることを願っています。
溶接リファレンス(p。12)を読んだだけで、@ManagedBeanは不要になりました。
Beanクラス@ManagedBeanに注釈を付けることで、マネージドBeanを明示的に宣言できますが、CDIでは宣言する必要はありません。仕様によれば、CDIコンテナーは、以下の条件を満たすクラスをマネージドBeanとして扱います。
- 非静的内部クラスではありません。これは具象クラスであるか、@Decoratorという注釈が付けられています。
- これは、EJBコンポーネントを定義するアノテーションでアノテーションが付けられたり、ejb-jar.xmlでEJBBeanクラスとして宣言されたりすることはありません。
- javax.enterprise.inject.spi.Extensionは実装されていません。
- 適切なコンストラクターがあります—次のいずれかです。
- クラスにパラメーターのないコンストラクターがある、または
- クラスは、@Injectという注釈が付けられたコンストラクターを宣言します。