Стоит ли по-прежнему добавлять библиотеку 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, который что-то говорит.
Он очень прост в настройке и прост в освоении основных дополнений (выходов). Есть целый ряд доступных приложений, в том числе:
Плюс другие. Это не сложно написать свой собственный аппендер. Кроме того, в каждом из приложений есть большая гибкость, позволяющая вам точно контролировать, что выводится в вашем журнале.
Одно замечание: у меня был ряд проблем с загрузчиком классов, когда я использовал протоколирование Apache Commons в дополнение к log4j. Это было только для одного конкретного приложения, но я обнаружил, что проще использовать log4j отдельно, чем иметь гибкость, предлагаемую при использовании уровня абстракции, такого как регистрация общего достояния.
Смотрите эту статью для более подробной информации :
Удачи!
java.util.logging предлагает комплексный пакет регистрации без лишнего багажа, который предоставляют некоторые другие.
log4j - намного более приятный пакет в целом, и в нем нет некоторых ошибок, которые содержит java.util.logging. Во-вторых, использование log4j напрямую проще, чем ведение журнала.
Я рекомендую использовать Apache Commmons Logging в качестве интерфейса регистрации. Таким образом, вы можете гибко переключать реализации ведения журналов в любое время, не требуя каких-либо изменений кода с вашей стороны.