Что случилось с логированием в Java? [закрыто]

Зачем использовать один из следующих пакетов вместо другого?

• Ведение журнала Java
• Ведение журнала Commons
• Log4j
• SLF4J
• Logback

В хронологическом порядке появления 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, поэтому он сделал его лучше (по словам Кена Джи - спасибо. Кажется, он подходит, если посмотреть на их более ранние сообщения в новостях )
• SLF4j, потому что они также публикуют адаптер log4j, поэтому вам не нужно «отключать» log4j в старом коде - просто заставьте log4j.properties использовать SLF4j и его конфигурацию

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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