В заголовке вы найдете стандартную структуру ведения журнала Java, достаточную для ваших нужд?
Используете ли вы альтернативные службы ведения журналов, такие как log4j или другие? Если да, то почему? Я хотел бы услышать любой совет, который у вас есть относительно требований к регистрации в проектах разных типов, и когда интеграция фреймворков действительно необходима и/или полезна.
Регистрация Java JDK в большинстве случаев сама по себе недостаточна. Однако, если у вас есть большой проект, который использует несколько сторонних библиотек с открытым исходным кодом, вы быстро обнаружите, что многие из них имеют разрозненные зависимости ведения журнала.
Именно в тех случаях, когда необходимо абстрагировать ваш API ведения журнала от вашей реализации протоколирования, важно. Я рекомендую использовать slf4j или logback (использует API slf4j) в качестве вашего API, и если вы хотите использовать Java JDK logging, вы все равно можете! Slf4j может выводить на множество различных реализаций журнала без проблем.
Конкретный пример его полезности произошел во время недавнего проекта: нам нужно было использовать сторонние библиотеки, которые нуждались в log4j, но мы не хотели запускать два фреймворка журнала бок о бок, поэтому мы использовали slf4j log4j api wrapper libs и проблема была решена.
Таким образом, протоколирование Java JDK прекрасное, но стандартизованный API, который используется в моих сторонних библиотеках, сэкономит вам время в долгосрочной перспективе. Просто попробуйте представить рефакторинг каждого заявления о регистрации!
java.util.logging(jul) был ненужным с самого начала. Просто проигнорируйте это.
jul сам по себе имеет следующие недостатки:
Самый важный момент: , если вы решитесь определить свой собственный уровень журнала, вы, вероятно, столкнетесь с проблемой утечки памяти!
Здесь вы можете прочитать об этом эффекте:
Это довольно интересное чтение, даже если вы не планируете использовать пользовательские уровни, кстати, поскольку проблема является широко распространенной, которая не просто применима к jul вообще.
Я лично предложил бы использовать SLF4J + Logback для всех целей ведения журнала. Оба проекта координируются Ceki Gülcü, парнем по LOG4J.
SLF4J является достойным (но неофициальным, поскольку он не из той же группы) преемником commons.logging. Это менее проблематично, чем CL, потому что он статически решает фактически используемый бэкэнд ведения журнала. Кроме того, он имеет более богатый API, чем CL.
С другой стороны, логин является (un) официальным преемником LOG4J. Он реализует SLF4J изначально, поэтому нет никаких накладных расходов, вызванных какой-либо оболочкой.
Теперь вы можете понизить меня, если вы все еще считаете, что я этого заслуживаю.;)
SLF4J - новый ребенок. Я немного поработал с этим, и это довольно хорошо. Главным преимуществом является параметризованное ведение журнала, что означает, что вы это делаете:
logger.debug("The new entry is {}. It replaces {}.", entry, oldEntry);
Вместо этого:
logger.debug("The new entry is " + entry + ". It replaces " + oldEntry + ".");
И все это манипулирование строкой выполняется только в том случае, если оператор фактически зарегистрирован. Выглядит также чище.
Следует отметить, что SLF4J является оберткой, такой как commons-logging, хотя она утверждает, что она менее подвержена проблемам с загрузкой классов Commons-logging.
Мы используем java.util.logging. Также для крупных проектов. Есть несколько вещей, которые вы должны настроить (например, форматирование по умолчанию), но это не соответствует реальной точке. Я нахожу количество фреймворков протоколирования в Java и ползучести функции, которые они реализовали довольно раздражающе и несколько смущающе для сообщества Java. Уровень религиозных дебатов о регистрации является верным признаком того, что что-то пошло не так.
Что JUL дает вам, это простой, но достаточный API и одно место для настройки вывода журнала, который вы хотите увидеть (logging.properties или JMX...). И его всегда там и стабильно.
Весь код, который хочет регистрироваться, должен соответствовать стандартным соглашениям (уровень по умолчанию - INFO) и в противном случае делать больше, но использовать регистраторы значимого имени (например, имя пакета или класса), и все будет в порядке.
Если у вас нет веской причины использовать что-то вне JDK, я предпочитаю использовать то, что предоставляется Sun.
Многие из проектов, которые используют журнал Log4J, использовали его до того, как существовал "стандартный" протокол ведения журнала.
В средствах ведения журнала JDK всегда выполняются то, что мне нужно, чтобы они делали - никогда не было проблем с ним.
Для меня инструменты сторонней регистрации не являются ни необходимыми, ни желательными.
Мне не удалось выяснить, как контролировать уровень ведения журналов отдельных классов в структуре java.util.logging, что возможно в log4j. Если у меня возникли проблемы с диагностикой ошибки или существует класс высокого трафика, который регистрирует важную информацию, я могу изменить уровень для одного класса, чтобы регистрировать больше и оставлять остальные мои классы относительно спокойными.
N.B. Может быть, я не мог понять, как это сделать, или java.util.logging может измениться с тех пор, как я попытался.
java.util.logging хорош, но не имеет конфигурации, которая по умолчанию выбирается из пути к классам. Это скорее боль для нас, так как у нас много развертываний, которые не разделяют конфигурацию протоколирования, и это довольно беспорядочно для этого в j.u.l.
Log4j в настоящее время не развивается, поэтому, если есть необходимость в разработке бэкэнд-части, то в настоящий момент самый динамичный вариант, на мой взгляд.
(caveat: участие в некоторой неясной разработке slf4j и logback, но это связано с тем, что я не делаю вышеприведенных высказываний:))
Мы используем log4j с ведение журнала сообщества. Я думаю, мы просто используем их, потому что все это делают. Это и мы использовали log4j до того, как поддерживали jdk протоколирование.
Edit: Просто потому, что все остальные - это шутка, но, вероятно, почему я начал работать с log4j и ведением журнала commons.
Вот несколько причин для использования регистрации в сообществах.
Я думал, что буду использовать log4j - как упоминалось в @ScArcher2, только потому, что все это делают. Но после рассмотрения обоих вариантов я узнал, что java.util.logging достаточно достаточен для большинства моих потребностей - и я говорю об огромной системе с множеством компонентов, работающих вместе.
Итак, на мой взгляд, нет необходимости использовать альтернативные сервисы. Java.util.logging достаточно эффективен для большинства случаев.
Довольно легко написать класс j.u.l LogManager, который отложит все протоколирование к реализации, сделанной на заказ, которая использует Log4J. Это означает, что вы можете использовать log4j, но по-прежнему иметь приятную функцию, которую могут контролировать библиотеки, журналы с использованием j.u.l, если они использовали Log4J.
Используя оба (и commons-logging), я должен сказать, что то, что действительно, действительно, действительно меня раздражает, таково:
log4j.error("An Exception", e);
jul.severe("An Exception", e); // GRRR! no such method
jul.log(Level.SEVERE, "An Exception", e); //Must use this method
Почему они выбрали этот дизайн? Зачем? Другое дело, что нет PatternFormatter, который поставляется с j.u.l - вам нужно катиться самостоятельно.
Тем не менее, я заблуждаюсь, чтобы использовать j.u.l с этого момента, поскольку он сокращает внешние зависимости и не является более сложным в использовании.
В проектах, над которыми я работаю, мы, как правило, используем коммерческую регистрацию из Джакарты. Это не сама система регистрации, вместо этого она может обернуть некоторые из наиболее распространенных логгеров - log4j, java.util.logging или другие.
При этом относительно легко можно переключить ведение журнала на основе среды, в которую развертывается приложение (разработчик может захотеть использовать simplelog или java.util.logging на своей машине из-за простоты обслуживания, в то время как на SIT система log4j с общей конфигурацией для всех приложений может быть развернута и т.д.)
Все зависит от ваших требований к регистрации. Это не просто API, который разработчики приложений используют, на что вы смотрите, и, откровенно говоря, наименьшая проблема, связанная с API-интерфейсом ведения журнала, по большей части легко адаптируется независимо от того, какой выбор вы делаете.
Важной частью является то, какой конфигурации ведения журнала требуется для операций, и они должны сообщать вам, что им нужно.
Log4J в своем пакете varia имеет поддержку для этих и других и проверена их API. Теперь с помощью java.util.logging вы сможете загрузить их, но они не так распространены, как Log4J, и может быть сложнее найти информацию для.
Еще одна вещь, которую стоит рассмотреть - это API-интерфейс поставщика, который вы используете. Большинство поставщиков "навязывают" API регистрации для вас. Spring является одним из них, который требует комбонирования.
Как разработчик, я бы попытался использовать java.util.logging, если мог, для своих собственных вещей, но в реальных сценариях вам нужно встряхнуть то, что им нужно в операциях, и позволить этому выбрать ваш выбор, потому что они - те, кто должен использовать эти журналы, когда приложение выходит в эфир. Ни разработчик приложений, ни разработчики не должны делать этот выбор, хотя они должны делать предложения.
Одна вещь, которую никто не упоминал в этом потоке - java.util.logging не поддерживает syslog из коробки. Для меня это разрывает сделку (и заставил меня немного испугаться, чтобы реорганизовать материал java.util.logging вместо чего-то с немного большим количеством сока.
Вот что я сегодня встретил:
http://logging.apache.org/log4j/1.2/ - один и тот же, хотя он, кажется, немного стареет.
http://slf4j.org/ - пытается взять логовую коронку, похоже, имеет некоторое переключение/перенаправление поведение.. он может быть подходящим для замены, но я не мог найти никаких ясных примеров. Я должен потратить больше времени на это.
http://syslog4j.org/ - Это syslogs, но не имеет замены для замены (ничего похожего, не делайте java people не syslog много или что-то еще?)
http://people.apache.org/~psmith/logging.apache.org/sandbox/jul-log4j-bridge/apidocs/org/apache/logging/julbridge/JULLog4jBridge.html - jul-log4j-bridge рекламирует, что его падение на замену выглядело многообещающим и имело небольшой след.
Одна из проблем, с которыми я сталкиваюсь со всеми системами ведения журнала, заключается в том, что, если все члены вашей команды не тратят время, чтобы овладеть тем, как настроить его и контролировать, вы никогда не знаете, будет ли распечатываться задание отладки.
У вас может быть отключен уровень (отладка), или вы можете отключить один пакет.
Я потратил слишком много времени, полагая, что оператор отладки будет печатать, а это не так. Теперь я в основном полагаюсь на System.out.println() и просто просматриваю и удаляю или конвертирую их, когда я делаю отладку.
Я знаю, что это не отвечает на ваш вопрос - я просто говорю, что вы можете подумать о том, сколько у вас есть оправдания, прежде чем добавлять сложность.
Ведение журнала не так сложно и, безусловно, оправдано в большинстве крупных проектов.
Лично я использую Simple Logger, но на работе я использую нашу корпоративную упаковку для регистратора JDK. Я использую Simple Logger из-за простоты его настройки и того факта, что он поддерживает регистрацию 7 уровней между Fatal и Ludicrous.
Если вам нужно войти в ваше приложение, вы, вероятно, сделали что-то действительно не так. Я бы сказал, что сообщение о случайных проблемах в порядке, но наличие отладки, инструкции info etc во многих классах с логикой является неправильным. Любое большое приложение с протоколированием в большинстве своих заполненных логикой классов будет равносильно информационной перегрузке, даже если вы выбираете только правильные регистраторы. В большинстве случаев информация будет неполной, шумной или фактической информации, которая вам нужна, просто отсутствует.
Im в основном говорит, что вам нужно будет только писать операторы отладки, чтобы информировать пользователя о реакции программы на внешние факторы.