2012-06-21 2 views
15

Я использую SLF4j в качестве моей рамки ведения журнала, поддерживаемой log4j. Моя проблема в том, что я ищу способ изменить уровень ведения журнала для моего регистратора во время выполнения.Как изменить уровень slf4j во время выполнения?

Я понимаю, что slf4j не разрешает это напрямую через свой собственный API, и, следовательно, я должен напрямую обращаться к поставщику протоколирования. Лично я считаю, что это большой недостаток в slf4j. Итак, теперь мой вопрос заключается в том, как я могу определить программно через slf4j, какой провайдер я использую? Самая большая цель использования slf4j заключается в том, что вы становитесь агностиком провайдера - вы можете легко переключаться между вашей любимой системой ведения журнала, не перерабатывая ничего. Но теперь, если мне нужно делать прямые вызовы log4j, я теряю эту способность.

По крайней мере, я хотел бы иметь возможность определить, использую ли я log4j в качестве провайдера, и если да, то разрешите пользователю переключаться на уровни журналов.

Если я делаю LoggerFactory.getLogger(Logger.ROOT_LOGGER_NAME), результатом является пример org.slf4j.impl.Log4jLoggerAdapter и даже не org.apache.log4j.Logger (как я бы надеялся/ожидал).

Есть ли способ узнать это?

Спасибо, Эрика

+1

См.: [Как найти, к какой библиотеке slf4j привязали себя?] (Http://stackoverflow.com/questions/10505418) –

+0

Спасибо. Я не уверен, почему я пропустил это в своем первоначальном поиске. –

ответ

13

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

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

+3

Справедливо, если SLF4J используется исключительно для библиотек. Однако мне кажется, что что-то настолько гибкое в библиотеке также должно быть доступно для использования в вашем приложении. Концепция наличия единого API, к которому я могу подключить любую систему ведения журнала, является фантастической. Кроме того, чаще всего часть вашего приложения в конечном итоге реорганизуется в библиотеку. Нужно перекодировать любые ссылки на log4j, чтобы стать slf4j, не имеет смысла. Если SL4j был разработан только для библиотек (которые я не читал на сайте slf4j), я нахожу это недальновидным. –

+3

Извините, не прояснилось: вам обязательно нужно использовать SLF4J для вызовов регистрации вашего приложения. Но в небольшой части вашего кода, который касается изменения конфигурации ведения журнала, просто введите материал в классы Log4J. Если вы решите переключить реализации протоколирования, вам все равно придется переписать этот бит. – artbristol

+0

Согласовано. Просто пытался сделать все в целом. Думаю, это просто невозможно. Это даже не вопрос кастинга - я должен делать вызовы с использованием классов Log4j напрямую (т. Е. Использовать log4j.Logger вместо slf4j.LoggerFactory для извлечения регистраторов) –

Смежные вопросы