問題タブ [osgi]

現在、次の標準のSubversionリポジトリレイアウトを持つプロジェクトがあります。

./trunk
./branches
./tags

ただし、OSGiとモジュラープロジェクトの道を進んでいると、次のようになります。

./trunk/bundle/main
./trunk/bundle/modulea
./trunk/bundle/moduleb ./tags/bundle/main-1.0.0
./tags/bundle/main-1.0.1
./tags/bundle/modulea -1.0.0

'build'は、すべてのモジュールを順番にビルドするという点でまだかなりモノリシックですが、ビルド/リポジトリを次のようなものにリファクタリングする必要があるかどうか疑問に思い始めています。

./bundle/main/trunk
./bundle/main/tags/main-1.0.0
./bundle/main/tags/main-1.0.1
./bundle/modulea/trunk
./bundle/modulea/tags/modulea- 1.0.0

このパターンでは、各モジュールがそれ自体を構築し、そのバイナリをリポジトリ（maven、ivy、またはSubversionリポジトリ自体の別のパス）に格納することを想像します。

モジュール化された後のプロジェクトレイアウトに関するガイドラインまたは「ベストプラクティス」はありますか？

モジュール/サービス/アプリケーション機能のビットがOSGiモジュールの特に優れた候補となる理由は何ですか？

アプリケーションでOSGiを使用することに興味があります。私たちはJavaショップであり、Springをかなり広範囲に使用しているため、OSGi（tm）サービスプラットフォーム用のSpringDynamicModulesを使用することに傾倒しています。トライアルとして、OSGiを少しアプリケーションに組み込む良い方法を探しています。ここで誰かがこれまたは同様のOSGiテクノロジーを使用しましたか？落とし穴はありますか？

@ニコラス-ありがとう、私はそれを見ました。これは良いチュートリアルですが、Hello Worldの例ではなく、最初の「実際の」OSGiバンドルを作成する方法についてのアイデアをもっと探しています。

@david-リンクをありがとう！理想的には、グリーンフィールドアプリを使用して、すべてを動的に設計します。しかし、私が今探しているのは、既存のアプリケーションの小さな部分にそれを導入することです。アプリの任意の部分を選択できると仮定すると、OSGiモルモットとしてその部分を良くしたり悪くしたりするために考慮すべきいくつかの要因は何ですか？

プラグインの開発を容易にするために、OSGi ランタイム (Equinox) をカスタム クライアント サーバー アプリケーションに組み込みましたが、これまでのところ順調に進んでいます。組み込みのマニフェスト エディター、依存関係管理、およびエクスポート ウィザードにより、Eclipse を使用してプラグインを作成しています。Eclipse を使用してビルドを管理することは、Hudson による継続的インテグレーションにはあまり役立ちません。

他の OSGi バンドルに依存する OSGi バンドルがあります。カスタム ANT ビルドでビルド順序をハードコーディングするのは本当に嫌です。これは過去のことであり、かなり恐ろしいことです。OSGi の依存関係を自動的に解決しない場合でも、簡単に管理できるビルド ツールはありますか? これを行う方法の適切な例はありますか?

説明:

生成されたビルド スクリプトは、Eclipse 経由でのみ使用できます。Eclipse の一部を手動で実行する必要があります。また、Eclipse ビルドにはない標準ターゲットもいくつかあります。再生成する可能性があるため、生成されたファイルを変更したくありません (インクルードできることはわかっていますが、Eclipse gen ファイルをすべて回避したいです)。一緒）

ここに私のプロジェクトのレイアウトがあります:

Eclipse PDE を使用する場合、各プラグインにはマニフェストがありますが、PDE が私のためにそれを行うため、build.xml はありません。Hudson を使用して GUI 駆動のプロセスを自動化するのは困難です。それぞれをビルドするために独自の build.xml をセットアップしたいのですが、依存関係とビルド順序の問題があります。これらの問題は、マニフェスト ファイル (OSGi インポートを記述する) によって引き起こされます。たとえば、PluginC は、PluginA に依存する PluginB に依存します。それらは正しい順序で構築する必要があります。ビルド順序を手動で制御できることに気づきました。ビルド順序の依存関係管理を自動化するのに役立つツールを探しています。

