EJB モジュール、Web モジュール、およびいくつかの JAR (私自身とサードパーティの両方のライブラリ) で構成されるアプリケーションがあります。EAR ファイルとしてパッケージ化されています。ライブラリは「libs」ディレクトリにあり、EJB マニフェスト ファイルのクラスパスに含まれています。Web モジュールは、依存関係を含めたり、クラスパスを指定したりせずにパッケージ化されます。
The EAR content (simplified):
/libs/model.jar
/libs/other.jar
ejb.jar
web.war
Web モジュールに @Stateless Bean があり、@EJB の注入によって EJB モジュールから Bean をルックアップします。セキュリティは、model.jar の ActiveUser クラスの ThreadLocal によってユーザー ロールにアクセスしてチェックすることによって実装されます。私の @stateless Web Bean は、@PostConstruct アノテーションが付けられたメソッドでいくつかのキャッシュを初期化します。Security モジュールを満たすために、ActiveUser の ThreadLocal にシステム資格情報を設定することから始めます。次に、挿入された EJB でメソッドを呼び出し、キャッシュのデータを返します (ActiveUser の資格情報を確認した後)。
アプリケーションを (weblogic maven プラグインを使用して) デプロイすると、すべてが魅力的に機能します。
次に、アプリケーションを再デプロイします (ここでも weblogic maven プラグインを使用します)。私はWebLogicのドキュメントを読みましたが、ここでは、再デプロイ時に古いクラスローダーが破棄され、新しいクラスローダーがインスタンス化されることが強調されています(クラスローダーによってロードされたクラスをアンロードまたは更新する方法がないため)。しかし、Web モジュールが @PostConstruct 内のキャッシュのデータを読み取ろうとすると、ユーザーが適切に認証されていないと EJB が訴えるため、私の再デプロイは失敗します。
コードをデバッグした後、Web モジュール Bean が「古い」クラスローダによってロードされた ActiveUser クラス定義をまだ使用していることがわかりました (オブジェクト ID は古いクラスローダのものと同じです)。EJB Bean は、新しいクラスローダーによってロードされた ActiveUser クラス定義を使用します。したがって、もちろん、ThreadLocals はもはや同じオブジェクトではありません。また、この特定の状態の結果として、多数の ClassCastExceptions が発生する可能性があることも想像できます。
この古い「ゴースト」クラスローダがまだアクティブなのはなぜですか? WLS-cat アプリケーションを使用してアプリケーションのクラスローダー ツリーを調べたところ、ここには新しいクラスローダーのみが存在し、古いクラスローダーの痕跡はありません。
行動方針について何か提案はありますか？誰もこれを経験しましたか？
管理対象サーバーを再起動すると、アプリケーションは問題なく起動しますが、再デプロイのたびに再起動する気はありません。夜間スナップショット ビルドを毎晩再デプロイし、統合テストを自動的に実行したいのですが、weblogic maven プラグインには目標がありません。サーバーの再起動。