OSGiには、数十のJAR依存関係をlibディレクトリーにラップしないことにより、デプロイ可能なアーティファクトが小さいという優れた利点があるようです。ただし、依存関係をコンテナーにデプロイするための簡単で信頼性の高い方法を教えてくれるものは何も見つかりません。たとえば、CXFといくつかのSpringサブプロジェクトを使用するアプリケーションがあります。このアプリケーションを新しいGlassfishサーバーにデプロイする必要がある場合、すべての依存関係が確実にインストールされるようにするための最良の方法は何でしょうか。
私はMavenを使用していますが、seem META-INF/mavenディレクトリを調べて、pom.xmlから依存関係リストを取得して移動するフックを作成する方法がある可能性があります。必要なライブラリをフェッチします(おそらくローカルリポジトリから)。それを行う方法はありますか?
Paxプラグインはこれを行っているように聞こえますが、Felixコンテナのブートストラップに基づいているようです。これは私が望んでいることではありません。私はすでに実行中のリモートコンテナを扱っています。
GUIではなくコマンドラインツールとして存在するようなショットはありますか?
依存バンドルをOSGiコンテナーにデプロイする方法はいくつかあります。それらのいくつかを次に示します。
最初に、bindexなどのツールを使用して、使用可能なバンドルのXMLインデックスファイルを作成する必要があります。 maven-bundle-pluginを使用している場合は、OBRインデックスを〜/ .m2/repository /repository.xmlに自動的に維持します。
OBRコマンドラインインターフェイスを使用してインデックスをロードします。
> obr:addUrl file:/Users/derek/.m2/repository/repository.xml
次に、OBRインデックスから決定された依存関係を使用して、ターゲットバンドルをデプロイするようにOBRに依頼します。
> obr:deploy com.paremus.posh.sshd
Target resource(s):
-------------------
Paremus Posh Ssh Daemon (1.0.23.SNAPSHOT)
Required resource(s):
---------------------
Paremus Command API (1.0.23.SNAPSHOT)
Optional resource(s):
---------------------
Paremus Config Admin Commands (1.0.23.SNAPSHOT)
Paremus OSGi & LDAP Types (1.0.23.SNAPSHOT)
Karafは、基本的に機能を提供するために必要なバンドルのリストである「機能」をサポートしています。
karaf@root> features:info obr
Description of obr 2.0.0 feature
----------------------------------------------------------------
Feature has no configuration
Feature has no dependencies.
Feature contains followed bundles:
mvn:org.Apache.felix/org.Apache.felix.bundlerepository/1.6.4
mvn:org.Apache.karaf.Shell/org.Apache.karaf.Shell.obr/2.0.0
mvn:org.Apache.karaf.features/org.Apache.karaf.features.obr/2.0.0
karaf@root> features:install obr
Virgoはplansを使用してアプリケーションを構成するアーティファクトを定義し、ローカルリポジトリとリモートリポジトリの両方から、バンドル、プラン、プランアーカイブ(PAR)、構成などのアプリケーションの依存関係を自動的に提供できます。 。
Nimbleは、OBR(または独自の拡張)リポジトリインデックスを使用して、ターゲットバンドルをアクティブ化するために必要なすべての依存バンドルを自動的にデプロイします(ターゲットバンドルが停止すると、それらをアンインストールします)。また、WABバンドルにはWebエクステンダーが必要であり、構成可能なポリシーに従って自動的にインストールするなど、他の依存関係を検出することもできます。
Nimbleは、Glassfishを起動するように構成することもできるため、Glassfishコンテナ内のバンドルでその機能を利用できます。
以下の例は、sshdがアクティブ化されると、ロギングサポートが自動的にインストールされることも示しています。
$ posh
________________________________________
Welcome to Paremus Nimble!
Type 'help' for help.
[denzil.0]% nim:add --dry-run com.paremus.posh.sshd@active
-- sorted parts to install --
4325 osgi.resolved.bundle/ch.qos.logback.core:0.9.22
-- start dependency loop --
5729 osgi.resolved.bundle/com.paremus.util.logman:1.0.23.SNAPSHOT
5727 osgi.active.bundle/com.paremus.util.logman:1.0.23.SNAPSHOT
3797 osgi.resolved.bundle/ch.qos.logback.classic:0.9.25.SNAPSHOT
3792 osgi.resolved.bundle/slf4j.api:1.6
-- end dependency loop --
436 osgi.resolved.bundle/org.Apache.mina.core:2.0.0.RC1
6533 osgi.resolved.bundle/sshd-core:0.3
398 osgi.resolved.bundle/com.paremus.posh.sshd:1.0.23.SNAPSHOT
396 osgi.active.bundle/com.paremus.posh.sshd:1.0.23.SNAPSHOT
(免責事項:私はParemusの開発者です)
gogoは、新しいRFC147標準コマンドラインシェルです。すでにFelix、Karaf、Nimbleで使用されており、まもなくGlassfishで利用できるようになります。
Gogoを使用すると、インタラクティブに入力できるコマンドをスクリプトとして実行できます。そのため、インストールするバンドルのリストを生成してスクリプトに変換したり、インストールされたバンドルを作業構成からキャプチャして、クリーンスタートから再作成したりすることもできます。
OSGiアプリケーションと、同じことを行い、同じライブラリを使用する従来のJavaアプリケーションを作成する場合は、まったく同じJARのセットが必要になります。大きな違いは、明示的にできることです。依存関係を定義します(そして、アプリケーションに対してより詳細なJARを生成する可能性があります)。
私が知っている純粋なOSGiベースのサーバーは1つだけです(EclipseのVirgo、以前はSpringのDMサーバー)。GlassfishとWebsphereはOSGiをサポートしていますが、私はそれらを使ったことがないので、私が言えることは、それらすべてにOSGiコンテナーが必要であり、それは通常EclipseのEquinoxまたはApacheのFelixであるということです。
あなたの質問は、実際にはアプリケーションのプロビジョニング(何をデプロイする必要があるかを検討すること)に関するもののようです。 Maven 3.0では、EclipseのP2プロビジョニングフレームワークを使用して多くの作業を行ったことを知っています。
アプリケーションに対して、EARまたはWARを展開していますか?どちらの場合も、ビルドシステムはすべての依存関係を含むアーカイブを作成する必要があります。そうしないと機能しません。ビルドの推移的な依存関係管理を行うためにMavenを使用するため、問題が発生する理由については少し混乱します。