JSF/フェイスレット/スプリングアプリケーションをOSGIでモジュール化する方法は？

StackOverflow https://stackoverflow.com/questions/2575669

質問

DI/Bean管理にSpringを使用する非常に大きなJSF/Faceletsアプリケーションを使用しています。私のアプリケーションにはモジュール構造があり、現在、モジュール化を標準化するアプローチを探しています。

私の目標は、多くのモジュール（おそらく相互に依存する）からWebアプリケーションを作成することです。各モジュールには次のものが含まれている場合があります。

  • クラス;
  • 静的リソース（画像、CSS、スクリプト）;
  • フェイステンプレート。
  • マネージドビーンズ - リクエスト、セッション、アプリケーションスコープ付き豆を備えたスプリングアプリケーションコンテキスト（代替手段はJSFマネージドビーンズです）。
  • サーブレットAPIスタッフ - サーブレット、フィルター、リスナー（これはオプションです）。

私が避けたいのは（ほぼすべての犠牲を払って）、モジュールのリソースをコピーまたは抽出する必要があります（フェイスラットテンプレートなど）、または拡張する必要があります。 web.xml モジュールのサーブレット、フィルターなどの場合は、モジュール（JAR、バンドル、アーティファクトなど）をWebアプリケーション（）に追加するのに十分である必要があります。WEB-INF/lib, bundles, plugins, 、...）このモジュールでWebアプリケーションを拡張します。

現在、このタスクは、ClassPathリソースの使用に大きく基づいているカスタムモジュール化ソリューションで解決します。

  • Special Resources Servletは、ClassPath Resources（JARS）の静的リソースを提供します。
  • 特別なフェイスラットリソースリゾルバーにより、クラスパスリソースからフェイスラットテンプレートを読み込むことができます。
  • スプリングロードパターンを介してアプリケーションのコンテキストをロードします classpath*:com/acme/foo/module/applicationContext.xml -これにより、モジュールジャーで定義されたアプリケーションコンテキストがロードされます。
  • 最後に、モジュールからSpringアプリケーションコンテキストで構成されたサーブレットとフィルターにリクエスト処理を委任する委任とフィルターのペアが委任します。

最後の日はOSGIについて多くを読みましたが、標準化されたモジュール化アプローチとしてOSGIをどのように使用できるか（そして）を検討していました。私は、個々のタスクをOSGIでどのように解決できるかを考えていました：

  • 静的リソース - 静的リソースをエクスポートしたいOSGIバンドル ResourceLoader バンドルコンテキストを使用したインスタンス。中央 ResourceServlet これらのリソースローダーを使用して、バンドルからリソースをロードします。
  • フェイスラットテンプレート - 上記と同様に、中央 ResourceResolver バンドルによって登録されたサービスを使用します。
  • マネージドビーンズ - 何も思いつきません 次のような式を使用する方法 #{myBean.property} もしも myBean バンドルの1つで定義されています。
  • サーブレットAPIのもの - WebExtender/Pax Webなどのものを使用して、サーブレット、フィルターなどを登録します。

私の質問は次のとおりです。

  • ここで自転車を発明していますか？そのための標準的なソリューションはありますか？スプリングスライスについて言及しているのを見つけましたが、それについて多くのドキュメントを見つけることができませんでした。
  • OSGIは説明されたタスクに適した技術だと思いますか？
  • OSGIアプリケーションのスケッチは多かれ少なかれ正しいですか？
  • 管理された豆（特にリクエスト/セッションの範囲）はどのように処理されるべきですか？

私は一般的にあなたのコメントに感謝します。

役に立ちましたか？

解決

あなたがしようとしていることは、いくつかの警告で実行可能な音です：

ビューレイヤー： まず、ビューレイヤーは少し詰め込まれています。後期結合管理豆のように劇的なものを作成しようとする頭痛を避けるカスタムコンポーネントを使用して、JSFコンポーネントをモジュール化する他の方法があります。

モジュール自体： 第二に、モジュールは特にモジュール式ではないようです。最初の弾丸リストは、モジュール自体ではなく、相互運用可能なWebアプリを作成しようとしているかのように聞こえます。モジュールの私の考えは、各コンポーネントが明確に定義されており、多かれ少なかれ離散的な目的を持っているということです。方法のように 元 下にあります vi. 。 OSGIルートを下って行く場合は、次のようなモジュラーを定義する必要があります。 この議論のために、モジュラーは、コンポーネントがホットスワップ可能であることを意味します。つまり、それらを追加できます 削除されました アプリを壊すことなく。

