Вы находите java.util.logging достаточным?


Answers

java.util.logging (jul) был ненужным с самого начала. Просто проигнорируйте это.

jul сам по себе имеет следующие недостатки:

  • В то время, когда jul был внедрен в Java 1.4, в широком использовании уже существует хорошо зарекомендовавшая себя система ведения журнала: LOG4J
  • предопределенные уровни журнала: SEVERE, WARNING, INFO, CONFIG, FINE, FINER, FINEST. Я не буду говорить вам, что я лично думаю об этих предопределенных уровнях, чтобы этот ответ был полуинтересным.
  • Можно определить дополнительные уровни. jul поддерживает до 4G разных уровней бревен, которые немного перегружены, ИМХО. Меньше иногда бывает больше.
  • Самый важный момент: если вы решитесь определить свой собственный уровень журнала, вы, вероятно, столкнетесь с проблемой утечки памяти!
    Здесь вы можете прочитать об этом эффекте:

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

  • он находится в пространстве имен java. *, поэтому реализация не может быть обменена во время выполнения. Это эффективно предотвращает переключение на SLF4J так же, как это возможно в случае commons.logging и LOG4J. То, как происходит перемычка для jul, влияет на производительность. Это делает jul самой негибкой структурой каротажа.
  • Внедряя jul, Sun неявно определила его как «стандартную структуру ведения журналов Java». Это привело к распространенному заблуждению, что «хороший гражданин Java» должен использовать jul в своих библиотеках или приложениях.
    Противоположный случай.
    Если вы используете либо commons.logging, либо LOG4j, вы сможете обменять фактически используемую структуру ведения журнала, если вам когда-либо понадобится, путем соединения с SLF4J. Это означает, что библиотеки, использующие commons.logging, LOG4J или SLF4J, могут регистрироваться в одной и той же цели ведения журнала, например, в файле.

Я лично предложил бы использовать комманду SLF4J + Logback для всех целей ведения журнала. Оба проекта координируются Ceki Gülcü, парнем позади LOG4J.
SLF4J является достойным (но неофициальным, поскольку он не из той же группы), преемником commons.logging. Это менее проблематично, чем CL, потому что он статически решает фактически используемый бэкэндинг ведения журнала. Кроме того, он имеет более богатый API, чем CL.
С другой стороны, логин является (un) официальным преемником LOG4J. Он реализует SLF4J изначально, поэтому нет никаких накладных расходов, вызванных какой-либо оберткой.

Теперь вы можете понизить меня, если вы все еще думаете, что я этого заслуживаю. ;)

Question

По названию вы находите стандартную структуру ведения журналов Java, достаточную для ваших нужд?

Используете ли вы альтернативные услуги регистрации, такие как log4j или другие? Если да, то почему? Я хотел бы услышать любой совет, который у вас есть относительно требований к регистрации в проектах разных типов, и когда интеграция фреймворков действительно необходима и / или полезна.




java.util.logging хорош, но не имеет конфигурации, которая по умолчанию выбирается из пути к классам. Для нас это скорее боль, потому что у нас много развертываний, которые не разделяют конфигурацию протоколирования, и это довольно беспорядочно для этого в jul

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

(caveat: участие в некоторой неясной разработке slf4j и logback, но это связано и не вызывает высказываний, которые я делаю выше :))




Одна вещь, которую никто не упоминал в этой теме - java.util.logging не поддерживает syslog из коробки. Для меня это разрывает сделку (и заставил меня немного испугаться, чтобы реорганизовать материал java.util.logging вместо чего-то с немного большим количеством сока.

Вот что я сегодня встретил:

  • http://logging.apache.org/log4j/1.2/ - один и тот же, хотя, похоже, он немного стареет.

  • http://slf4j.org/ - Я пытаюсь взять корону log4j, похоже, имеет какое-то поведение моста / перенаправления. Возможно, он подходит для замены, но я не мог найти никаких ясных примеров. Я должен потратить больше времени на это.

  • http://syslog4j.org/ - Это syslogs, но у меня не было замены на замену (ничего похожего, не делайте java-ребята, а не syslog много или что-то еще?)

  • http://people.apache.org/~psmith/logging.apache.org/sandbox/jul-log4j-bridge/apidocs/org/apache/logging/julbridge/JULLog4jBridge.html - jul-log4j-bridge рекламирует, что его падение замены, выглядело многообещающим и имело небольшой след.




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

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




Мы используем java.util.logging. Также для крупных проектов. Есть несколько вещей, которые вы должны настроить (например, форматирование по умолчанию), но это не соответствует действительности. Я нахожу количество фреймворков протоколирования в Java и ползучести функции, которые они реализовали довольно раздражающе и несколько смущающе для сообщества Java. Уровень религиозных дебатов о регистрации является верным признаком того, что что-то пошло не так.

То, что JUL дает вам, представляет собой простой, но достаточный API и одно место для настройки того, какой вывод журнала вы хотите видеть (logging.properties или JMX ...). И его всегда там и стабильно.

Весь код, который хочет регистрироваться, должен соответствовать стандартным соглашениям (уровень по умолчанию - INFO), а в противном случае - не больше, но используйте регистраторы значимого имени (например, имя пакета или класса), и все будет в порядке.




Лично я использую Simple Logger , но на работе я использую нашу корпоративную упаковку для регистратора JDK. Я использую Simple Logger из-за простоты его настройки и того факта, что он поддерживает протоколирование 7 уровней между Fatal и Ludicrous.




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

Редактировать: Просто потому, что все остальные делали это шутка, но, вероятно, почему я начал работу с log4j и commons logging.

Вот несколько причин для использования регистрации в сообществах.




Службы регистрации JDK всегда делали то, что мне нужно, - никогда не было проблем с этим.

Для меня инструменты сторонней регистрации не являются ни необходимыми, ни желательными.