Мы рассматриваем наше веб-приложение JEE на предмет запланированного рефакторинга, и одно из предложений - заменить log4jна logbackилиslf4j
Команда не знает, следует ли нам это делать - потому что в настоящее время мы хотим следовать, если ничего не сломано, не исправлять в этой области.
Изменить: я не спрашиваю о сравнении каркасов ведения журналов, но является ли это ценный элемент рефакторинга для изменения каркаса, когда мы вполне довольны log4j
Ответы:
Один важный вопрос, который вы должны принять во внимание: вы создаете библиотеку, которая используется кем-то другим, или вы создаете конечный продукт?
В первом случае SLF4j очень важен, потому что кто-то интегрирует вашу библиотеку в свое программное обеспечение, в котором уже есть регистрация, и было бы хорошо, если бы ваши классы просто использовали это.
Во втором случае я бы сказал, что вы можете оставить все как есть. Возможно, подумайте об использовании slf4j в следующем проекте.
Не. Лучше потратьте время на реализацию полезных, ценных функций.
Если Log4J работает для вас, нет причин менять это. Если это не так, ищите альтернативу, которая делает то, что вам нужно, которая может быть или не быть slf4j.
Просто потому, что кто-то говорит, что что-то лучше, чем что-то другое, никогда не должно быть причиной для изменения всего вашего приложения (или вообще для принятия этого чего-то нового).
Slf4j - это API, который позволяет вам выбирать , использовать ли log4j, logback или ведение журнала jdk по умолчанию во время развертывания, вместо того, чтобы принимать решение во время компиляции (что происходит, когда вы кодируете непосредственно в log4j)
Slf4j также предоставляет конструкцию {}, которая может задерживать дорогостоящие вызовы toString (), полностью их избегая, если инструкция log не включена.
Затем вы можете выбрать двигатель позже.