伝統的なSpringアプリケーションは1つのアプリケーション・コンテキスト、又は親コンテキストを含むサービス・レイヤー、データ・レイヤー、又はWebレイヤーのコンポーネントを含んだ子コンテキストを持つドメイン・オブジェクトしか使いません。アプリケーション・コンテキストは複数の設定ファイルの内容から合成されます。アプリケーションをOSGiにデプロイする場合、最も自然な方法は、OSGiサービス・レジストリを通じてアプリケーションをBundleの集合(アプリケーション・コンテキスト)としてパッケージすることです。独立したサブシステムは1つのパッケージか、もしくはBundleのセットとなっているべきです。(バーチャル・パーティショニング)あるサブシステムは1つのBundleとしてパッケージされるかもしれませんし、レイヤーによっていくつかのBundleに分割されているかもしれません。partitioning:ホリゾンタル・パティショニング)例えば、ある真っ直ぐな(straightforward)Webアプリケーションがあり、4つのモジュール(Bundle)に分割されているとします。Bundle、サービス・レイヤーBundle、データ・レイヤーBundle、そしてドメイン・モデルBundleという具合です。そのようなアプリケーションを図示すると以下のようになります。(訳注:本家ではここで上記の例のWebアプリケーションが概念図として図示されています。このページの一番上の図です。)この例の場合、データ・レイヤーバンドルはいくつかの内部的コンポーネント(bean)を含むデータ・レイヤー・アプリケーション・コンテキストに処理を委譲しています。このうち2つのbeanはOSGiサービス・レジストリ内のサービスとして公開されている外部のアプリケーション・コンテキストから構成されています。サービス・レイヤーBundleはいくつかの内部的なコンポーネント(bean)を含んだサービス・レイヤー・アプリケーション・コンポーネントに委譲しています。これらのうちいくつかのコンポーネントはデータ・レイヤー・サービスに依存し、それらのサービスをOSGiレジストリからインポートしています。サービス・レイヤーコンポーネントのうち2つはOSGiサービス・レジストリを通して外部に公開されています。WebコンポーネントBundleは数個のコンポーネント(bean)を含むWebアプリケーション・コンテキストに処理を委譲しています。それらのいくつかのコンポーネントはアプリケーション・サービスに依存し、OSGiレジストリを通してそれらのサービスをインポートしています。ドメイン・モデルBundleはドメイン・モデル・タイプにだけ関与していますが、しかし自分自身のコンポーネントを作る必要がありません。アプリケーション・コンテキストには関連していません。Bundleとしてパッケージングされていなければなりません。Bundleとは、OSGiサービス・プラットフォームに認識される一連のヘッダーが記述されているMETA-INF/MANIFEST.MFを含んだjarファイルに過ぎません。3.2を参照してください。いくつかのOSGi実装では解凍されたjarファイルもサポートしますが、フォーマットは一緒です。Extenderは以下の片方か両方の条件を満たしたBundleを'Spring-powered'と認識し、そしてBundleが起動された時に付随するアプリケーション・コンテキストを作成します。META-INF/springフォルダ内に1つ以上の".xml"ファイルを持つ場合。META-INF/MANIFEST.MFが'Spring-Context'のマニフェスト・ヘッダーを持つ場合。Bundleのバージョン(Bundle-Version)を満たしている場合にのみそのBundleを認識します。3.2.5で規定されているバージョン範囲の文法に従っている必要があります。'Spring-Context'ヘッダーがない場合、ExtenderはMETA-INF/spring内の各".xml"が有効なSpring設定ファイルでないか確認し、全てのディレクティブ(下記参照)をデフォルト値として設定されたとみなします。アプリケーション・コンテキストはこれらの設定ファイルから作成されます。推奨される方法はアプリケーション・コンテキストの設定を最低2つのファイルに分割することです。「modulename-context.xml」と「modulename-osgi-context.xml」です。modulename-context.xmlにはOSGiには依存しない普通のbean定義を、modulename-osgi-context.xmlにはOSGiを通して公開されたり参照したりするbeanの定義を記述します。schemaをトップレベルnamespaceとして使用することもできます。Spring-Contextマニフェスト・ヘッダーは設定ファイルの代替セットを指定する為に使うこともできます。fragments)として解決されます。Spring-Contextヘッダーが1つ以上の設定ファイルの場所を定義している場合、META-INF/spring内のファイルはSpring-Contextヘッダーで指し示されない限り無視されます。Spring-Contextヘッダーの文法は、下記の通りです。*この文法はOSGiサービス・プラットフォーム共通ヘッダー文法と一貫しています。config/account-security-context.xmlとある場合、Bundleのjarファイルの中のaccount-data-context.xmlとaccount-security-context.xmlがアプリケーション・コンテキストの初期化に使用される。Spring-Contextにはいくつかの有効なディレクティブがある。↓アプリケーション・コンテキストの生成の同期/非同期(デフォルト)を指定する。*;create-asynchronously=falseアプリケーション・コンテキストの生成を同期で行う。設定ファイルはMETA-INF/spring内の全ての"*.xml"ファイルが使用される。config/account-data-context.xml;create-asynchrously:=falseアプリケーション・コンテキストの生成をconfig/account-data-context.xmlを使用し同期で行う。注意する点としては、「同期」オプションでアプリケーション・コンテキストの生成を行う場合、生成作業がOSGiのイベントスレッド内で行われるという事です。生成終了まで次のイベント処理は保留されます。同期オプションでアプリケーション・コンテキスト作成中にエラーがあった場合、FrameworkEvent.ERRORが発生します。そのBundleはアクティブ化中のステートのままになります。(訳注:ずーっとstartedのままということだと思います。↓アプリケーション・コンテキストの生成が全ての必須の依存サービスを待つか、全ての依存が解決される前に次に進むか(デフォルト)を指定する。config/osgi-*.xml;wait-for-dependencies:=falseconfディレクトリ内の"osgi-*.xml"にマッチするファイルを使用してアプリケーション・コンテキストを作成する。アプリケーション・コンテキストの作成は依存性の解決を待たずに次に進む。この動作は本質的に、必須のサービス参照がオプショナルのように扱われる。オブジェクトの使用者(client)はその初期において本来の状態にないサービスオブジェクトがインジェクトされているかもしれない。必須な依存の解決をあきらめてアプリケーション・コンテキスト作成がタイムアウトするまでの時間(秒数)。この設定値は「wait-for-dependencies:=false」が設定されると無視される。*;timeout:=60アプリケーション・コンテキストの作成は、必須の依存を1分(60秒)まで待ちます。↓アプリケーション・コンテキスト自身をOSGiサービス・レジストリへ公開するか公開しないかを設定する。デフォルトは「公開する」。*;publish-context:=falseSpring-Contextのマニフェスト設定がないか、設定がされていないディレクティブがある場合、デフォルトが自動的に設定される。↓Bundle固有の設定とは別に、Spring-DMではコアのExtenderの基本的な動作を設定することができます。これはSpring-DMが'managed'な環境の中に組み込まれていたり、Bundle-wideな機能性を求められるときに便利です。設定の変更を有効にする為に、Extenderはデフォルトを上書きするためにOSGiのフラグメント?を利用します。ExtenderはそのBundle空間内のMETA-INF/springディレクトリにあるXMLファイルを見に行きます。それを元に自分自身を設定するための内部的なアプリケーション・コンテキスト(OsgiBundleXmlApplicationContext型)を作成します。Extenderのデフォルト設定を変更するには、目的に応じたbean名を下記のテーブルから探し、適切なフォーマットで設定してから下記のようにspring-osgi-extender.jarフラグメント?にアタッチする必要があります。org.springframework.bundle.osgi.extender現在の所、下記のbean名がExtenderに対して有効です。executerはアプリケーション・コンテキスト自身のスレッド・プールの管理について責任を持ちます。SimpleAsyncTaskExecutorがデフォルトで使用され、各アプリケーション・コンテキストについて新しいスレッドが作成されます。これは開発やテストの為には良いかもしれませんが、本番環境ではスレッド・プールを使用することを強くお勧めします。各Bundleに関連付けられているSpringアプリケーション・コンテキストを廃棄します。executerはアプリケーション・コンテキスト自身のスレッド・プールの管理について責任を持ちます。TimerTaskExecutorがデフォルトで使用され、全てのアプリケーション・コンテキストは適切な順番で非並列的に破棄されます(一つ一つ順番に破棄されるということ?)。普通は破棄の順番は適切であるべきなのでデフォルトの設定か、もしくは管理された同時に1つだけ破棄が実行されるスレッド・プールのような実装を使用することが推奨されます。「コンテキスト全体の終了までの最大許容時間」などのプロパティーです。下記の「デフォルト」を参照。ApplicationEventMultiCasterはSpring-DMのイベントを他のベンダーのコードに伝達します。SimpleApplicationEventMulticasterのインスタンスが使用されます。アプリケーション・コンテキスト内での使用可能なbeanに関する情報は「AbstractApplicationContext」のjavadocを参照してください。extenderによって作成されるアプリケーション・コンテキストのカスタマイズ機能を提供します。これはアプリケーション・コンテキストのclass型の変更やさらなる追加処理を含みます。Extenderのデフォルトの動作が適用されます。型のbeanは自動的に検知され、extenderによって作成された全てのコンテキストに適用されます(user-definedかどうかにかかわらず)。factoryによって既存のbeanの追加/削除/変更や新しいbeanのインスタンスの追加に便利です。Extenderのデフォルト動作が適用されます。packageextenderPropertiesでは、下記のプロパティーが使用できます。extenderが各アプリケーション・コンテキストの完全な停止を待つ合計時間。ミリ秒単位で指定します。extenderがSpring-DMのアノテーションを処理するかどうかのフラグです。processorを設定することによって有効になることに注意してください。injection”?を参照してください。IoCコンテナの全機能はExtender設定beanを作るために使用できます。(訳注:ちょっと意味が不明。↓(例えば、)ログを残す為にアプリケーション・コンテキスト作成の成功・失敗を知りたいことがあります。org.springframework.osgi.context.eventというOSGiアプリケーション・コンテキストがそのライフサイクル中に発するイベントを扱うパッケージを提供しています。現時点では以下のイベントがあります。OSGiアプリケーション・コンテキストが正常に初期化、又はリフレッシュされた時に発行されます。(例:ConfigurableApplicationContextインターフェースのrefresh()メソッドが使用された場合。)アプリケーション・コンテキストのライフサイクル中でこのイベントが何回発生するかは保障できません。使用している実装に依存します。アプリケーション・コンテキストが異常によりcloseされた時に発行されます。このイベントはアプリケーション・コンテキストのライフサイクル中にいつでも発生する可能性があります。リフレッシュ前、リフレッシュ中、リフレッシュ後。一般的には設定的なエラーを表します。ミスタイプ、文法的誤り、必要なbeanの定義忘れ、など。これらのイベントを受け取りたい場合は、OsgiBundleApplicationContextListenerを実装し、それをOSGiサービスとして公開しておく必要があります。extenderは自動的にlistenerを発見し、そのlistenerにイベントを送信します。OSGiサービス・レジストリよりも優れている点として、extenderはイベント発行側からの結合を疎なものにておくことができ、さらに登録/登録解除を簡単にします。クライアントがlistenerを登録解除することは何も特別なことではありません。Bundleを停止すると自動的に全ての発行されているサービス(その中にはlistenerも含む)が登録解除されます。extenderによって検出されたイベントはlistenerを登録解除します。Bundleのライフサイクル中にクライアントがマニュアルでlistenerを登録解除することもできます。NoteSpring-DMのイベントの意味づけはSpringのイベントの意味づけと若干異なります。OSGiイベントは原因となったアプリケーションの内部のbeanには送信されませんが、他の(おそらく他のアプリケーション・コンテキスト内のbean)監視をしているbeanには送信されます。extenderが正常に動作する為にいくつかのOSGiプラットフォームにインストールされるべきBundleを提供しています。FrameworkのいくつかのBundleをインストールする必要があります。2.5の場合、Springの配布物の中のいくつかの.jarはOSGiのBundle形式になっていて、OSGiプラットフォームへ直接インストールすることができます。必要とされる最低限のBundleは以下のとおりです。org.springframework.bundle.spring.aop)さらに、下記のライブラリのBundleが必要です。Modulesの配布物の中に含まれています。classを使う場合。versionを強く推奨します。)log4jのようなlogging実装。2.0では(その他の機能と共に)使いやすいXMLによる設定ファイルと拡張可能なXML設定が導入されました。infrastructureによってカスタムXMLスキーマを自動的に検出する機能を含みます。Spring-DMにおいてはOSGi環境の中でも追加コードの記述やmanifestの記述なしにBundleに対してカスタム・スキーマの検出が行われます。namespace宣言を作成する為にSpring-DMによってスキャンされます。(Bundle内のMETA-INF/spring.handlersとMETA-INF/spring.schemas)検出された場合、Spring-DMはスキーマとnamespaceをOSGiサービス内に作成し、自動的にSpring-poweredの他のBundleから使用可能にします。このことは、カスタム・スキーマを使用しているBundleを配備した場合、他にはそれに該当するnamespaseとスキーマを処理するライブラリを配備するだけです。カスタム・スキーマをそのclasspathに内包しているBundleは利用可能なOSGi環境を通してそれを利用できます。内包されているライブラリのnamespaceは他のBundleと共有されません。それらは他のBundleからは不可視です。namespaceは他の作用なく透過的にサポートされます。内包されたnamespaceプロバイダは優先的に使用されますが、共有はされません。反対に、Bundleとして配備されたプロバイダは他のBundleに対しても公開されます。↓Manifestヘッダー内の「Import-Package」と「Export-Package」についての詳細はOSGiプラットフォームのドキュメントを参照してください。BundleはBundleが依存する全ての外部パッケージへの「Import-Package」エントリーが必要になります。そのBundleが他のBundleがアクセスする為の型(原文:type、多分Javaで言えばclassとかenumとかでしょう)を提供している場合、それらの外部から見えるようにしたいパッケージの全てに「Export-Package」エントリーが必要です。loaderがJ2SEで大したファンファーレ無しでこっそり導入されました。下記はJavaサイトにあるチュートリアルの中から引用した短い定義です。loader」の概念を導入しました。loaderにセットされています。スレッドの階層構造は根源スレッド(プログラムが動いているスレッド)を根としています。loaderにセットされています。loaderにセットされています。loaderはアプリケーションがロードすることのできるclassをロードすることができるということです。runtimeがユーザアプリケーションに代わってclassやリソースをロードするのに使われます。loaderを持ち、先に説明したのと同じ委譲モデルをサポートしています。loaderからアクセスできるとものと仮定しています。loaderを使っておらず、ローダーは主にマルチスレッド化されているアプリケーション・サーバやコンテナから使用されています。loaderから参照可能な型やリソースのセットは定義されていません。loaderからの値を保障しない、別の言い方をすれば「管理していない」ということです。したがって、独自にclassを読み込んだりclassを動的に生成するコード(例えばライブラリのようなコード)はOSGi環境内では問題を引き起こす可能性があります。loaderを通してアクセス可能であることを保障します。loaderを通して何がアクセス可能かをコントロールすることを可能にします。このことについての詳細はセクション5を参照してください。headerやEquinoxのbuddyメカニズムのように特定のOSGi実装が提供する機能に依存し続けなくてはなりません。Modulesのドキュメントではよく知られたエンタープライズ・ライブラリーの知られていない問題やその回避策にも言及します。選択したOSGiプラットフォーム実装はOSGi環境の現在の状態についての十分多くの情報提供しているはずです。Equinoxを-console引数で起動した場合、コマンドライン・コンソールを通じて、インストールされているBundleとそのステータス、Bundleが公開しているサービスやパッケージを確認することができ、Bundleがfailしている理由を確認ることができ、Bundleのライフサイクルをコントロールすることができます。ModulesのBundleは問題解決の助けとなる拡張可能なロギングシステムを含んでいます。Bundleの形式になっています)を配備することです。classpathのrootに作成するだけです。APIを使用しており、ロギング実装は完全にプラガブルです。log4j以外の実装を使用したロギングの設定方法の詳細についてはFAQや巻末の情報ページを参照してください。mod_perl/2.0.11。