問題タブ [stateless-session-bean]

I was reading about stateless session bean and couldn't understand it's use.

Excerpt from sun tutorial below

"..Because stateless session beans can support multiple clients, they can offer better scalability for applications that require large numbers of clients"

Where stateless session bean is being used? what kind of applications use it?

What mechanism has been being used before the advent of 'stateless session bean' to support multiple clients in the similar contexts?

Can anyone please provide some details?

thank you!

まず、Java SEをしばらく使用している間、これがJavaEE領域への最初の進出であることを指摘しておきます。私はNetbeans6.9とNetbeansコードジェネレーターを使用して、大部分の手間のかかる作業を行っています（これについてはさらに詳しく説明します）。GlassFishのバージョンは3です。これは、Netbeansをダウンロードしたときに出荷される標準的なものです。

次のように単純な文字列を返すステートレスセッションBeanを作成しました。

インターフェイス定義は次のとおりです。

クラスとインターフェースはどちらも、Netbeansが提供する「コードの挿入」機能を使用して作成されました。私はこのように私が愚かな初心者のエラーをしないように考えています（皮肉なことに）。

私の問題は、サーブレットからEnterprise Beanを呼び出そうとすると（Netbeansコードジェネレータの「CallEnterprise Bean」オプションを使用して呼び出しが追加された）、次のエラーが発生することです。

例外の原因は次のとおりです： NoClassDefFoundError

これは、サーブレットが呼び出しを行う方法です。

広範囲にわたるグーグルの後で、この問題の解決策を見つけることができなかったのではないかと思います（主に、この問題に近づいているように見えるいくつかのフォーラム投稿には、解決策をたどるには専門用語が多すぎるためです）。

私を正しい方向に向けるアドバイス/助けをいただければ幸いです。

EJB に関する質問:

無限ループを持つセッション Bean があるとします。EJB トランザクションで実行されています。EJB のトランザクションがタイムアウトすると、無限ループ スレッドが中断するか、コンテナが無限ループを実行しているスレッドを停止します。

静的メソッドを使用した単純な pojo よりも、ステートレス Bean と依存性注入を使用する方が有益なのはなぜですか? 言い換えれば、EJB の利点は、スレッド化、トランザクションなどの基礎となるコンテナの利点だけにあるのでしょうか?

ステートレス EJB がプールに格納され、必要に応じてインスタンス化されることは知っています。私の質問は、EJB 依存関係がさらにある場合、たとえば次のような場合にどうなるかということです。

EJB_A と EJB_B もステートレス EJB です。

最悪の場合、まったく同時に 2 つの要求がある場合、サーバーはプールから Master_EJB の 2 つのインスタンスを取得します (または、必要に応じて作成します)。

しかし、これら 2 つの呼び出しのうち、一方が EJB_A のみを必要とし、もう一方が EJB_B のみを必要とする場合、必要なインスタンスの数は 4 (2 つの Master_EJB + 1 EJB_A + 1 EJB_B) または 6 (2 Master_EJB + 2 EJB_A + 2 EJB_B) になりますか?

セッション Bean でユーザー名を正しく取得する方法を誰か教えてもらえますか? 私たちのアプリケーションでは、次のメソッドを呼び出してそれを行います。

そして、これはすべてがうまくいくまでうまくいきます。しかし、500 または 404 エラーが発生し、ユーザーを対応するページ (web.xml で設定) にリダイレクトすると、このメソッドはユーザー名として「WLS KERNEL」を返します。この場合、正しいユーザー名を取得するにはどうすればよいですか?

Hibernate の merge() メソッドでオブジェクト ツリーを保存しようとしています。エンティティAuftrag(英語で「注文」を意味する) には、Auftragspositionでマッピングされたオブジェクトのコレクションが含まれていcascade="all-delete-orphanます。

