6

このトピックに関連する質問がすでにいくつかあることは知っていますが、実際の解決策はまだ見つかりませんでした。

現在、JPA、CDI、JSFを使用してEE6でアプリケーションを開発しています。すべてをWARまたはEARにパッケージ化して、すべてをアプリケーションサーバーにデプロイするよりも、よりモジュール化されたアプローチを採用したいと思います。

モジュールを3つのMavenプロジェクトに分割することにより、アプリケーションを可能な限りモジュール化して設計しようとしています。

  • API-(ステートレス)サービスのインターフェースが含まれています
  • モデル-特定のモジュールのJPAエンティティが含まれています
  • Impl-API、主にCDIBeanの実装が含まれています

現在、すべてのモジュールのビューロジックは、見苦しい大きなWebプロジェクトにまとめられています。私はすでにWebフラグメントについて考えていましたが、Beanクラスとxhtmlファイルをjarファイルに分散させる場合は、親Webアプリケーションがリソースを検索できるようにフックを実装する必要があります。この種のソリューションでは、少なくとも、モジュールに関連するすべてのビューロジックを含む、モジュールごとに4番目のプロジェクトを作成できます。これは良いスタートです。

私が欲しいのは、これらの4種類のプロジェクトを持つことができるだけでなく、すべてのプロジェクトがホットスワップ可能であることです。これが私をOSGiに導きました。これは、EE6テクノロジーがOSGiコンテナー内で十分にサポートされていないことに気付くまで、最初は本当にクールでした。

JPA

まずJPAを見てみましょう。JPA対応のOSGiバンドルを作成する方法を説明するチュートリアル[1]がいくつかありますが、これらのチュートリアルのいずれも、エンティティを異なるバンドル(モジュールのモデルプロジェクト)に分散する方法を示していません。たとえば、3つの異なるモジュールが必要です

  • ユーザー
  • ブログ

ブログモジュールのモデルプロジェクトは、ユーザーのモデルプロジェクトに(コンパイル時)依存しています。ユーザーモジュールのモデルプロジェクトは、コアのモデルプロジェクトに(コンパイル時)依存しています。

モジュールのモデルプロジェクトごとに永続性ユニットを作成せずに、このようなシナリオでJPAを機能させるにはどうすればよいですか?実行時に使用可能なすべてのエンティティを認識する1つの永続性ユニットが必要です。エンティティが存在するモデルプロジェクトは、もちろんホットスワップ可能である必要があります。たぶん、プロジェクトに必要なすべてのエンティティをインポートし、必要なすべての構成を含むpersistence.xmlを含む、クライアントごとに個別のプロジェクトを作成する必要があります。そのようなプロジェクトを構築するための利用可能なMavenプラグイン、またはその問題を解決するための他のアプローチはありますか?

CDI

CDIはとてもいいです。私は本当にそれが大好きで、もう見逃したくありません!私はMyFacesCODIやDeltaSpikeのような素晴らしいCDI拡張機能を使用しています!私は自分の(ステートレス)サービスを他のサービスまたはビューレイヤーに注入します。これは素晴らしいことです。私のサービスはステートレスなので、OSGiサービスとして使用しても問題はないはずですが、OSGiでのCDI統合についてはどうでしょうか。OSGiサービスをCDIBeanに注入するGlassfishCDIExtension [2]を見つけましたが、OSGiサービスをCDIBeanにしたい場合もあります。それを実現する方法が完全にはわかりません。おそらく、BeanManagerを使用して実装をインスタンス化し、そのインターフェイスのすべての実装をBundleActivator内のServiceRegistryに登録する必要があります。それを行うための標準的な方法はありますか?OSGiフレームワークへの(コンパイル時の)依存関係を避けたいと思います。

また、何も変更せずに、現在使用しているのと同じようにサービスを使用したいと思います(実装に注釈が付けられておらず、インジェクションポイントが修飾されていません)。その問題を対象としているように見えるJBossWeld拡張/サブプロジェクト[3]がありますが、非アクティブであるように見えます。ベストプラクティスやハウツーが見つかりません。実装をそのままにして、OSGiを使用できるようにするにはどうすればよいですか?すべての実装にはすでにステレオタイプの注釈が付けられているので、実装に注釈を追加することは大したことではないということですが、とにかくそれを防ぎたいと思います。

JSF

前に述べたように、ビューロジックモジュールを賢く広めることができるようにしたいと思います。私の知る限り、これは箱から出して実際に可能ではありません。Pax Web [4]はどういうわけかそれを解決するはずですが、私はそれに精通していません。

Faceletテンプレートを含むモジュール「core」にプロジェクト「CoreWeb」を入れたいのですが、これを「template.xhtml」と呼びましょう。モジュール「blog」の「BlogWeb」というプロジェクトのJSFページは、そのテンプレートを参照してコンポジションを適用できるはずです。

ビューを拡張できるようにするために、モジュールの特定のクラスで実装できるJavaインターフェース「Extension」を紹介します。次に、ビューのコントローラーは、拡張機能のすべての実装を挿入します。拡張機能は、たとえば、メインビューに含まれるサブビューのリストを提供します。

説明した拡張メカニズムは簡単に実装できますが、次の要件を満たす必要があります。

  • 新しいOSGiバンドルをアプリケーションサーバーに追加すると、使用可能な拡張機能のセットが変更される可能性があります。拡張機能は、ビューのコントローラーで使用可能である必要があります。
  • メインビューに含める必要がある(別のバンドルからの)サブビューにアクセスできる必要があります。

Spring Slices [5]の単一ホストであるが複数のスライスアプリケーションの概念は非常に興味深いものですが、Spring DM Serverに限定されているようであり、プロジェクトも非アクティブであるようです。

概要

私が説明したすべての例と動作の後で、私が達成したいことをあなたが知っていることを願っています。これは、非常に動的でモジュール化されたEE6アプリです。

私が最後に探しているのは、少なくとも私が期待するようにすべてを実行する方法に関するドキュメント、またはすでに機能しているソリューションです!

[1] http://jaxenter.com/tutorial-using-jpa-in-an-osgi-environment-36661.html

[2] https://blogs.oracle.com/sivakumart/entry/typesafe_injection_of_dynamic_osgi

[3] http://www.slideshare.net/TrevorReznik/weldosgi-injecting-easiness-in-osgi

[4] http://team.ops4j.org/wiki//display/paxweb/Pax+Web

[5] https://jira.springsource.org/browse/SLICE

4

1 に答える 1

1

いくつかの質問に答えるには、単一の永続性ユニットを使用し、エンティティを複数のバンドルに分散させることはお勧めしませんが、場合によっては機能することがあります。ただし、エンティティが非常に密接に関連しているため、永続性ユニットを共有する必要がある場合は、モジュール間でエンティティを分割しても意味がない場合があります。また、エンティティごとに実装とインターフェースを分離することで、コンパイル時の依存関係を処理できることを忘れないでください。インターフェースと実装が同じバンドルに含まれている必要はありません。

依存性注入については、ブループリントがお勧めです。いくつかの実装が利用可能であり、エンタープライズOSGiをサポートするほとんどのアプリケーションサーバーは、そのままブループリントをサポートします。XMLを使用してメタデータを追加するため、クラス自体を変更する必要はありません。

于 2012-07-03T07:07:34.350 に答える