私が4つのレガシーjarを持っているとしましょう：
- my-library.jar
- my-app.jar
- my-other-app.jar
- log4j.jar
「MyApp」と「MyOtherApp」は無関係なアプリケーションであり、どちらもmain（）関数を備えています。どちらも「my-library-app」のさまざまなライブラリ関数を使用しています。3つすべてがlog4jを介してロギングを行います（実際にはslf4jですが、例を単純にしておきたいだけです）。
現在、2つのアプリケーションは2つの異なるlog4j構成ファイルでセットアップされているため、2つの異なるファイルにログが記録されます。
今、私はすべてをOSGiに変換したいと思います。そこで、最初の3つをそれぞれ個別のバンドルとしてバンドルし、実際のアプリのmain（）をアクティベーターに変換して、バンドルするか、log4jの既存のバンドルを見つけます。同じOSGiフレームワークで両方のアプリを起動します。
しかし、2つの異なるアプリが異なるファイルにログインしなくなりました。右？JVMで実行されているlog4jのインスタンスは1つだけであり、その構成は1つのlog4j.propertiesファイルから取得されます。
したがって、4つのjarファイルをそれぞれ個別にバンドルする代わりに、3つのバンドルを作成します。
- 私の図書館
- 私のアプリとlog4j
- 私の他のアプリとlog4j
これで、2つの異なるアプリの異なるログ構成ファイルを取得できます。しかし、マイライブラリからのログ呼び出しはどうですか？My Libraryバンドルはlog4jの2つのコピーの1つにラッチされ、My Libraryから生成されたすべてのログメッセージは、2つのログファイルの1つ（たとえば、My App用）に出力されます。ただし、他のアプリからの呼び出しによるマイライブラリからのログメッセージであっても、それは当てはまります。彼らは間違ったログファイルに行きます。
だから多分バンドル：
- マイライブラリとlog4j
- 私のアプリとlog4j
- 私の他のアプリとlog4j
これで、マイライブラリからのログメッセージは独自のログファイルに送られます。これは、一部のメッセージが間違ったアプリのログファイルに送られるよりも優れていると思いますが、それでもあまり良くありません。そのファイルには両方のアプリからのログメッセージが含まれており、どちらのアプリを対象としたログファイルにもそれらのアプリからのすべてのログメッセージは含まれていません。
だから多分バンドル：
- マイアプリとマイライブラリとlog4j
- 私の他のアプリと私のライブラリとlog4j
しかし今、OSGiのポイントは何ですか？マイライブラリまたはlog4jの使用を共有していません。実際には、さらに悪化する可能性があります。実際のすべてのアプリバンドルに複数のコピーを貼り付ける必要があるjarがたくさんあります。これは、それらの原因となったアプリに関連付けられたログメッセージを確認したいからです。
したがって、バックアップして別のことを試してみてください。これはlog4jでは不可能だと思いますが、（たとえば）slf4jでは元のバンドルプランに戻ることができます。
- 私の図書館
- 私のアプリ
- 私の他のアプリ
- log4j
次に、スレッドがどのアプリからのものであるかを示すMDC情報を各スレッドに入れるようなことをします。そのMDC情報に反応して、どのログファイルに入るのかを判断します。
しかし、それもうまくいかないようです！マイアプリのスレッドからマイライブラリの関数を呼び出すと、マイライブラリから新しいスレッドが生成される可能性がありますが、これは必ずしもそのMDCに関連付けられているとは限りません。
そして、それよりも悪いことです。マイライブラリには、マイライブラリを使用するアプリで共有されるスレッドが含まれている可能性があるため、そのようなマーカーに関連付けることはできません。
だから、全体として、私は困惑しています。任意の提案をいただければ幸いです。前もって感謝します。