永続化は、RMI を介して呼び出されるステートレス セッション Bean で行われます。Sessionこのメソッドは、新しい (クリーンな)インスタンスを開きます。既存の注文が保存されると、merge() は DB からエンティティをロードしようとし、次に、ロードされた依存注文の位置をセッションの永続コンテキストに関連付けます。その後、merge() 操作が注文位置にカスケードされると、NonUniqueObjectException が発生します (一時的な注文位置が Hibernate でロードされた位置と異なるため)。

saveOrUpdate() も同様の結果をもたらします。

インテリジェントな (1 行または可能な限り少ないコード行) ソリューションは存在しますか? それとも、オブジェクト ツリーを再帰的に処理し、(セッションに関連付けられているように) 一時オブジェクトを最初に保存するなど、その動作を回避する必要がありますか?

AuftragEntityPersister(PS: 私は今、その例外を取得しました。これは、おそらくその問題を回避するために、オブジェクト ツリー全体をデータベースから削除し、再度挿入したという名前の古いカスタムメイドのサブクラスをスローしたためです。)

参照。例外スタックトレース:

ユーティリティ クラスで Local Stateles セッション Bean インスタンスを検索する際に問題が発生しています。常に ClassCastException が発生します: $ProxyXYZ (XYZ は任意の数字)

Glassfish 3.1.1、JPA 2、EJB 3、JSF2 を使用しています。

すべてが耳のアーカイブにパッケージ化されています。

プロジェクトでは Bean Validation も使用するため、バリデータ クラスの 1 つで、Statateless セッション Bean のインスタンスを取得しようとします。バリデータは次のように定義されます。

セッション Bean:

Proxy クラスのインスタンスを取得するため、ルックアップ プロセスはうまく機能しますが、それをセッション Bean にキャストすることはできず、このバリデーターが実行されると、次の例外が発生します。

また、バリデータ クラスを次のように定義しました。

しかし、同じエラーが発生します。

何か案は？

私の EJB プロジェクトには、次のセッション Bean (ステートフル) があります。

インターフェイス StatefulShopCartLocal:

アプリケーション クライアント プロジェクトでルックアップを行うと、次のようになります。

次のエラーが表示されます。

そのセッション Bean のシリアル化に問題があると思いますが、何が間違っているのでしょうか?

ありがとう。

必要に応じてプレーンな古い Java オブジェクト (POJO) と通常のクラス ファイルを使用し、非同期呼び出し、プーリングなどの追加機能が必要な場合にのみ EJB を使用しようとしています。サーバーがどのように処理するのか疑問に思っています。プロジェクトがサーバーにデプロイされると、この動作になります。コンテナーによって管理されないため、そのメソッドの 1 つを呼び出す可能性がある、プールされたステートレス セッション Bean ごとに新しいインスタンスを作成する必要がありますか? 静的メソッドや状態などは、このモデルにどのように影響しますか。

編集：

1) もっと明確にすることができます。Java EE のポイントは、POJO に @stateless などのアノテーションを付けて、コンテナで管理できるようにすることです。注入したばかりのステートレス Bean の新しいインスタンスを宣言する必要はなく、その型を呼び出すことができます。

2) ほとんどの Java EE のチュートリアルや書籍では、ビジネス ロジックの一部として、アノテーションのないクラスについては言及されていません。それは決して育てられていません。ビジネスロジックのJava EEプロジェクトでそれらを使用でき、サーバーにデプロイできる場合、これは奇妙に思えます。プーリングや非同期アクセス (コンテナーが EJB を介してマネージャーを支援するもの) が必要ない場合は、Java EE プロジェクトでこれらの通常の POJO を使用できます。

3) それは、プロジェクトに適切に組み込むにはどうすればよいかという私の質問に私を導きますか? それらを EAR に接続された EJB プロジェクトに入れるべきですか、それとも EAR に入れる必要がありますか? または動的 Web プロジェクト。このような通常のオブジェクトの適切な使用に関する言及や指示はほとんどありません。展開用に WAR にコンパイルされると、サーバー上で何か問題が発生しますか? 適切にアノテーションが付けられた EJB、サーブレット、または JSP を期待していませんか?