非同期リモート インターフェイスを公開する最善の方法について質問があります。

条件は次のとおりです。

• プロトコルは非同期です
• 第三者はいつでもデータを変更できます
• コマンドの往復は重要な場合があります
• モデルは UI インタラクションに適している必要があります
• プロトコルは特定のオブジェクトに対するクエリをサポートしているため、モデルもサポートする必要があります

この分野で不足しているスキルを改善する手段として (および Java 全般をブラッシュアップする手段として)、xmms2用の Eclipse ベースのフロントエンドを作成するプロジェクトを開始しました(後述)。

それで、問題は次のとおりです。リモート インターフェイスを適切なデータ モデルとして公開するにはどうすればよいですか (この場合は、管理とイベント処理を追跡します)。

一般的な議論からパターン名の削除、具体的な例やパッチまで、何でも歓迎します :)

ここでの私の主な目標は、このクラスの問題全般について学ぶことです。私のプロジェクトがそれから利益を得ることができるなら、それは結構ですが、議論を始めるための何かを持っていることを厳密に提示します.

私は「クライアント」と呼ぶプロトコル抽象化を実装しました(従来の理由から)。これにより、メソッド呼び出しを使用してほとんどの公開された機能にアクセスできますが、それは完全ではありませんが満足しています。

xmms2 デーモンによって提供される機能には、トラックの検索、メタデータの取得と操作、再生状態の変更、プレイリストのロードなどがあります。

私は xmms2 の最新の安定版リリースに更新している最中であり、現在の実装の明らかな弱点のいくつかを修正したほうがよいと考えました。

私の計画は、デーモンとのより自然な相互作用を可能にするプロトコル インターフェイスの上に、より良い抽象化を構築することです。現在の「モデル」の実装は使いにくく、率直に言って非常に醜いです (本当に恐ろしい atm である UI コードは言うまでもありません)。

現在、ID に基づいてTrackクラスのインスタンスを取得するために使用できるTracksインターフェイスがあります。検索はCollectionsインターフェイス (残念ながら名前空間の競合) を介して実行されますが、これはむしろ Tracks に移動したいと思います。

どのデータも第三者によっていつでも変更される可能性があり、これは配布されるモデルと変更通知に適切に反映されるべきです

これらのインターフェイスは、接続時に次のようなオブジェクト階層を返すことによって公開されます。

• 繋がり
  • プレイバック getPlayback()
    • 再生、一時停止、ジャンプ、現在のトラックなど
    • 再生状態の変更を公開する
  • トラック getTracks()
    • 追跡 getTrack(id) など
    • トラックの更新を公開する
  • コレクション getCollection()
    • プレイリストまたは名前付きコレクションを読み込んで操作する
    • メディア ライブラリのクエリ
    • コレクションの更新を公開する

現在、私は大学の最終学年プロジェクトの一環として、新しいバージョン管理システムに取り組んでいます。アイデアは、高度な適応性とプラグ可能性を実現することです。

OSGi フレームワーク (Equinox 実装) を使用してプラグインを管理しています。私の問題は、OSGi バンドルをテストするためのシンプルで使いやすい方法が見つからないことです。

現在、Maven を使用してバンドルをビルドし、テスト ハーネスを実行する必要があります。かなりの時間を節約できるので、Eclipse 用の JUnit テスト ランナーのようなものを探しています。

OSGi バンドルをすばやく簡単にテストする方法はありますか?

編集: Eclipse プラグインや GUI コンポーネントをテストするために必要なものはありません。OSGi バンドルだけです。

EDIT2: JUnit4 をサポートするフレームワークはありますか?

