19

質問：今日の時点で、2つのEnterprise OSGiフレームワークのどちらがより成熟していますか：ApacheAriesまたはEclipseGemini？

私はAriesとGeminiEnterpriseOSGiの機能についていくつかの基礎研究を行いました。私も同様の質問を経験しました：GeminiとApacheAriesの青写真コンテナ。

以下の私の要件と調査結果。あなたの追加の入力を高く評価します。

  1. ブループリントコンテナ：AriesとGeminiはどちらも、ブループリント仕様に対する実装の点で同等に成熟しているように見えます。

  2. Web開発（Spring PortletMVCを使用してJSR286に対して開発する予定）：GeminiWebはSpringDM
    にルーツがあります（したがって、Geminiフレームワークに対する私の最初の好み）が、AriesはSpringPortletMVCベースのWebと同等に機能する必要があると思いますアプリケーション。

  3. JPA：これが私の最大の関心事です。私は当初、Geminiに傾倒していましたが（Spring DMにルーツがあり、アクティブなSpringSourceコミュニティからのサポートがあるため）、GeminiJPAの成熟度はAriesJPAに比べてかなり低いと感じています。理由：

    • Gemini JPAは、JPAプロバイダーとしてのEclipseLinkとの統合のみをサポートします。Hibernateを使用したいと思います。AriesJPAはHibernateをサポートしています。
    • Gemini JPAの制限について：特に制限＃5：JTAトランザクションのサポートの欠如。Aries JPAはJTAをサポートしているよう です...しかし、サポートのレベルの詳細を知ることができませんでした。

  4. JNDI：新しいWebアプリケーションは、JBossアプリケーションサーバー内でホストされているサービス層から既存のセッションEJBを呼び出す必要があります。したがって、JNDIサポートは、クライアント層のOSGi対応Webアプリケーションにとって非常に重要です。
    ジェミニネーミングはまだリリースされていないようですが、アリエスはすでにこの分野である程度の能力を持っています。

4

1 に答える 1

14

同じ質問が頭に浮かび、次の結果が得られました。

1: ジェミニは、はるかに長い過去を持ち、多くのことを証明した春に基づいています。コードを調べたところ、Gemini はより多くの拡張機能を備えているように見えましたが、名前空間ハンドラーに問題がありました。バージョン 1.0.0 でも、名前空間ハンドラを待機しませんでした。Aries は、必要な参照を待つのと同じ方法で NS ハンドラーを待ちます。OSGi の担当者に尋ねたところ、次のブループリント仕様には標準の NS ハンドラー API が含まれている可能性があり、これは非常に役立つと思います。私の結論は、Apache Aries を使用するというものでしたが、最終的な決定ではありません。私はこのトピックを四半期ごとに見直します。また、ブループリントを改善する方法を提案し、OSGi bugzillaにアップロードしました。. 夏にはこれらの拡張機能を実装したいと考えています。コードを調べたところ、Gemini に基づいた方がはるかに簡単です。

2: Gemini には Tomcat が組み込まれています。バンドルを分点に単純にドロップすると、かなりうまく機能します。ただし、避けたかったSpringへの依存関係がいくつか含まれています。私はSpringが好きですが、必要なだけ依存関係を減らしたいと思っていました. 私は、牡羊座がこのトピックで主要なサポートを持っているとは思わない. やっとMyfacesやJerseyと連動するJettyを今まで使い始めました。今まで他に試したことはありません。また、Jetty の構成の可能性がさらに気に入りました。構成バンドルは、ビルド ライフサイクルの一部として統合テストを実行する場合に非常に役立つ環境変数として定義できます。Gemini がより多くの構成オプション (バンドルから来るなど) をサポートする場合は、それに移行することを考えます。

3: 私は JTA を使用するのが好きなので、Gemini を使用するという選択肢はありませんでした。Aries JPAを静かにしばらく使用しましたが、満足していました。私は多くの同僚と仕事をしているので、彼らの有効性に責任があります。Aries JPA では、DataSourceFactory サービス (persistence.xml で db 接続が定義されている場合) または DataSource サービス (jta-data-source または non-jta-data-source の場合) が定義されているのを待たないという問題がありました。これは、Aries JPA を使用する場合、バンドルの開始順序が重要であることを意味していました。

Glassfish は OSGI バンドルの前に JNDI リソースを開始したため、Glassfish と JNDI を使用するまで問題はありませんでした。クリーンな OSGI コンテナーに移行したとき、問題が発生し始め、同僚は適切なバンドル開始順序を取得するために多くの時間を費やすようになりました。

最後に、Aries JPA をバンドルにまとめて、気に入らない部分を書き直しました。これは、persistence.xml パーサー部分のみを保持し、http://everit.org/osgi/jpa/org.everit.osgi.jpa.container/index.htmlに独自のプロジェクトを作成して、この問題が発生しないように集中したことを意味します。 . 現在、Hibernate で動作し、Eclipselink と Compile time Enhanced OpenJPA で (試していない) と思います。私が作成したコンテナーは、org.apache.aries.jpa.container.context および aries jpa ブループリント名前空間ハンドラーとうまく連携します。

4: アプリケーション サーバーを使用していて、バンドルよりも先に JNDI 環境が起動することが確実な場合は、それを使用してください。ただし、変更をキャッチしたり、JNDI リソースを削除したりすることはできないため、OSGi 内で使用することはまったくお勧めしません。JPA のために必要な場合は、osgi:service/... 式を使用して persistence.xml で *-data-source を使用している場合でも、標準の OSGi サービス トラッカーを使用するコンテナの実装を提案できます :)。中央の構成場所が必要な場合は、felix-webconsole の [構成] タブ、OSGi 仕様のメタタイプおよび構成管理部分を確認することをお勧めします。メタタイプを使用して構成設定を定義すると、それらは feilix-webconsole で使用可能になり、構成管理 API を介して構成変更イベントをキャッチできます。

私の意見がお役に立てば幸いです。

于 2012-05-29T23:19:43.323 に答える