依存関係： モジュールの説明に「おそらく互いに依存する」と少し心配しています。あなたはおそらく（私が望む）すでにこれを知っていることを望みますが、あなたの依存関係は指示された非環式グラフを形成する必要があります。循環依存関係を導入すると、アプリの最終的な保守性の観点から、傷の世界を求めています。 OSGIの最大の弱点の1つは、 そうではありません 円形の依存関係を防ぐため、これを実施するのはあなた次第です。それ以外の場合、依存関係はクジュのように成長し、システムのエコシステムの残りの部分を徐々に窒息させます。

サーブレット： fuhgeddaboudit。サーブレット3.0スペックが生産されるまで（Pascalが指摘したように）、Webアプリにサブレットを遅くすることはできません。別のユーティリティサーブレットを起動するには、独自のアプリに入れる必要があります。

わかりました、警告のためにこれだけです。これがどのように機能するかについて考えてみましょう：

あなたはあなた自身のJSFモジュールを定義しました...正確に何ですか？定義された、かなり些細な目的：ログイン画面を与えましょう。したがって、ログイン画面を作成し、OSGIを使用してアプリに遅くバインドします...そして何ですか？ .jspxページで定義していない場合、アプリはログイン機能があることをどのようにして知っていますか？アプリは、そこにあることがわからない何かに移動することをどのようにして知っていますか？

条件付きの含まれている条件を使用してこれを回避する方法があります（例： <c:if #{loginBean.notEmpty}>）、しかし、あなたが言ったように、あなたの管理されたLoginbeanがまだアプリに導入されていないかもしれない別のモジュールに存在すると、物事は少し毛深いものになります。実際、そのLoginbeanが存在しない限り、サーブレットの例外が得られます。それで、あなたは何をしますか？

モジュールの1つでAPIを定義します。 モジュール間で共有しようとするすべてのマネージドビーンは、このAPIレイヤーのインターフェイスとして指定する必要があります。また、すべてのモジュールには、使用する予定のこれらのインターフェイスのデフォルトの実装が必要です。また、このAPIは、相互運用可能なすべてのモジュール間で共有する必要があります。次に、OSGIとSpringを使用して、指定された豆を実装して配線できます。

これが私がこの問題にアプローチする方法ではないことを指摘するために少し時間をとる必要があります。全くない。ログインページのような単純なようなもの、またはストックチャートのように複雑なものを考えると、私は個人的にカスタムJSFコンポーネントを作成することを好みます。しかし、要件が「マネージドビーンズをモジュール式（つまり、ホットスワップ可能など）にしたい場合」である場合、これが私がそれを機能させる唯一の方法です。そして、私はそれを完全に確信していません 意思 仕事。 この電子メール交換 JSF開発者が作業を開始したばかりの問題であることを示唆しています。

私は通常、マネージドビーンズがビューレイヤーの一部であると考えているため、ビューロジックにのみ使用し、他のすべてをサービスレイヤーに委任します。管理された豆を遅く結合することは、私の考えでは、ビューレイヤーからビジネスロジックにそれらを促進することです。これらのチュートリアルがすべてサービスに焦点を当てている理由はあります。ほとんどの場合、アプリが「ヘッドレス」を実行するのに必要なことを考えたいので、あなたの見解を「スキン」するのがどれほど簡単かたとえば、Androidスマートフォンで、すべての機能を備えた実行を実行する必要があります。

しかし、それはあなたが扱っているものの多くはそれ自体がビューロジックであるように聞こえます - たとえば、別のビューテンプレートに交換する必要性。 OSGI/Springは役立つはずですが、利用可能な実装を選択するにはアプリに何かが必要です。OSGIのサービスレジストリが作成されたものとほぼ同じです。

それは静的なリソースを残します。これらをモジュール化することはできますが、これらのリソースを取得するためにインターフェイスを定義する必要があることを忘れないでください。また、アプリが不在の場合にアプリが窒息しないようにデフォルトの実装を提供する必要があります。 I18Nが考慮事項である場合、これは良い方法かもしれません。あなたがなりたかったら 本当 冒険的で、静的リソースをJNDIに押し込むことができます。それにより、それらは完全にホットスワップ可能になり、プログラムで使用する実装を解決しようとする苦痛を救いますが、いくつかの欠点があります。見た目が失敗した場合、アプリはnamingexceptionをスローします。そして、それはやり過ぎです。 JNDIは通常、アプリの構成のためにWebアプリで使用されます。

残りの質問については：

