Журналирование Java против Log4J [закрыто]

Стоит ли по-прежнему добавлять библиотеку log4j в проект Java 5 только для того, чтобы регистрировать, скажем, некоторые исключения в файле с некоторыми хорошими настройками опрокидывания. Или стандартная утилита util.logging тоже сделает эту работу?

Что вы думаете?

Я бы сказал, что вы, вероятно, в порядке с util.logging для нужд, которые вы описываете.

Для хорошего дерева решений, посмотрите на Log4j против java.util.logging

Вопрос первый: ожидаете ли вы необходимости в каком-либо из умных обработчиков, которые есть у Log4j, которых нет в JUL, таких как SMTPHandler, NTEventLogHandler или какой-либо из очень удобных FileHandlers?

Вопрос второй: Видите ли вы, что хотите часто переключать формат выходных данных журнала? Вам понадобится простой и гибкий способ сделать это? Другими словами, вам нужен PatternLayout Log4j?

Вопрос третий. Ожидаете ли вы определенной необходимости изменять сложные конфигурации ведения журналов в ваших приложениях после их компиляции и развертывания в производственной среде? Звучит ли ваша конфигурация примерно так: «Серьезные сообщения из этого класса отправляются по электронной почте сотруднику службы поддержки; серьезные сообщения из подмножества классов регистрируются в системном журнале на нашем сервере; предупреждающие сообщения из другого подмножества классов регистрируются в файл на сетевом диске A, а затем все сообщения отовсюду записываются в файл на сетевом диске B "? И ты видишь себя настраивающим это каждые пару дней?

Если вы можете ответить «да» на любой из вышеперечисленных вопросов, перейдите с Log4j. Если вы ответите однозначно "нет" на все из них, JUL будет более чем достаточным, и он уже удобно включен в SDK.

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

Я рекомендую вам использовать Simple Logging Facade для Java (SLF4J). Он поддерживает различные провайдеры, которые включают Log4J и может использоваться в качестве замены для ведения журнала Apache Commons.

Log4j существует уже давно и работает очень хорошо. У меня нет научных исследований, подтверждающих это, но, исходя из того, что я видел у большого числа клиентов, я легко использую каркас регистрации, который используется больше, чем любой другой. Он существует уже давно и не был заменен Next Big Logging Framework, который что-то говорит.

Он очень прост в настройке и прост в освоении основных дополнений (выходов). Есть целый ряд доступных приложений, в том числе:

1. ConsoleAppender
2. DailyRollingFileAppender
3. ExternallyRolledFileAppender
4. FileAppender
5. JDBCAppender
6. JMSAppender
7. NTEventLogAppender
8. RollingFileAppender
9. SMTPAppender
10. SocketAppender
11. SyslogAppender
12. TelnetAppender
13. WriterAppender

Плюс другие. Это не сложно написать свой собственный аппендер. Кроме того, в каждом из приложений есть большая гибкость, позволяющая вам точно контролировать, что выводится в вашем журнале.

Одно замечание: у меня был ряд проблем с загрузчиком классов, когда я использовал протоколирование Apache Commons в дополнение к log4j. Это было только для одного конкретного приложения, но я обнаружил, что проще использовать log4j отдельно, чем иметь гибкость, предлагаемую при использовании уровня абстракции, такого как регистрация общего достояния.

Смотрите эту статью для более подробной информации :

Удачи!

java.util.logging предлагает комплексный пакет регистрации без лишнего багажа, который предоставляют некоторые другие.

log4j - намного более приятный пакет в целом, и в нем нет некоторых ошибок, которые содержит java.util.logging. Во-вторых, использование log4j напрямую проще, чем ведение журнала.

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

Я бы пошел с log4j. Возможности с log4j совсем не устарели!