1

同じ JBoss サーバーにデプロイしたい複数の EJB を持ついくつかの個別のアプリケーション プロジェクト (EAR) があります。現在、一部のプロジェクトは、同じ EJB を使用している場合がありますが、バージョンは異なります。同様の状況で、一部のプロジェクトは、同じ「通常の」クラス (つまり、JNDI ルックアップなしで VM 内にロードされたクラス) の異なるバージョンを使用する場合があります。

OC4J では、これは問題ではなかったようですが、JBoss では、すべてが同じ「名前空間」(またはおそらくクラス ローダー) に存在するという印象を受けます。私はこの仮定で正しいですか？

基本的に、私がやりたいこと (または確実にしたいこと) は次の 2 つです。

  • EJB の JNDI ルックアップを実行するクライアントから、EJB の正しいバージョンが返されるように、EJB が存在するアプリケーションを示すことができるようにしたいと考えています。

  • EJB 内からクラスをインスタンス化するとき、そのクラスが、EJB と同じアプリケーション (EAR) でデプロイされたものであることを確認したいと考えています。

EJB の「分離」プロパティを構成できると読んだと思いますが、2 番目のポイントを解決できる可能性があると思いますか?

4

2 に答える 2

6

JBoss のデフォルトの動作は、フラットなクラスローダーを使用することです。これによりフットプリントが削減されますが、お気づきのように、複数のアプリケーションを展開するのが面倒になります。

ありがたいことに、修正は簡単です。ディレクトリ内のear-deployer.xmlファイルでdeploy、次のパラメータが設定されていることを確認します。

<attribute name="Isolated">true</attribute>

これにより、デプロイされた各 EAR に独自のクラスローダー スペースが与えられます。JBoss lib ディレクトリからアクセスすることはできますが、デプロイされた EAR は互いに見えなくなります。

于 2009-07-17T08:48:37.307 に答える
3

異なるEARのクラスが同じ「スペース」に存在することは正しいです。JBoss はデフォルトでフラットなクラスローダー階層を使用します。これは、すべてのクラス (WAR パッケージ化されたものを除く) が同じクラスローダーによってロードされることを意味します。JBoss 5 の導入により、Java EE ルールに厳密に従うため、分離されたクラスローディングをサポートする新しい標準プロファイルがあります。古いバージョンの JBoss も、 callByValueを通じてこの動作をサポートし、デプロイヤ設定のプロパティを分離します。

于 2009-07-16T18:43:12.767 に答える