0

必要に応じてプレーンな古い 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 を期待していませんか?

4

1 に答える 1

2

まったく影響しません。クラスはクラス、オブジェクトはオブジェクトです。それらは管理されておらず、干渉されておらず、何も起こりません。彼らは決して特別ではありません。

静的シングルトンは静的シングルトンであり、Java は Java です。

知っておく必要があるのは、コンテナーのクラスローダー レイアウトと、デプロイされたアプリケーションおよびリソースとの関係だけです。(たとえば、あるアプリのクラスは別のアプリのクラスを見ることができません。) ほとんどの場合、これはあまり重要ではありません。物事がより複雑になるにつれて、そうなる場合もあります。

しかし、ほとんどの場合、それはただの Java です。

補遺:

これを確認するより良い方法は、単純にクラスをローカリティのブロックにグループ化することです。

EJB を使用する単純な Web アプリケーションを考えてみましょう。

Web アプリケーションは WAR アーティファクトにデプロイされ、EJB は個別にコンテナー内の個別の EJB としてデプロイするか、より可能性が高いのは EAR 内にデプロイできます。アプリケーションを EAR にパッケージ化する場合、WAR も EAR 内にバンドルする可能性があります。したがって、最終的に EAR には WAR と EJB が含まれます。

開発中、この場合、クラスは 3 つのカテゴリのいずれかに属します。

  1. EJB のみに関連するクラス (セッション Bean など)。

  2. WAR のみに関連するクラス (サーブレット クラスなど)。

  3. 両方に関連するクラス (おそらくデータベース エンティティ)。

したがって、それらをパッケージ化する簡単な方法は、3 つの jar ファイルにまとめることです。WAR 用の jar ファイル (実際、これは WEB-INF/classes 内のクラスを含む WAR です)、EJB 用の jar ファイル、および 3 番目のタイプの jar ファイルです。これをライブラリと呼びます。

ビルドの依存関係に関しては、WAR ビルドは lib に依存し、EJB ビルドは lib に依存します。しかし、WAR も EJB も相互に依存しません。これらは直接には何も共有せず、3 つ目のライブラリ jar を介して間接的にのみ共有するためです。lib jar は、WAR にも EJB にも依存しないため、スタンドアロンです。EJB セッション Bean インターフェイス クラスはライブラリ jar に入ることに注意してください (両方の層がそれらに依存しているため)。

耳には、lib jar、WAR、および EJB jar を META-INF dir および application.xml ファイルと一緒にバンドルするだけです。WAR には独自の構造があり、WEB-INF とすべて、EJB jar には META-INF と ejb-jar.xml があります。ただし、lib.jar は WEB-INF/lib ディレクトリになく、EAR バンドルにあるため、コンテナが担当するクラス ローダーのチカネリを使用して、EJB と WAR の両方で共有されることに注意してください。

これは注意することが重要です。たとえば、lib jar に単純な静的シングルトンがある場合、WAR と EJB の両方がそのシングルトンを共有します。これらはすべて同じクラス ローダーの一部であるためです。そのシングルトンを使用するには、通常の Java だけです。特別なことは何もありません。

EJB と WAR が別々にデプロイされた場合、それぞれに独自の lib.jar のコピーが必要になります。Singleton の場合、各モジュールには独自のクラス ローダーがあるため、それらは共有しません。

そのため、他の方法でいくつかの実際の書き込みが必要でない限り、すべてを EAR にバンドルして、EJB 層と WAR 層の両方を単一の統合アプリケーションとして扱う方が簡単です。

補遺2:

Java EE 開発でクラスを使用することについてはあまり話題になりません。それは、他の Java プログラムと同じようにクラスを使用するだけだからです。あなたはここでこれを考えすぎています。

3 つの jar イディオム: war、ejb、lib は、3 つの懸念事項を分離し、依存関係を制限するため、私が長年使用してきたものです。クライアント -> ライブラリ -> EJB。また、クライアントは通常、lib jar と Java のみを必要とするため、ビルドが簡素化されます。Netbeans IDE では、これを管理するのは簡単です。ちょっとした作業で、他の IDE や ant/maven でも簡単です。大きな負担ではありませんが、3つの部分を比較的きれいに保ちます.

依存関係と Jar の管理は、大規模な Java プロジェクトにとって悪夢であり、デプロイ可能なさまざまなアーティファクトを扱う EJB ではなおさらです。私の本では、それを軽減するのに役立つものはすべて勝利であり、真実は、クリーンでスタンドアロンの lib jar が非常に役立ちます。特に、その lib を他のコードと統合して使用する必要がある場合に役立ちます。たとえば、後でリモート EJB または Web サービスを使用して外部 GUI クライアントを作成する場合、lib jar はクライアントが持つ唯一の依存関係です。この jar の利点は、この種のライブラリをセットアップするのに必要なわずかな手間をはるかに上回ります。

最後に、lib jar は、アプリケーションで使用したい他の jar と同様の単なる jar です (ロギングやその他の一般的なサードパーティの jar など)。

于 2011-11-11T00:47:13.507 に答える