4

私の WebSphere 8 アプリケーション サーバーでは、デフォルトのクラス ロード順序はparent_first です(アプリケーション サーバー クラス ローダーからロードを試み、次に EAR クラス ローダーからロードを試みます)。
これにより、アプリでの Apache の HttpClient の使用と WebSphere の内部使用との間に衝突が発生します。
読み込み順序をparent_last（ WebLogicではprefer-web-inf-classes）に切り替えることを検討しています。

Java EE アプリ クラスのロード順序を parent_last に変更する際に注意すべき落とし穴は何ですか?

4

2 に答える 2

2

何もないはずです。

を使用PARENT_LASTすると、WebSphere のものと競合するクラスや jar を使用してアプリケーションを配布できます。この設定はClassClassException、互換性のない 2 つの異なるクラスローダーが、WebSphere AS とアプリケーションにあるクラスをロードするときに常に使用されます。

クラス・ローダーのモード -PARENT_FIRSTおよびPARENT_LAST- については、WebSphere Application Server 8.0 インフォメーション・センターのクラス・ローダーで説明されています。

アプリケーション内に jar をバンドルする傾向があるため、デプロイメントが長くなり、メモリ消費量が増え、(ライブラリの) 管理が難しくなります。

共有ライブラリ (または OSGi リポジトリ) に関する限り、管理者が何を設定する必要があるかを説明する必要がないように、開発者がアプリケーション内にすべてを保持する方が明らかに簡単です。

PARENT_LASTアプリケーション内でjarを配布することが良いことであると想定しない限り、 が役立つケースは考えられません(その点については議論します)。

アプリケーション内の jar が少ないほど、次のようになります。

  1. アプリケーションは、メンテナンスを容易にする共有ライブラリまたは OSGi リポジトリを介して問題が修正されたときに、その jar をアップグレードすることで利益を得ることができます
  2. アプリケーションは、メモリの期待値を下げ、再利用性を促進するライブラリを共有できます (明らかに展開が速くなります)

PARENT_LASTアプリケーション内に jar をバンドルしない理由が他にもあり、構成設定がさらに減少する可能性があります。

彼らが乗り換える理由があると言うまでは我慢PARENT_FIRSTして、それが起こったら答えを見せてください ;-)

于 2013-01-17T10:49:40.783 に答える
1

IBM Software Developers Kit（SDK）for Javaの理解から >クラスのロード：

[委任モデル]は、コアAPIの一部として同じ名前を想定することにより、信頼性の低いソースからのコードが信頼性の高いコアAPIクラスを置き換えることを防ぎます。

そのPARENT_LASTため、バージョンの非互換性のためにアプリが基本クラスをオーバーライドする必要がある場合に存在するようですが、これを行うと、セキュリティも弱くなる可能性があります。

于 2013-01-17T13:41:38.303 に答える