Tomcatのクラスローダは、ポリシーに違反している委任

Question

• Question1： 私たちが知っているように、クラスローダがクラスをロードしようとしている、その親クラスローダに委譲要求。ただし、Tomcatでは、共通のlibディレクトリに置かれた同じ名前のクラスを上書きするためにクラスをロードできます。つまり、Tomcat WebappClassloaderは委任ポリシーに従っていません。大会の違反ですか？

• 質問2： 私はクラスを書いて共通のlibディレクトリに入れましたが、明らかにクラスはWebアプリケーション間で共有されています。たとえば、すべてのWebアプリケーションは、クラスの静的フィールドを読み書きできます。さらに、JDKのクラスはBootstrapクラスローダーによって読み込まれ、静的フィールドはすべてのWebアプリケーションによって共有されますが、危険ですか？

Answer 1

この動作は意図的なものであり、Tomcat自体で提供されるライブラリをすべてのWARで個別に上書きすることができます。たとえば、問題を導入したり、他のアプリケーションを壊さずに、コンテナにデプロイされた各アプリケーションごとに異なるバージョンのLog4Jをオーバーライドすることができます。 Tomcatのdocumentationから：多くのサーバアプリケーションと同様

、Tomcatはへのアクセスを持って、許可へのクラスローダー[...]の様々なコンテナの異なる部分、およびコンテナ上で稼働するWebアプリケーションをインストールします利用可能なクラスとリソースの異なるリポジトリへ。このメカニズムは、サーブレット仕様、バージョン2.4で定義された機能、特にセクション9.4と9.6で定義された機能を提供するために使用されます。

これは通常の委任アルゴリズムに違反しますが、これは他のアプリケーションサーバー（JBossなど）でも同様です。

広告。質問2：はい、危険です。あなたは同期について覚えておかなければならず、この変数を誰が変更するかを制御する必要はありません。私はstaticフィールドを完全に避けるだろう。

たとえばEhCacheはCacheManagerを共有できます。これはnet.sf.ehcache.CacheManager#singletonstatic volatileフィールドで実装されています。これですべての問題が発生します。ehcache.jarをTomcatの/libに入れると、期待通りに動作します。しかし、各Webアプリケーションに独自のJARファイルのコピーがある場合、各WebアプリケーションにはCacheManagerクラスのコピーがあるため、共有は機能しません。 1つのアプリケーションだけにehcache.jarがある場合、すべてのアプリケーションがを一緒にパッケージ化したものを除き、CachedManagerの同じインスタンスを共有すると、さらに悪化します。このようなエラーは非常に追跡しにくいです...