Ведение журнала OSGi из устаревших приложений?

Допустим, у меня есть четыре устаревших банки:

1. моя -библиотека.jar
2. мой -app.jar
3. мой -другой -app.jar
4. log4j.jar

«Мое приложение» и «Мое другое приложение» — это несвязанные приложения, оба с основными функциями (). Оба они используют различные библиотечные функции из «моего -библиотечного -приложения». Все три ведут журнал через log4j (на самом деле slf4j, но я просто хочу, чтобы пример был простым ).

В настоящее время два приложения настроены с двумя разными файлами конфигурации log4j, что приводит к тому, что они регистрируются в двух разных файлах.

Теперь я хочу преобразовать все в OSGi. Поэтому я объединяю первые три в отдельный пакет, преобразую основные ()реальных приложений в активаторы и либо объединяю, либо нахожу существующий пакет log4j. Я запускаю оба приложения в одной и той же среде OSGi.

Но теперь два разных приложения больше не регистрируются в разных файлах! Верно? В JVM работает только один экземпляр log4j, и он получает свою конфигурацию из одного единственного файла log4j.properties.

Так что, может быть, вместо того, чтобы связывать каждую из моих четырех банок по отдельности, я сделаю три связки:

1. Моя библиотека
2. Мое приложение плюс log4j
3. Мое другое приложение плюс log4j

Теперь я могу получить разные файлы конфигурации ведения журнала для двух разных приложений. Но как насчет вызовов журнала из «Моей библиотеки»? Пакет «Моя библиотека» будет привязан к одной из двух копий log4j, и теперь все сообщения журнала, созданные из «Моей библиотеки», будут выводиться в одном конкретном из двух файлов журнала -, скажем, в файле «Мое приложение». Но это верно, даже если это сообщение журнала из Моей библиотеки из-за звонка из Моего другого приложения! Они перейдут к неправильному файлу журнала.

Так что, может быть, расслоение:

1. Моя библиотека плюс log4j
2. Мое приложение плюс log4j
3. Мое другое приложение плюс log4j

Теперь сообщения журнала из «Моей библиотеки» отправляются в собственный файл журнала, что, я думаю, лучше, чем некоторые из них отправляются в файл журнала неправильного приложения, но все же это не очень хорошо. В этом файле есть сообщения журнала из обоих приложений, и ни один из файлов журнала, предназначенных для любого приложения, не содержит всех сообщений журнала из этих приложений.

Так что, может быть, расслоение:

1. Мое приложение плюс Моя библиотека плюс log4j
2. Мое другое приложение плюс Моя библиотека плюс log4j

Но в чем теперь смысл OSGi? Я не делюсь использованием Моей библиотеки или log4j. А на самом деле, вероятно, будет еще хуже -будет куча jar-файлов, несколько копий которых мне придется вставлять во все мои фактические пакеты приложений просто потому, что я хочу видеть их сообщения журнала, связанные с приложением, которое вызвало их.

Так что, возможно, сделайте резервную копию и попробуйте что-нибудь другое. :Я не думаю, что это возможно в log4j,но в (скажем )slf4j я мог бы вернуться к исходному плану пакета:

1. Моя библиотека
2. Мое приложение
3. Другое мое приложение
4. log4j

А затем я делаю что-то вроде размещения информации MDC в каждом потоке, говоря, из какого приложения поток. Реагируйте на эту информацию MDC, чтобы определить, в какой файл журнала она входит.

Но, похоже, это тоже не сработает! Вызов из некоторого потока в Моем приложении какой-либо функции в Моей библиотеке может привести к созданию нового потока из Моей библиотеки, который не обязательно будет связан с этим MDC.

Хуже того, что :в «Моей библиотеке» может быть какой-то поток, который используется любым приложением, использующим «Мою библиотеку», поэтому он не может быть связан с каким-либо таким маркером.

Так что, в общем, я в тупике. Любые предложения будут ценны. Заранее спасибо.