何かを壊すことを心配することなく、Karaf 2.3 で Spring 3.1 を使用することは可能ですか?
3 に答える
私はこの問題に少し苦労しました。基本的に、Camel 2.10.1、Spring Integration 2.1.3.RELEASE (はい、2 つの統合フレームワークを知っています) を使用しており、Spring 3.1.2.RELEASE、activemq 5.7.0、Karaf 2.3.0 を使用していました。Claus が OSGi について言っているように、それは常に心配であり、特に制御できない場合は特にそうです。
- サードパーティの OSGi マニフェスト
- Karaf 機能記述子 (カスタム ディストリビューションを作成することでこれを回避できるため、これは少し心配が少なくなります)。
また、Spring DM も使用しているため、基本的に 3.0、3.1、および 2.5.6 の 3 種類の Spring を使用できます。たとえば、推移的な依存関係の解決などにより、3 つのバージョンの spring-core がインストールされた状態になる可能性があり、スタートアップの順序などによっては、厄介な「用途」の制約に遭遇する可能性があります。 .
私たちが最終的に行ったことは、Karaf と連携し、Spring 3.1.2.RELEASE を投棄して 3.0.7 を優先することでした。私たちの場合、3.0.7 で問題がなかったので、これは簡単でした。
一般に、コンテナーがすぐに提供するものと連携することが、依存関係を処理する上で合理的な戦略であることがわかりました。
Karaf 2.3.0 で利用できる Spring31 機能があります。オプション機能として提供するのは最適ではないかもしれませんが、現在は std. 2.3.0 ラインのスプリングに関する機能は、スプリング 3.0.x の機能です。Out-Of-The-Box のサポートについては、Karaf 3.0 を少し待つ必要があります。
OSGiには常に心配があります:(
Camel は Spring 3.0 と 3.1 の両方をサポートしています。したがって、キャメルの観点からは大丈夫です。Karaf は Spring 3.0.7 でそのまま使用できます。代わりに Spring 3.1.x を使用するには、Karaf を再構成する必要があります。
私見では、これは間違っています (たとえば、Karaf が Spring 3.0.7 をすぐに公開するなど)、Karaf はユーザーに特定の Spring バージョンを強制するべきではないと考えています。ただし、エンド ユーザーが使用する Spring を自由に選択できるようにします。また、コンテナーにデプロイされたアプリケーションの必要に応じて、Spring 3.0、3.1、および 3.2 を並べて実行することもできます。または、少なくともカラフは、公開/使用するSpringバージョンをすぐに選択できるようにする必要があります。
Karaf の @dev メーリング リストで、この問題とその対処方法について議論されています。 http://karaf.922171.n3.nabble.com/Apache-Karaf-2-3-0-very-close-tp4026295.html およびこちら http://karaf.922171.n3.nabble.com/Re-3rd -Party-Feature-Definitions-tp4026366.html
Karaf チームがメーリング リストにリストされているので、これらのメーリング リストで声を上げてください。