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

117

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

  • Ведение журнала Java
  • Ведение журнала Commons
  • Log4j
  • SLF4J
  • Logback
Loki
источник
4
Возможно, вам понадобится stackoverflow.com/questions/873051 , который сравнивает SLF4j с ведением журнала Commons.
Джеймс МакМахон,
24
Какого черта Цеки создал 3 фреймворка логирования !!! это безумие ...
МП.
6
@mP. - первым был log4j, потом возникли разногласия, и было написано slf4j + logback. slf4j - это API, а реализация API завершена. Независимо от всего остального, slf4j чрезвычайно полезен.
Торбьёрн Равн Андерсен
3
Подробнее о том, почему Ceki Gülcü действительно создал SLF4J + Logback, см. В следующем выступлении Devoxx: parleys.com/#st=5&id=1701
bitek
Лучшее, что из этого получилось, - это API slf4j, который, надеюсь, объединит мир ведения журналов. Я думаю, что логбэк еще не достиг критической массы у разработчиков.
Торбьёрн Равн Андерсен

Ответы:

86

В хронологическом порядке появления 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 и его конфигурацию
Стивен
источник
3
Насколько я могу судить, идея ведения журнала Commons заключается в том, что его следует использовать в библиотеках. Таким образом, библиотека всегда может использовать ту же структуру ведения журнала (через ведение журнала общего пользования), которую использует хостинговое приложение.
Иоахим Зауэр
Большое спасибо Локи за вопрос. Теперь я знаю, что больше не собираюсь использовать log4j в качестве фреймворка по умолчанию. SLF4j FTW! Также спасибо Ken G за указание на то, что SLF4j написан тем же парнем, что и log4j
Стивен
3
Комментарий в вашем примере кода неверен на 100%. Фактическое форматирование сообщения выполняется Logback лениво, поэтому это произойдет только в том случае, если событие действительно обрабатывается приложением, а приложение требует форматированного сообщения - чего не произойдет, например, в случае SocketAppender, поскольку событие сериализуется с использованием неизмененный шаблон сообщения + аргументы в виде строк. Я думаю, это просто зависит от того, как вы определяете «эффективно». Он определенно будет выдавать одно и то же сообщение (по крайней мере, если запись и объект совпадают;)), поэтому, пожалуйста, простите мои придирки.
Хуси
6
SLF4J на самом деле - это просто API, который находится поверх других фреймворков ведения журналов. Подобно цели Commons Logging, но, судя по моему опыту, более интуитивно понятно.
Джеймс МакМахон,
37

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

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

Жюльен Частанг
источник
19
Это ответ? Это больше похоже на разглагольствование.
Майкл Майерс
15
Я прошу прощения. Это является немного тирады. Но это также убедительный ответ на вопрос «Что случилось с ведением журнала в Java?». Короче говоря, он глубоко сломан.
Жюльен Частанг,
1
ну это не стоит -1 голосов; P Но есть над чем задуматься.
guyumu
21
Проблемы начались, когда Sun фактически добавила java.util.logging в Java 1.4. До этого LOG4J был хорошо известен и широко использовался. После этого возникла необходимость в оболочках для поддержки как LOG4J, так и java.util.logging. Кроме того, поскольку jul содержится в пакете java. *, Его нельзя заменить заменой JAR - таким образом SLF4J соединяет другие фреймворки. Вероятно, это была худшая идея Sun за всю историю ... и в конечном итоге она привела к неверному предположению, что "хороший гражданин Java" должен использовать jul.
Хуси
4
@Huxi, я утверждаю, что Calendar API был хуже. В защиту Sun это был не их код, а исходил от Таглиента.
Thorbjørn Ravn Andersen
22

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

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

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

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

Huxi
источник
2
Технически это локальный поток Map <String, String>.
pdxleif
17

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

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

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

Кен Джентл
источник
4

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

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

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

Маркус Лаусберг
источник
4

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

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

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

kdgregory
источник
1
Также есть мост commons.logging => SLF4J, который можно использовать для маршрутизации всех журналов CL через SLF4J. SLF4J поддерживает соединение commons.logging, LOG4J и (немного громоздко, но максимально хорошо) java.util.logging, поэтому все журналы будут помещаться в любой сервер SLF4J, который вы будете использовать. См. Slf4j.org/legacy.html Я бы использовал Logback, кстати, но вы можете возразить, что я предвзят.
Хуси
2

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

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

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

Майкл Резерферд
источник
Не возражал против зависимости от 1.4 ?? Даже 1.4 подошел к концу срока службы.
Том Хотин - tackline
2
@Tom Он имеет в виду jdk1.4 +, не будь глупым.
М.П.
На самом деле я недавно проделал некоторую работу в системе, которая все еще работала под jdk 1.3 :-(, и это было меньше двух лет назад, я последний раз поддерживал систему jdk 1.2 . Слишком много мест не обновляются, если у них нет абсолютно до, они просто отказываются устанавливать обновления.
Майкл Рутерферд,
0

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

tsimon
источник
2
Это то, что делает обычная регистрация, так зачем изобретать велосипед? Также есть некоторые проблемы, с которыми ваш фасад должен будет справиться, что уже делает журнал общего доступа.
Джеймс А. Н. Штауфер,
+1 Чтобы противостоять аргументу о ведении журнала общего пользования, некоторые корпоративные приложения используют настраиваемое средство ведения журнала. Всегда полезно скрыть базовую реализацию. «Тонкая» обертка избавляет от необходимости упаковывать еще одну банку и требует меньше изобретений.
questzen
1
Это спасло меня недавно, когда мы портировали наш фреймворк на Compact Framework (в .Net). Если бы у нас были жестко запрограммированные зависимости от nLog, мы бы облажались. Поскольку мы использовали этот подход, мы смогли добавить нулевой регистратор и быть счастливыми. Кто-нибудь проголосует за меня до 0, пожалуйста :-)
tsimon
3
Один уже существует - взгляните на slf4j. Это общепринятая тонкая оболочка, которая позволяет переключать фреймворки ведения журналов при запуске приложения путем переключения jar-файлов в пути к классам среды выполнения.
Dedeb
1
У засорения есть свой способ узнать, какой фреймворк он будет использовать - это не красиво и довольно запутанно. Сколько фреймворков логирования создал Ceki. Всегда следует стремиться выделить уровень взаимного взаимодействия и скрыть реализацию, даже если она засоряется вашим собственным журналированием. За кулисами вы можете подключить все, что пожелаете, как упомянул Трэвис.
М.П.