Как получить логи slf4j и до сих пор не зависит от бэкэнда логов?

Question

Я использую SLF4J в качестве фасада регистрации и позволяю пользователям решать, где и что регистрировать. Теперь в случае сбоя я хочу отправить на сервер файл, содержащий отладочную информацию, что в основном означает лог-файл. И поскольку у нас уже есть все эти лог-операторы, разбросанные по коду, почему бы не использовать их?

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

Моя первая идея состояла в том, чтобы реализовать org.slf4j.impl.StaticLoggerBinder, доставить мою собственную реализацию регистратора, который ведет его регистрацию, а затем делегирует регистратору, настроенному пользователем. Тем не менее, я вижу некоторые проблемы с этим: если пользователь устанавливает нормальный бэкэнд регистрации, то несколько путей org.slf4j.impl.StaticLoggerBinder находятся в пути к классам. Это выдаст предупреждение, и я, возможно, не смогу убедиться, что моя реализация - это та, которую нужно вызвать.

Есть ли лучшие решения для этого? Совсем другой подход? Идея изначально плохая? Как это сделать?

Answer 1

Смысл SLF4J состоит не в том, чтобы позволить конечным пользователям приложения выбирать свою среду ведения журналов (зачем им это важно?), А в том, чтобы позволить разработчикам включать библиотеку, не привязываясь к выбранной библиотекой структуре ведения журнала.

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

Answer 2

Поскольку SLF4J с открытым исходным кодом, вы можете изменить его, чтобы использовать другой класс, чем org.slf4j.impl.StaticLoggerBinder.Тогда ваш пользовательский класс StaticLoggerBinder может загрузить исходный предоставленный пользователем org.slf4j.impl.StaticLoggerBinder (если он существует).

Другая идея заключается в использовании пользовательского LoggerFactory (не org.slf4j.LoggerFactory) в вашем приложении, которое возвращаетLogger делегат.Этот метод регистрации делегатов класса делегатов вызывает исходную реализацию Logger, а также отправляет журналы на сервер, если это необходимо.

В любом случае, оба будут выглядеть неудобно для меня, создав два артефакта (один дляконечные пользователи и еще один для разработчиков) пахнет лучше.

(Наконец, я не знаю, что это за библиотека / приложение, но в моей рабочей среде было бы неприемлемо, если библиотека отправляет данныена сторонний сервер. Вы уверены, что вам действительно нужно это сделать?)