Выходит ли Log4j в пользу Slf4j?

Кажется, что log4j имеет некоторые проблемы с загрузкой классов (иными словами), и мне кажется, что тенденция состоит в том, чтобы выйти из log4j в сторону slf4j. (Hibernate остановился, используя первый в пользу последнего)

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

Обновление:

Итак, этот ответ от delfuego меня смущает, можете ли вы его принять/возразить?:

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

Больше проблем с загрузкой по log4j: http://articles.qos.ch/classloader.html

Ответ 1

Slf4j - это действительно просто каротажный фасад. Тем не менее, Log4j должен сменяться Logback от тех же авторов.

Обновить: если вы хотите узнать о другом преимуществе Slf4j, то тот факт, что следующие (уродливые) конструкции больше не нужны, чтобы избежать ненужного вызова toString():

if (logger.isDebugEnabled()) {
    logger.debug("Message: " + bigObject + ", " + anotherBigObject);
}

Вместо этого вы можете использовать параметризованные сообщения:

logger.debug("Message: {}, {}", bigObject, anotherBigObject);

Также см. Каков самый быстрый способ (не) ведения журнала?

Ответ 2

Slf4J не является альтернативой Log4j, а скорее предоставляет Facade для ведения журнала, поэтому вы можете подключить свою собственную систему ведения журнала. Это в основном полезно для библиотек. от slf4j.org:

Простой логический фасад для Java или (SLF4J) служит простым фасадом или абстракция для различного лесозаготовки рамки, например. java.util.logging, log4j и logback, что позволяет пользователю подключить требуемый журнал рамки во время развертывания.

Чтобы ответить на ваш вопрос: теперь Slf4j принимается каркасами, но в ваших проектах вы можете продолжать использовать Log4J (или любой другой)

Ответ 3

Во-первых: важный момент: Slf4j - это frontend logging (API), который может использоваться ниже большинства основных систем loggin: например log4j или java.util.logging. Поэтому лучше сравнить sfl4j с commons-logging.

О состоянии Log4j, цитаты из Состояние регистрации java (год назад)

Одна вещь, которую я не понял, заключается в том, что разработка log4j практически мертва. В настоящее время он находится в версии 1.2, и планы на версию 1.3 были отменены в пользу разработки log4j 2.0. Однако, похоже, 2.0 не находится в активной разработке. Стоит отметить, что Ceki Gülcü, оригинальный основатель проекта log4j, перешел на slf4j (см. Ниже).

Ответ 4

Глядя на slf4j page, похоже, что он заменит log4j - он просто позволит вам использовать одну и ту же базовую структуру ведения журнала (например, log4j) для всего приложения, позволяя библиотекам автоматически подключаться к ним.

Он больше похож на замену Apocal Commons Logging, чем log4j.

Ответ 5

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

Ответ 6

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

Slf4j не может указать пользовательский файл конфигурации, но заставляет пользователя использовать default (log4j.properties или log4j.xml) на одном из многих корней Java (каждый Jar имеет один корень плюс корень JVM и классы или bin). Если у двух JAR файлов есть это, трудно контролировать, какой из них использовать безопасно.
Slf4j не может поддерживать все уровни Log4j, такие как "фатальный". При переключении большого кода с Log4j на Slf4j требуется огромное усилие изменения кода (например, решение о переупорядочении уровней).
Должны быть выбраны два ключевых файла Jar (log4j-over-slf4j.jar или slf4j-log4j12.jar). Если classpath и то, и другое не будет работать. Если вы выбираете один случайный случай, теряете неожиданные функции (например, log4j-over-slf4j.jar не поддерживает несколько файлов журналов для одних и тех же классов, например, один для журнала событий и один для журнала необработанных данных).