Что случилось с логированием в Java?

В хронологическом порядке появления api (насколько мне известно):

• Log4j, потому что его используют почти все (по моему опыту)
• Commons Logging, потому что его используют проекты с открытым исходным кодом (чтобы они могли интегрироваться с любой платформой ведения журнала, используемой в интегрированном решении); особенно актуально, если вы являетесь API / Framework / OSS и полагаетесь на другие пакеты, которые используют Commons Logging.
• Commons Logging, потому что вы не хотите «ограничиваться» определенной структурой ведения журнала (вместо этого вы ограничиваетесь тем, что дает вам Commons Logging) - я не думаю, что разумно использовать этот момент в качестве причины.
• Ведение журнала Java, потому что вы не хотите добавлять дополнительную банку.
• SLF4j, потому что он новее, чем Commons Logging, и обеспечивает параметризованное ведение журнала:

logger.debug("The entry is {}.", entry);
//which expands effectively to
if (logger.isDebugEnabled()){
    // Note that it's actually *more* efficient than this - see Huxi's comment below...
    logger.debug("The entry is " + entry + "."); 
}

• Logback, потому что он новее, чем log4j, и снова поддерживает параметризованное ведение журнала, поскольку он напрямую реализует SLF4j
• SLF4j / Logback, потому что он написан тем же парнем, что и log4j, поэтому он сделал его лучше (согласно Ken G - спасибо. Кажется, подходит, если смотреть на их предыдущие посты в новостях)
• SLF4j, потому что они также публикуют адаптер log4j, поэтому вам не нужно «отключать» log4j в старом коде - просто заставьте log4j.properties использовать SLF4j и его конфигурацию

Обычно я бы по умолчанию использовал Log4J.

Я бы использовал ведение журнала Java, если бы не возражал против зависимости от Java 1.4, но все же предпочел бы использовать Log4J.

Я бы использовал Commons Logging, если бы улучшал то, что уже использовал.

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

В проекте нашей компании мы используем LOG4j, и он очень прост в использовании, как показал Стивен в своем примере. Мы также написали наши собственные классы шаблонов для LOG4j, чтобы вы могли создавать свои собственные схемы выходных файлов. Вы можете описать, как должен выглядеть ваш файл журнала. Можно улучшить исходные классы log4j.

Все свойства LOG4j вы можете изменить в файле log4j.properties, чтобы вы могли использовать разные файлы для разных проектов.

Ведение журнала Java мне не нравится, но это может быть связано с тем, что я использую log4j с самого начала.

См. Также ответы на вопрос Как лучше всего регистрировать ошибку?, особенно:

• Есть некоторый потенциал проблемы с загрузкой классов с Commons Логирование.

• Log4J и SLF4J были разработаны тот же человек, учится у проблемы, обнаруженные на практике с Log4J.

Обзор Commons Logging объясняет причину своего существования: ведение журнала из кода библиотеки, когда у вас нет контроля над базовой структурой ведения журнала. Очень важно для различных проектов Apache, которые будут связаны с внешними приложениями. Возможно, это не так важно для внутренних ИТ-проектов, где у вас есть полный контроль.

Тем не менее, я пишу в Commons Logging, как и многие другие разработчики, которых я знаю. Причина в том, чтобы свести к минимуму умственный багаж: вы можете менять проекты или работу, и вам не нужно изучать новую структуру (при условии, что новая работа / проект также использует CL, и / или вы можете убедить их перейти на нее).

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

Я считаю, что ведение журнала в Java сбивает с толку, непоследовательно, плохо документировано и особенно бессистемно. Более того, между этими фреймворками ведения журнала существует огромное количество сходства, что приводит к дублированию усилий и путанице относительно того, в какой среде ведения журнала вы на самом деле находитесь. В частности, если вы работаете в серьезном стеке веб-приложений Java, вы часто находитесь в несколько журналирования среды за один раз; (например, спящий режим может использовать log4j и tomcat java.util.logging). Apache Commons предназначен для объединения различных платформ ведения журналов, но на самом деле просто добавляет больше сложности. Если вы не знаете этого заранее, это вызывает крайнее недоумение. Почему мои сообщения журнала не выводятся на консоль и т. д.? Ох, потому что я смотрю журналы Tomcat, а не log4j. Добавляя еще один уровень сложности, сервер приложений может иметь глобальные конфигурации ведения журнала, которые могут не распознавать локальные конфигурации для конкретного веб-приложения. Наконец, все эти структуры ведения журналов СЛИШКОМ СЛОЖНЫ. Вход в Java был беспорядочным и беспорядочным, оставляя таких разработчиков, как я, разочарованными и сбитыми с толку.

В ранних версиях Java не было встроенной среды ведения журнала, ведущей к этому сценарию.

Есть один важный момент, о котором раньше не упоминалось:

SLF4J (и Logback, и LOG4J в качестве серверной части журналирования) поддерживают так называемый сопоставленный диагностический контекст (MDC, см. javadoc и документация).

По сути, это локальная для потока карта <String, String>, которую вы можете использовать для добавления дополнительной контекстной информации к вашему событию регистрации. Текущее состояние MDC привязано к каждому событию.

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