3

これは非常に初歩的な質問かもしれませんが、これがよく知られており、他の場所で解決されている場合は、私を助けてください.

Tomcat インスタンスにデプロイする必要がある 2 つの WAR として、複数の戦争のセットアップ (すべての Maven モジュール) がkilo-webapp1あります。kilo-webapp2これら 2 つの Web アプリケーションは両方とも、共通のサービス jar のサービスを使用しますkilo-common-services.jar。にはkilo-common-services.jar、jar viz のユーザーによってロードされる独自のスプリング コンテキストがあります。kilo-webapp1そしてkilo-webapp2この場合。キロコモンサービスでのサービスの初期化には長い時間がかかることがあるため、(インスタンスの起動にかかる時間があまり長くないようにするために) 1 回だけ実行したいので、これも役立ちます。 JVMインスタンスで最新の状態に保つ第2レベルのキャッシュとして使用します。これを行うために、次の手順に頼りました。

  1. tomcat の CATALINA_BASE の catalina.properties を次のように変更しますshared.loader。${catalina.base}/shared/lib
  2. kilo-common-services.jarおよびそのすべての依存 jar を にコピーしましたCATALINA_BASE/shared/lib。【手動ステップ】
  3. spring関連のjarをそのCATALINA_BASE/shared/lib場所にコピーする[手動ステップ]
  4. beanRefContext.xmlでファイルを作成しましたkilo-common-services.jar。ClassPathXmlApplicationContextここで、コンストラクターに共通サービスのスプリング コンテキスト ファイルの場所が提供された場所を定義します。
  5. およびpom ファイルのように、kilo-common-services.jarおよびその他すべての依存関係 (Spring 関連の jar など)の依存範囲に注意してください。Spring の場合、これは、クラスパス スキャン アクションが 2 回トリガーされないようにするために必要です。また、スコープを介して除外されていない場合、これにより異なるs (log4j の場合) が発生します。providedkilo-webapp1kilo-webapp2ClassCastExceptionprovided
  6. kilo-webapp1およびのweb.xmlkilo-webapp2は、それらの parentContext が でservicesContext定義されていることを示していkilo-common-services.jarます。

キロコモンサービスのサービスが1つしか存在しないことは確認できましたが、ご想像のとおり設定が面倒です。誰かが Eclipse のような IDE でのこのようなセットアップに関するベスト プラクティスを持っている場合は、本当に感謝しています。私の問題は以下の通りです：

  • ＃2は挑戦になりつつあります。私は現在、依存する jar を から にコピーしようとmvn dependency:copy-dependenciesし ていますが、 これは非常に手動のステップです。何度も依存関係を再生成するのを忘れて、再デプロイをしなければなりません。kilo-common-servicestarget/dependencyshared/lib
  • ＃3も簡単ではありません。新しい一般的な依存関係が何度もあり、ClassCastExceptionsを回避するために共有ライブラリにコピーすることを常に忘れないでください。
  • #5 もメンテナンスの悪夢です。

また、時間が経つにつれて、共有する必要のある異なる一般的な jar が増え、これらの jar のそれぞれに苦痛が伴います。セットアップを自由に批評し、使いやすい (IDE からも) より良いものを代わりに提案してください。他の詳細を提供していただければ幸いです。

前もって感謝します！

4

2 に答える 2

2

問題は、アーキテクチャが壊れていることです (そのため、ソリューションに苦労しています)。次の 2 つの解決策があります。

1) 2 つの war アプリケーション間で(初期化に) 時間がかかるサービスを共有したい場合は、それを完全に別のサービスにして、残りまたは任意の種類のリモート経由でアクセスします。

2) 両方の Web アプリケーションを 1 つにマージします。

共通ライブラリを共有 lib フォルダーにすると、多くの頭痛の種になり、最終的にロールバックすることになります。

私の（個人的な）アプローチは、両方のアプリケーションをマージすることですが、パッケージを十分に分離し、別々のスプリング構成を持たせることです。このようにして、少なくとも両方の Web アプリケーションのロジックの分離を維持できます。また、両方とも同じコンテナーで実行されるため、2 つの別個の戦争を行うことによるメリットはほとんどありません (すぐに別のコンテナーに移動する予定がない限り)。

IDE については、maven-cargo-plugin を使用して、(ほぼ) 任意の構成で複数の Web アプリケーションを含む tomcat を起動できます。

于 2012-12-28T10:12:54.973 に答える
0

Spring と Tomcat を使用し、Domain Driven Design を利用して、安らかな soa を開発しています (とにかくそれが計画です)。migrationProject と初期の基本検索サービスがあります。2 つの別個の POM を持つ 2 つの別個の WAR ファイル。どちらも同じ Domain オブジェクトを使用します。

そのため、DomainObjects だけの別のプロジェクトを jar にラップし、maven や jenkins を使用して自動的に展開します (構成するたびに (たとえば、特定のリポジトリにプッシュするとき))。

同じ jar のコピーを 2 つ持つことは、私にははるかに悪い考えのように思えます。壊れているのはあなたのアーキテクチャではなく、改善が必要な展開と開発プロセスです。

（私の種類の関連する質問）。

私たちの長期的な計画は、依存関係から注入されたサービス クラスとリポジトリを持つ複数のコントローラーを使用して、1 つのプロジェクトを安らかなインターフェイスとして使用することです。

于 2012-12-28T11:49:41.210 に答える