問題タブ [stateful-session-bean]

アプリケーション クライアントからステートフル セッション Bean (SFSB) にアクセスできません。JBoss 5.0.1.GA を使用しています。アプリケーション クライアントと EJB は両方ともデプロイする EAR にパッケージ化されており、問題なく動作する他のアプリケーション クライアントがあります。これまで、私はステートレス セッション Bean (SLSB) しか使用していませんでしたが、私が理解している限り、SLSB と SFSB の違いは、アプリケーション クライアントからのアクセス方法には影響しません。

クラス/インターフェースの構造:

アプリケーション クライアントは、「 JBoss 5 でアプリケーション クライアントを使用する方法」で説明されているように、「appclient-launcher」を介して実行されます。init() の実行中に (ローカル) ABean で someMethod() が呼び出されるまで、「BBean」のルックアップを行うことは正常に機能します。その呼び出し中に、コンテナーは InvalidStateException("Local call: security context is null") をスローします (根本的な原因として)。ステートフル Bean をステートレス Bean に変更すると、すべて正常に動作します (もちろん、状態が保持されないことを除きます)。興味深いことに、Web アプリケーション (JSF マネージド Bean) からまったく同じ SFSB を問題なく使用できます。

私は何か間違ったことをしていますか？アプリケーション クライアントから SFSB を使用するにはどうすればよいですか?

これまでのところ、この特定の問題について役立つものは何も見つかりませんでした。この例外は、[#JBAS-4317] Security Context over the invocationの同様のコンテキストで言及されていますが、完了としてマークされ、JBoss 5.0.0.Beta3 で修正されていることを考慮すると、同じ問題ではないようです。

EJB3 を学んでいて、いつ SFSB を使うと便利なのか知りたいのですが? SFSB が実際に複雑な問題を簡単に解決する良い例を見つけることができません。

実際、SLSB は Web サービスとして使用できることがわかり、これは便利です。しかし、いつSFSBを使うべきかわかりません。それについて何かを学ばなければならないので、私はそれに関する問題しか見ません.完全にではなく少し少ない注釈で構成されるコードを書く必要があります.迷惑なルックアップを使用する必要があります...そして、良いものは得られません。

たとえば、ステートフル オブジェクトはステートフル コンテキストからしか使用できないため、SLSB から SFSB を使用することはできません。サーブレットで DI を使用することはできません。代わりに、JNDI ルックアップを使用して手動で SFSB インスタンスを作成し、それを HttpSession オブジェクトに配置する必要があります。これは Web サービスではありません。

SFSB で見られる唯一の利点は、トランザクション管理です。しかし、本当にトランザクションが必要で、DB が不要な場合はまれだと思います。データを XML ファイルに保存し、SFSB でトランザクション管理を使用して非リレーショナル DB を管理すると、非常に便利になると想像できます。

私は完全に間違っているとほぼ確信しているので、SFSB の使用法の本当に良い例をいくつか教えてください。

Java EE 6チュートリアルを実行していて、ステートレスセッションBeanとステートフルセッションBeanの違いを理解しようとしています。ステートレスセッションBeanがメソッド呼び出しの合間に状態を保持しない場合、なぜ私のプログラムはそのように動作するのですか？

クライアント

getNumberが毎回0を返すことを期待していましたが、1を返し、ブラウザでサーブレットをリロードするとさらに増加し​​ます。問題は、ステートレスセッションBeanがどのように機能するかを理解していることであり、もちろん、ライブラリやアプリケーションサーバーでは機能しません。ステートレスに変更すると動作が異なるステートレスセッションBeanの簡単なHelloWorldタイプの例を誰かに教えてもらえますか？

JNDIを使用して、サーブレットで（ローカル変数として）新しいステートフルセッションBeanを取得しようとしています。私のdoGet()方法は次のとおりです。

インクルードを試みましjava:comp/envたが、すべての試みで名前の例外が発生しました。

との@Statefulようなさまざまな推測を使用して、アノテーションでBeanをバインドしようとしています。@Stateful(name="beanName")@Stateful(mappedName="beanName")

私はショッピング カート スタイルのプロセスで JSF を使用して Java EE Web アプリを開発しているので、多数のページでユーザー入力を収集し、それを使って何かをしたいと考えています。

これには EJB 3 ステートフル セッション Bean を使用することを考えていましたが、調査の結果、SFSB はクライアントの http セッションに関連付けられていないため、httpSession を介して手動で追跡する必要があると思われます。ここ 。. .

1) セッション Bean と呼ばれるのはなぜですか。私が見る限り、セッションとは何の関係もありません。セッションに pojo を格納することで同じことを達成できます。

2) 注入できるということのポイントは何ですか?もし注入するのがこの SFSB の新しいインスタンスだけなら、pojo を使用したほうがよいでしょうか?

JSF はプレゼンテーション テクノロジであるため、ロジックに使用するべきではありませんが、ユーザー入力を収集するための最適なオプションのように思われます。

