3

最近、動的サーブレット構成を使用できるように、アプリをサーブレット 2.5 からサーブレット 3.0 に変換しました。

Spring の SpringServletContainerInitializer を使用して、コード内に存在する WebApplicationInitializer の対応するインスタンスでアプリケーションを初期化しています。このアプローチは Tomcat では機能しますが、Websphere 8.5.0.1 にデプロイする場合、SpringServletContainerInitializer はコードで WebApplicationInitializer インターフェースの実装を見つけることができないため、Spring MVC ディスパッチャー サーブレットは作成されません。

著者がそれを機能させることができなかった1 つのブログ投稿をオンラインで見つけました。

クラス ローダー、クラス ロードの順序をいじり、別の方法でサーブレット 3.0 がコンテナー内で動作することを確認してみましたが、問題ないようです。WAS クラス ローダー ビューアを使用すると、SpringServletContainerInitializer クラスと WebApplicationInitializer インターフェースがロードされていることを確認できますが、WebApplicationInitializer 実装はロードされていません。

Websphereでこれを試した人はいますか? クラスローダの問題かもしれないと考えていますが、最終的にはわかりません。

4

2 に答える 2

3

私はちょうどこの投稿を見ました。クラスローダの問題をデバッグするとき、WebSphere はトレースを提供します。これを有効にすると、何が起こっているか、何が起こっていないかについてより詳細な情報を得ることができます。これは、PMR を開いた場合に IBM サポートが要求する mustgather データで提供されます。しかし、出力を読んで理解するのは簡単です。

http://www-01.ibm.com/support/docview.wss?uid=swg21196187#show-hide "Collecting Data Manually" の下で使用するトレース文字列は次のとおりです。

com.ibm.ws.classloader.*=all

于 2013-06-19T16:02:03.950 に答える
1

私はまったく同じ問題を抱えていました。この問題は、次の APAR http://www-01.ibm.com/support/docview.wss?uid=swg1PM85177によって修正された WebSphere の欠陥です。WebSphere は注釈のキャッシュを構築します。キャッシュがいっぱいになると、以前にキャッシュされた注釈が破棄されるため、SpringServletContainerInitializer が WebApplicationInitializer のすべての実装を見つけられなくなります。

この APAR は 8.0.0.8 ですでにリリースされており、4 月 28 日に予定されている 8.5.5.2 で予定されています。その間、キャッシュのサイズをデフォルトの 2000 から 16000 (4000 & 8000 で失敗) に増やすことができ、その時点でアプリケーションが動作し始めました。キャッシュ サイズは WebSphere ノードの JVM のシステム プロパティによってオーバーライドされるため、1 つのサイズがすべてに適合するわけではありません。アプリケーションの正しい値が決定されるまで、この設定を試すことが重要です。

私が使用した JVM システム プロパティは -Dclassinfocachesize=16000 です。

于 2014-03-19T23:41:44.823 に答える