Wikipedia やOSGiに関する他のサイトを読んだことがありますが、全体像はよくわかりません。コンポーネントベースのプラットフォームであり、実行時にモジュールをリロードできると書かれています。また、どこにでもある「実用的な例」は、Eclipse Plugin Framework です。

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

1. OSGi の明確で単純な定義は何ですか?

2. どのような一般的な問題を解決しますか?

「よくある問題」とは、私たちが毎日直面している問題を意味します。

SpringSource dm Server を使用したいのですが、お客様からアプリケーション サーバー (Websphere) でアプリを実行するように求められています。SpringSource dm Server を他のアプリケーション サーバーと統合する方法はありますか? 少なくとも dm サーバーは OSGi 上に構築されており、他の多くのアプリケーション サーバー (Websphere を含む) も OSGi に基づいています。SpringSource dm サーバーを websphere コンポーネントとして実行することは可能ですか?

OSGi と JSF を一緒に使った人はいますか?

JSF はクラスローダー マジックを使用してカスタム コンポーネントを検索するためです。チュートリアルから（強調鉱山）：

この構成ファイルは、このコンポーネントを表す .jar ファイル内の META-INF/faces-config.xml になります。JSF は、実行時にロードされる各 .jar ファイル (.war ファイルの WEB-INF/lib ディレクトリ内) でそのようなファイル名を探し、その構成でそれぞれを使用します。このようにして、複数のコンポーネント .jar ファイルを 1 つの Web アプリケーションに組み合わせることができ、各 .jar に記述されているすべてのコンポーネントをアプリケーションで使用できます。

JSF カスタム コンポーネントを OSGi バンドル (つまり、カスタム コンポーネントは JSF ランタイムとは異なる OSGi バンドルに含まれる) として持つことができ、JSF が実行時にこれらを見つけられるようにしたいと考えています。

誰かが似たようなことをしましたか？

私は Eclipse プラグイン (技術的には OSGi プラグイン) の開発を始めていますが、最初に遭遇した問題の 1 つは、通常のように commons-logging 出力を制御できないように見えることです。

プラグインの依存関係に commons-logging パッケージを含めました。実際、何かをログに記録すると (INFO 以上の重大度で)、コンソールにログが記録されます。ただし、下位レベル (DEBUG や TRACE など) ではログを記録できないようです。

log4j.properties ファイルを指定しました。これはクラスパス上にあります (commons-logging パッケージと同じように、ランタイムの場合) が、そのプロパティ ファイルの設定はロガーの動作に影響しません。

log4j.properties ファイルは次のとおりです。

ロガーの出力を実際に制御するには、どうすればよいですか?

フォーマットが java.util.logging のデフォルトと一致するか、他のヒントを提供することを期待して、いくつかのサンプル出力メッセージを次に示します。

アップデート：

私は今、次のさまざまな組み合わせを試しました。

• org.osgi.service.log.LogService など。
• slf4j
• Log4J
• コモンズロギング
• java.util.logging

また、 OSGi をプロンプトから手動で実行している場合にのみ、DEBUG またはそれ以下のレベルのメッセージが表示されます (これは私が開発しているものには非現実的です)。さらに、さまざまなプロパティ ファイルを介して、他の種類のログ構成に影響を与えることはできません。その点で私が試みることはすべて、日食の設定によって上書きされるようです。

また、上記のライブラリのさまざまな構成ファイルを、ここで提案されているようにそれぞれのライブラリに接続されたプラグイン フラグメントなど、さまざまな場所に配置しようとしましたが、それでも同じ結果が発生します。

私はカスタム LogListener を実装し、System.out.println を使用してログ メッセージのパス全体をトレースし (とにかく方法は知っています)、デバッグ メッセージは、基礎となるログ API によって出力されるまで存在します。私は使用していますが、それらは消えます。

OSGi バンドル リポジトリを使用している人はいますか? 何のために使用していますか?