7

この Web アプリケーションは、管理不能な混乱にまで成長しました。

私はそれを共通の「フレームワーク」部分 (ページや画像などの Web 要素をまだ含む) と、追加の機能と画面を追加するいくつかのモジュールに分割したいと考えています。このリファクタリングは、サードパーティの拡張機能のプラグイン システムとしても役立つようにしたいと考えています。

すべてのモジュールは、展開の個別の単位である必要があり、理想的には war または jar ファイルです。

いくつかの通常の war ファイルを作成しようとしましたが、Tomcat は (サーブレットの仕様に従って) これらの war ファイルを互いに完全に分離しているため、たとえばクラスを共有できません。

「メイン」クラスパスを表示できるようにするには、プラグインが必要です。

プラグインを一覧表示したり、構成を設定したりできるように、プラグインをある程度制御するには、アプリケーションをメインにする必要があります。

プラグイン自体 (依存関係を指定しない限り) と、同じ Tomcat で実行されている可能性のある他の無関係な Web アプリケーションとの間の完全な分離を維持したいと考えています。

「メイン」アプリケーション URL プレフィックスの下にルートを設定したいのですが、それは必須ではありません。

私は Tomcat を使用したいと思っています (大きなアーキテクチャの変更は、あまりにも多くの人々と調整する必要があります) が、EJB または OSGi の世界でのクリーンなソリューションについても聞きたいです。

4

8 に答える 8

4

OSGi を使用して、あなたが説明している同じ問題を解決するというアイデアをいじくり回しています。特に、Spring Dynamic Modulesの使用を検討しています。

于 2008-10-03T23:44:23.710 に答える
3

Java ポートレットを見てみましょう - http://developers.sun.com/portalserver/reference/techart/jsr168/ - 簡単に言えば、自己完結型の j2ee Web アプリケーション間の相互運用性を可能にする仕様です。

編集 ポートレットはほとんどフレームワークに依存しないことを忘れていました。そのため、Spring を親アプリケーションに使用でき、個々の開発者はポートレットで必要なものを何でも使用できます。

于 2008-10-04T09:40:01.463 に答える
1

Maven を使用してプロジェクトを分離し、WAR と JAR の間の依存関係を解決することを検討しましたか? WAR 間でライブラリが重複することになりますが、それは必要な場合に限られます (ファンキーなクラスローダーの楽しみに取り組まない限り、これは問題になりません)。

Tomcat では、ある WAR から別の WAR に比較的透過的な方法で移動する必要がある場合に、クロス コンテキスト アプリケーションを構成することもできます...

物事を同じ単一のWebアプリ(ROOTなど)の下に保持したい場合は、ユーザーが比較的透過的になるように、舞台裏で関連する他のWebアプリに転送するプロキシWebアプリを作成できますか?

于 2008-10-03T23:47:16.747 に答える
1

あなたの主な問題は、システムの物理的で静的な資産を中心にしています。残りは、単純に、事実上、jar です。

Tomcat では、WAR は個別のクラスローダーで分離されていますが、セッション レベルでも分離されています (各 WAR は個別の Web アプリであり、独自のセッション状態を持っています)。

Glassfish では、WAR が EAR にバンドルされている場合、それらはクラスローダーを共有しますが (GF は EAR でフラット クラス ローダー スペースを使用します)、別のセッション状態を保持します。

また、サーバー内の別の WAR に「転送」できるかどうかもわかりません。問題は、転送が Web アプリのルートへの相対 URL を使用し、各 Web アプリに独自のルートがあるため、単純に「ここからそこに到達できない」ことです。リダイレクトできますが、それはフォワードと同じではありません。

そのため、Web アプリのこれらの機能は、コンテナー内に均一にデプロイしようとする試みに対して陰謀を企てます。

むしろ、個々のモジュールを取得して単一の Web アプリに "マージ" する "アセンブラー" ユーティリティを作成することをお勧めします。web.xml やコンテンツをマージしたり、jar やクラスを正規化したりできます。

WAR は、Java の世界では機能でありバグです。コンパイルされたアプリケーションをインストールするという点で「ドラッグアンドドロップ」でデプロイできるので、私はそれらが大好きです。その機能は、遭遇したものよりもはるかに多く使用されています。しかし、私はあなたの痛みを感じます。アプリ間で共有する共通の「コア」フレームワークがあり、基本的にそれを維持するために継続的にマージする必要があります。スクリプトを作成しましたが、まだ少し面倒です。

