EJB で動作する Java アプリがありますが、次の場合:
- EJB が更新され、アプリが壊れています。
- アプリサーバーが更新され、アプリが壊れています。
人間の関与なしで、アプリ サーバーと Bean のクライアント jar を更新するための推奨される方法はありますか?
推奨される方法がアプリ サーバーに依存する場合は、jboss を想定します。
EJB で動作する Java アプリがありますが、次の場合:
人間の関与なしで、アプリ サーバーと Bean のクライアント jar を更新するための推奨される方法はありますか?
推奨される方法がアプリ サーバーに依存する場合は、jboss を想定します。
これが、人々が Web サービスに移行している理由の 1 つです:) または、JMS も使用してください。
実際、アプリ サーバーがアップグレードされたり、ベンダーが変更されたりした場合、古い/外部のスタブがサーバー側の新しいコードで機能する方法はありません。:-(
アプリケーション デプロイヤー ロールが必要であると宣言された EJB を覚えていますか? クライアント アプリケーション用の client.jar を準備して配布するのは彼次第です (または、アプリケーション パッケージャーであるかどうかは関係ありません。重要なのは、自動操作ではないということです)。
いくつかのトリックは可能かもしれません (client.jar をサーバー上の特定の場所に配置して、最初にクライアントがダウンロードするように要求し、次にクラスローダーを使用して使用するように要求するなど)、それらは確立された慣行よりも多くのハックです。
JBoss の詳細については、情報がありません。
あなたの基本的な問題は、1 つのコンポーネント間のインターフェイス コントラクトが変更されると、他のコンポーネントが破損することです。これはアプリや EJB に限定された問題ではなく、コンパイラに対して安全ではありません。
私が知っている唯一の自動化されたアプローチは、App プロジェクトが EJB プロジェクト (IDE およびビルド ファイル内) に依存するようにプロジェクトをセットアップし、コンパイラ チェックを提供することです。そしてそれらを EAR として一緒にデプロイします。
それがオプションではなく、それらを個別にデプロイする必要がある場合、EJB 開発者は下位互換性のあるインターフェースをそのまま維持することについて、彼のゲームに取り組む必要があります。