最終的にHttpSessionにバインドされるスコープに属するすべてのCDIマネージドBeanは、シリアライズ可能である必要があります。つまり、すべての属性をシリアライズ可能にする必要があります。これはバグだと思われますが、EntityManagerはありません（hereとhere（なぜ閉じているのか分かりません））。JPAはHttpSessionで管理されているCDIスコープでは使用できませんか？
これは、スペックを遵守したい場合は、SessionやConversationなどのCDIスコープからJPAを使用できないことを意味します。
Java EEが使用不可能に近いと思われますか？
あなたは正しい：EntityManagerはシリアライズ可能ではありませんが、CDI EGはそれを気付かなかったと思いますか?-)？
したがって、CDI Beanがシリアライズされている（つまりSFSBのパッシベーション）場合、EntityManagerは一時的なものとみなされ、そうではありません。 Beanがシリアル化されていない場合、EntityManagerはBeanに自動的に再注入されるため、以前と同じように動作します。
問題は、BeanでExtended Persistence Contextを使用する場合です。 Java EE仕様は、このようなBeanのシリアライズをサポートしていません。しかし、Java EE 5のSeam 2やJava EE 6のSeam3 PersistenceのようなCDI拡張のようなフレームワークでは、これらの特殊なユースケースを管理する可能性があります。
ありがとうございます。私はEJB 3.1仕様を見ており、次のように述べています。 'コンテナは、以下の条件が満たされない限り、拡張永続コンテキストを持つステートフルセッションBeanを不動態化してはいけません。1.永続コンテキスト内のすべてのエンティティが直列化可能です。 2. EntityManagerはシリアライズ可能です。コンテナは、これらの要件を満たしていないため、ステートフルセッションBeanインスタンスを破棄することはできません。 正しく理解すると、パッシベーションできないSFSBはメモリ内に残る必要があります。 Session Scoped CDI Beanの場合はどのように見えますか？ –
@Antoine、情報ありがとうございますが、Seam 3がExtended Persistence Contextのシリアル化を処理する方法や、いくつかのリソースを教えてくれますか？ – user953217
私はこのメカニズムをSeam 3でテストしませんでしたが、Seam 2ではこれまでいくつかのドキュメントを確認できました：http://docs.jboss.org/seam/latest/reference/en-US/html/ClusteringAndEJBPassivation .html Seam 2 pojoは同じ機能を持っています。 EJBとシンプルCDI BeanのSeam 3永続性に移植されていることを確認し、あなたの投稿を続けます。 –