Java logging. Hello World

[@Throwable]

В последнем приведенном примере:
java.util.logging.Logger log4jLog = java.util.logging.Logger.getLogger(«log4jLog»);
->
org.apache.log4j.Logger log4jLog = org.apache.log4j.Logger.getLogger(«log4jLog»);
???

[@ehabarov]

Для SLF4J практически не раскрыта «вкусность» с подстановкой значений в сообщение (parameterized messages).
Плюсы:
— если оператор логгирования не срабатывает (выключен соотв. уровень), то не тратится время на обращение к объектам, значения которых должны быть подставлены в тело сообщения.
— текст сообщения всегда идет одной строкой.
Пример:

logger.debug("Value {} was inserted between {} and {}.", newVal, below, above);

Поправка по тексту статьи:

Если в classpath не будет найдена реализация логгера ( или заглушка nop) SLF4J гневно ругнется и работать откажется.

Начиная с версии 1.6, если не найдена ни одна реализация, то произойдет переключение на режим «no operation», но работать будет! Это написано в руководстве, второй абзац.

[@onakrainikoff]

Для SLF4J практически не раскрыта «вкусность»

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

Начиная с версии 1.6, если не найдена ни одна реализация, то произойдет переключение на режим «no operation», но работать будет! Это написано в руководстве, второй абзац.

Да совершенно верно, там написано: " If no binding is found on the class path, then SLF4J will default to a no-operation implementation", но мной имелось ввиду несколько другое, что в таком случае должна быть подключена slf4j-nop-1.*.*.jar, собственно реализация заглушки.

[@ehabarov]

В каждой реализации должны быть классы org.slf4j.impl.StaticLoggerBinder, org.slf4j.impl.StaticMarkerBinder, org.slf4j.impl.StaticMDCBinder.
Такая реализация есть и в архиве slf4j-nop-*.jar. Подключение этого архива означает «Сознательное» блокирование вывода SLF4J.

Однако, если не найдена ни одна реализация, то будут использованы классы org.slf4j.helpers.NOPLoggerFactory, org.slf4j.helpers.NOPLogger и org.slf4j.helpers.NOPMDCAdapter, которые находятся в архиве slf4j-api-*.jar.
Это дает основной программе возможность работать, не сваливаясь по ClassNotFoundException.

Еще одна выдержка из документации: Failed to load class org.slf4j.impl.StaticLoggerBinder

[@grossws]

Строго говоря, slf4j является в первую очередь api, а не оберткой. Logback — одна из реализаций этого api. Кроме неё есть всякие реализации типа nop, simple (просто в stderr), slf4j-log4j (выводит в log4j), slf4-jdk14 (в jul), slf4j-jcl (в commons-logging) и бриджи для перенаправления логов других систем логгирования в slf4j (jcl-over-slf4j, jul-to-slf4j, log4j-over-slf4j).

Если у вас часть библиотек использует, скажем, jul, часть — jcl/commons-logging, а часть log4j, то slf4j очень удобен для интеграции всего этого барахла и единообразного управления оным. Бриджи реализуют интерфейсы соответствующих библиотек логгирования и их пользователи не замечают никакой разницы. А дальше выбирается реализация бэкенда по вкусу (я обычно использую logback или log4j).

[@Regis]

Slf4j и Logback в одном списке? Это как сравнивать интерфейс и реализацию. Slf4j в вашем списке лишний.

Чего не хватает в статье:

1) Logback — идейный наследник Log4j. В некотором смысле это тот же Log4j, но переписанный с нуля. Одна из фич — большой акцент на производительности.

2) Для всех новых проектов настояетельно рекомендуется связка Slf4j + Logback. Все остальные варианты из вышеперечисленных являются в том или ином смысле устаревшими.

[@onakrainikoff]

Slf4j и Logback в одном списке?

Одной из целей статьи было показать пример работы с каждым из указанных фреймворков, как показать работу Logback без Slf4j?

Slf4j в вашем списке лишний

буду рад услышать аргументы

вышеперечисленных являются в том или ином смысле устаревшими

Не могу с вами согласиться, ибо не могу назвать устаревшим log4j2, да JUL в 8 версии расширил немного функционал

[@evkin]

Одной из целей статьи было показать пример работы с каждым из указанных фреймворков, как показать работу Logback без Slf4j?

Так же как и все остальные:-) Идем в мануал logback http://logback.qos.ch/manual/introduction.html и копируем первый пример))

package chapters.introduction;

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

public class HelloWorld1 {

  public static void main(String[] args) {

    Logger logger = LoggerFactory.getLogger("chapters.introduction.HelloWorld1");
    logger.debug("Hello world.");

  }
}

[@evkin]

Да, как говориться чукча писатель, а не читатель))) LogBack используется только в связке с оберткой SLF4J)))

[@Regis]

да JUL в 8 версии расширил немного функционал

Не буду ручаться за JUL в Java 8, но на время Java 7 он все еще заметно уступал Slf4j+Logback. Например предлагаю посмотреть вот этот вопрос на SO по поводу JUL.

[@Regis]

как показать работу Logback без Slf4j?

Очевидно: никак. Претензия-то не к тому, что вы в секции про Logback упоминаете Slf4j, а к тому, что вы в один список положили как имплементации так и API.

[@Dementor]

О том, что существует пачка библиотек для логирования можно узнать и при обычном гуглении. Я просмотрел всю статью в поиске ответа — зачем их столько наплодили и почему нельзя все время пользоваться стандартной Java.util.logging без всяких заморочек? Ответ нашел только в Вашем комментарии — дело в быстродействии.

2) Для всех новых проектов настояетельно рекомендуется связка Slf4j + Logback. Все остальные варианты из вышеперечисленных являются в том или ином смысле устаревшими.

Только вопрос: Кем рекомендуется?

[@Regis]

почему нельзя все время пользоваться стандартной Java.util.logging без всяких заморочек

Вот этот вопрос на SO с довольно подробным ответом в дополнениях к вопросу.