JSF セッション スコープ Bean をすべてのリクエスト Bean の管理プロパティとして設定できます。つまり、それらに注入されますが、SFSB とは異なり、JSF マネージド セッション スコープ Bean は http セッションに関連付けられているため、同じインスタンスが常に次のように注入されます。 http セッションが無効化されていない限り。

だから私は複数の層を持っています

第 1 層) プレゼンテーションを処理する JSF マネージド リクエスト スコープ Bean。ページごとに 1 つ。
第 2 層) 要求 Bean によって設定された値を持つ JSF 管理セッション スコープ Bean。
第 3 層) JSF セッション スコープ Bean 内のデータに対してロジックを実行するステートレス セッション EJB。

なぜこれがそんなに悪いのですか？

代替オプションは SFSB を使用することですが、それを最初のリクエスト Bean に挿入し、それを http セッションに格納して、後続の各リクエスト Bean で取得する必要があります。

または、すべてをセッションに保存することもできますが、リテラル キーとキャストを使用する必要があるため、これは理想的ではありません。など .. エラーが発生しやすいなど。. . そして乱雑！

私は、このテクノロジーに取り組んでいるというよりは、このテクノロジーと戦っているように感じます。

ありがとう

EJB 3 テクノロジに基づくアプリケーションの開発に問題があります。

セッション Bean で Facade パターンを使用して、エンティティ Bean からクライアント (Web アプリケーション) を分離したいと考えています。

ユーザー セッションの管理に SFSB を使用しています。

だから私はクライアントにメソッド、などFacadeLoginRemoteを公開するリモートインターフェースを持っています...現在、このSFSBには、、などの他のメソッドも含まれています。すべてのユーザーが実際にコースを取得してリソースを取得できるわけではないため、Facade は値をクライアントに返す前にいくつかのチェックを実行します。doLogin()doLogout()getCourse(int id)getResource(int id)

Facade を分割し、メソッドgetCourse()を特別なクラスに配置して、ユーザーの権限をチェックする機能にgetResource()任せたいと思います。FacadeLoginRemote

いくつかの異なる SLSB を作成する場合は、それらをクライアントに公開します。そのため、クライアントは からのチェックを回避して直接接続する可能性がありますFacadeLoginRemote。

私が間違っている？これを行う方法はありますか？

前もって感謝します、

アンドレア

それが である場合、なぜEJBを使用する@ManagedBeanのでしょうか? 以前はショッピング カートと会話状態の維持に使用していましたが、マネージド Bean はユーザー セッション中に保持されるため、そこに状態を保存し、ビジネス ロジックのために SLSB を呼び出すことができます。あれは正しいですか？そうであれば、ステートフルな ejb は、トランザクションが必要な場合など、より具体的なアプリケーションのために残されますか?@SessionScoped@Stateful

奇妙な理由で、次の例外が発生します。

正しいクラスであるため、クラスキャスト例外であってはならないことはわかっています。

コードは次のとおりです。

そしてクラスは

誰かが私が犯した間違いを見つけることができますか?

クラスター化されたJBoss環境の機能をテストするために、いくつかのプロジェクトでバニラJBossAS 6サーバーを使用しています。私が抱えている問題は、ノード内の 1 つの EJB (別のタイプ) から別のノード内の同じタイプのインスタンスに EJB 参照を転送すると、メソッド呼び出し時に例外がスローされ、そのlong_alphanumeric_keyキーが指定された Bean はキャッシュ (InfinispanStatefulCache) に登録されていません。

問題は、転送する必要があるオブジェクトでステートフル アノテーションの代わりにシングルトン アノテーションを使用すると、転送されたオブジェクトが問題なく動作し、それが作成されたサーバーで共有 EJB のメソッドを正常に呼び出すことです。問題は、このケースには HA-Singleton と同じ欠陥があることです。HA-JNDI ツリーのルックアップを介して以前に取得されたすべての転送された参照。

私が達成しようとしていることについての洞察：

私が現在必要としているのは、HA-Singleton のようにノード間でステートフル EJB の単一インスタンスを共有することです。HA-Singleton を使用しない理由は、このタイプのシングルトンの状態がクラスターのマスター ノードで排他的に維持されるため、ノードがシャットダウンまたは失敗した場合、インスタンスの状態が失われるためです。

ステートフル Bean を使用すると、クラスターの状態を維持できるため、ノードで障害が発生したときに状態が失われるのを防ぐことができます。JBoss と Infinispan のキャッシュがどのように機能するかはまだ完全には理解できていませんが、私が読んだ限りでは、@Clusteredアノテーション付きステートフル Bean の状態はクラスター全体に自動的に複製されます。

現在の JBoss バージョンで Singleton と HA-Singleton を使用する際の問題についてはすでに警告されているため、この設計変更の解決に役立つあらゆる種類のドキュメントまたはパターンを歓迎します。

また、Infinispan キャッシュと JBoss クラスタリングがどのように機能するかについての洞察を提供できるドキュメントをいただければ幸いです。これまで私が読んできた資料には、Infinispan の代わりに JBossCache が使用された古い JBoss バージョンが混在していました。

よろしくお願いします、
ドイツ語