プラグインによるJava Webアプリケーションの拡張

Question

手に負えない混乱に成長したこのWebアプリケーションがあります。

一般的な「フレームワーク」に分割したい一部（まだページや画像などのWebのものが含まれています）および追加の機能と画面を追加するいくつかのモジュールこのリファクタリングは、サードパーティの拡張機能のプラグインシステムとしても役立つことを望んでいます。

すべてのモジュールは、個別のデプロイメントユニット、理想的にはwarまたはjarファイルである必要があります。

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

＆quot; main＆quot;を表示するにはプラグインが必要です。クラスパス。

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

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

「メイン」の下に根を下ろしてほしいアプリケーションURLプレフィックス。ただし、必須ではありません。

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

Answer 1

私は、あなたが説明しているのと同じ問題を解決するためにOSGiを使用するという考えをいじっていました。特に、 Spring Dynamic Modules の使用を検討しています。

Answer 2

Javaポートレットをご覧ください- http://developers.sun.com / portalserver / reference / techart / jsr168 / -要するに、自己完結型のj2ee Webアプリケーションとの相互運用性を可能にする仕様です

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

Answer 3

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

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

同じ単一のWebアプリ（たとえばROOT）の下に物事を保持したい場合、ユーザーが比較的透明にするためにバックグラウンドで関連する他のWebアプリに転送するプロキシWebアプリを作成できますか？

Answer 4

主な問題は、システムの物理的、静的な資産に集中することです。残りは、単に、効果的に、jarです。

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

Glassfishでは、WARがEARにバンドルされている場合、それらはクラスローダーを共有します（GFはEARでフラットクラスローダースペースを使用します）が、まだセッション状態は異なります。

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

したがって、Webアプリのこれらの機能は、コンテナ内に同種に展開しようとすることに対して陰謀を企てます。

むしろ、ホットなヒントは「アセンブラ」を作成することだと思います。個々のモジュールと「マージ」を行うユーティリティ。それらを単一のWebアプリに追加します。 web.xml、コンテンツのマージ、jarおよびクラスの正規化などが可能です。

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

Answer 5

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

別のWARに転送できる限り、そのWARに転送できます。

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

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

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

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

BR、
〜A

Answer 6

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

メインアプリケーションは、サービスを提供するWebアプリケーション（プラグイン）へのURLで構成されます。

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

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

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

プラグインが同じデータベースで機能する場合は、キャッシュ時間を制限するか、戦争をスパンするように設定してください キャッシングレイヤー。

Answer 7

また、実行時にプラグイン（またはモジュール）を追加し、既存の実行中のwebappを強化できる共通または抽象的なフレームワークを開発しようとしています。

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

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

OSGIまたはSpring Dynamicモジュールは優れていますが、現時点では非常に複雑に見えます。気がついたらもう一度調べます。

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

たぶん、展開時にプラグインのjarを使用して、正しいディレクトリにファイルをコピーできます。

Answer 8

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

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

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