ここで自転車を発明していますか？そのための標準的なソリューションはありますか？

あなたは少しです。これを行うアプリを見てきました 親切 物事ですが、あなたはかなりユニークな要件につまずいたようです。

OSGIは説明されたタスクに適した技術だと思いますか？

モジュールをホットスワップ可能にする必要がある場合、選択肢はOSGIと軽量のServicelocatorインターフェイスです。

OSGIアプリケーションのスケッチは多かれ少なかれ正しいですか？

あなたのコンポーネントの境界がどこにあるかをもっと知ることなく、私は本当に言うことはできません。現時点では、OSGIにそれができる以上のことをするようにプッシュしているように聞こえます。

しかし、私の言葉を受け取らないでください。 私 見つかった 他の これらの場所で素材を読む。

そして、あなたは春のスライスについて尋ねるので、 これはあなたを始めるのに十分なはずです. 。 GITクライアントが必要になり、ソースコードを調べてアプリでトレーニングするように見えます。そして、それは非常に初期のプロトタイプコードです。

他のヒント

私は現在のプロジェクトで同じ問題に直面しています。私の意見では、OSGIは標準と将来のサポートの点で最良かつクリーンなソリューションですが、現在、Webアプリケーションで使用しようとすると問題が発生する可能性があります。

  1. WebコンテナとOSGIプラットフォームの間には、十分に統合されたソリューションはありません。
  2. OSGIは、単純なモジュール化されたアーキテクチャを検索しているカスタムビルドWebアプリケーションには多すぎる可能性があります。プロジェクトが私たちの制御下にある100％ではないサードパーティの拡張機能をサポートする必要がある場合、プロジェクトにホットな再配置、プラグイン間の厳格なアクセスルールなどが必要な場合は、OSGIを検討します。

クラスローダーとリソースフィルターに基づいたカスタムソリューションは、私にとって非常に適切なようです。例として、あなたは研究することができます ハドソンソースコード またはJavaプラグインフレームワーク（JPF）プロジェクト（http://jpf.sourceforge.net/）。

web.xmlを拡張することについては、サーブレット3.0仕様（http://today.java.net/pub/a/today/2008/10/14/introduction-to-servlet-3.html#で幸運になるかもしれません。プラグ性と拡張性）。

によって導入された「Webモジュール展開記述子フラグメント」（別名Web-Fragment.xml） サーブレット3.0仕様 ここでいいでしょう。仕様はそれを次のように定義しています：

Web Fragmentは、Webアプリ内で使用されているフレームワークがDevlopersにWeb.xmlに情報を編集または追加するように依頼することなくすべてのアーティファクトを定義できるようにWebアプリを論理的なパーティション化することです。

Java EE 6は今のところあなたにとって選択肢ではないかもしれません。それでも、それは標準化されたソリューションになるでしょう。

Enterprise OSGIはかなり新しいドメインですので、あなたのニーズを直接満たすソリューションを得るとは思わないでください。それは、Equinox（Eclipseの背後にあるOSGIエンジン、したがって最大のユーザーベースを持つOSGIエンジン）から失われていることがわかったことの1つは、一貫した構成 / DIサービスです。最近の私のプロジェクトでは、いくつかの同様のニーズがあり、シンプルな構成OSGIサービスの構築を終了しました。

モジュール式アプリケーションに固有の問題の1つはDI前後です。モジュールの可視性により、場合によってはクラスのアクセスを防ぐことができます。これは、登録されたバディポリシーを使用して回避しましたが、これは理想的ではなく機能しますが、機能します。

構成以外では、モジュラーアプリケーションを作成するためのベースとしてOSGIを使用するガイダンスについて、最近リリースされたEquinox Bookをご覧ください。例はequinoxに固有の場合がありますが、原則はあらゆるOSGIフレームワークで機能します。リンク - http://equinoxosgi.org/

Spring DMサーバーを調べる必要があります（Eclipse Virgoに移行されていますが、まだリリースされていません）。最近のOSGI Enterprise Specには、リリースされたばかりの良いことがたくさんあります。

春のDMチュートリアルの一部が役立つと思います。しかし、はい、標準のモジュール性を使用して、Webバンドルの外側からクラスの両方をロードすることができます。その中で、それは良いフィットです。

セッションのコンテキストに関しては、セッションで予想されるように処理されます。ただし、Webバンドル間でそのセッションを共有することで問題が発生する可能性があります。

また、単一のWebバンドルを使用してから、Eclipse Extensionレジストリなどを使用して、Webアプリの機能を拡張することもできます。

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top