于 2008-10-03T23:49:10.347 に答える
1

「また、サーバー内の別の WAR に「転送」できるかどうかもわかりません。問題は、転送が Web アプリのルートへの相対 URL を使用し、各 WebApp が独自のルートを持っていることです。あなたは単に「ここからそこに着くことができない」. リダイレクトすることはできますが、それはフォワードと同じではありません.

そのWARが誰かにそれを許可する限り、別のWARに転送できます。

glassfish と EAR の複数の WAR : それは理にかなっています。

MAIN クラスを tomcat の共​​有 CLASSPATH に配置すると、個々の PLUGIN を個別の WAR ファイルに配置できます。

Main アプリは、server.xml で定義する TOMCAT サーブレットの一部にすることもできます。これは MASTER SERVLET にすることができ、他のすべての WAR はこのマスター サーブレットによって制御できます。

それは理にかなっていますか ?

BR、
~A

于 2008-10-04T02:24:46.990 に答える
0

プラグイン機能の複雑さに応じて、たとえば Axis で実装された Web サービスも検討します。

メイン アプリケーションは、サービスを提供する Web アプリケーション (プラグイン) への URL を使用して構成されます。

私が見ているように、利点は2つあります。

  • 2 つの戦争の間に、きれいでデバッグ可能な API、つまり Soap/XML メッセージが得られます。
  • アプリケーション全体の回帰テストを行うことなく、単一のプラグインをアップグレードできます

短所は、いくつかの Axis プロジェクトをセットアップする必要があることと、ある種のプラグイン構成が必要なことです。さらに、サービス Web アプリケーションへのアクセスを制限する必要がある場合があるため、少し設定が必要になる場合があります。

プラグインが同じデータベースで動作する場合は、必ずキャッシュ時間を制限するか、war-spanning キャッシング レイヤーを構成してください。

于 2008-10-04T09:27:48.680 に答える
0

また、実行時にプラグイン (またはモジュール) を追加し、既存の実行中の webapp を強化できる共通または抽象フレームワークの開発も試みています。

さて、あなたが言ったように、WARまたはJARファイルを使用してそれを行う方法を優先しました。WAR ファイルの問題は、既存のアプリにプラグインとしてデプロイできないことです。Tomcat はそれを別の Web コンテキストとしてデプロイします。望ましくない。

もう 1 つのオプションは、JAR ファイルにカスタム コードを記述して、その JAR ファイルを WEB-INF/lib フォルダーにコピーし、クラスを既存のクラスローダーにロードすることです。問題は、JSP や構成ファイルなどの Java 以外のファイルをデプロイする方法です。そのためには、2 つの解決策があります。JSP の代わりに速度テンプレートを使用します (b.) カスタム コードを記述して、コンテキスト パスではなくクラスパスから JSP を読み取ります。

OSGI または Spring Dynamic モジュールは優れていますが、現時点では複雑すぎるように見えます。気が向いたらまた調べてみます。

プラグインのライフサイクルを管理し、パッケージ化された JAR ファイルで JSP を使用できる単純な API を探しています。

おそらく、展開時にプラグインの un jar を使用して、ファイルを適切なディレクトリにコピーできます。

于 2009-04-22T12:58:22.153 に答える
0

アプリケーションを個別のモジュールに分割することを考えている場合、実際には OSGI に勝るものはありません。Greenpages の例を見てください。アプリケーションに必要な jar を含む親モジュール (コア) を作成できます。

コンポーネント プログラミングについて少しでも知っていれば、OSGI モジュールがインターフェイスのように動作し、他のモジュールで使用するものを公開する必要があることがすぐにわかります。理解すればとても簡単です。いずれにせよ、OSGI の使い方を学ぶときは、本当につらいこともあります。モジュールに jar として追加した Jackson のバージョンが、Spring コア モジュールに含まれる他の jar によってオーバーライドされたため、JSON の使用に問題がありました。必要に応じて、どのバージョンの jar がロードされているかを常に再確認する必要があります。

残念ながら、OSGI のアプローチでさえ、私たちが探しているものを解決することはできません。実行時に永続モデルと既存のフォームを拡張する方法。

于 2012-08-15T20:59:29.663 に答える