Ви хочете подивитися на рамку реєстрації та, можливо, на рамку фасаду журналу.
Існує декілька фреймів для ведення журналів, часто з функціями, що перекриваються, настільки, що з часом багато хто розвинувся, щоб покластися на спільний API, або стали використовувати через фасадну рамку, щоб абстрагувати їх використання і дозволити їх замінювати на місці при необхідності.
Каркаси
Деякі рамки ведення журналу
Деякі фасади лісозаготівлі
Використання
Основний приклад
Більшість із цих фреймворків дозволить вам написати щось із форми (тут, використовуючи slf4j-apiта logback-core):
package chapters.introduction;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
// copied from: http://www.slf4j.org/manual.html
public class HelloWorld {
public static void main(String[] args) {
final Logger logger = LoggerFactory.getLogger(HelloWorld.class);
logger.debug("Hello world, I'm a DEBUG level message");
logger.info("Hello world, I'm an INFO level message");
logger.warn("Hello world, I'm a WARNING level message");
logger.error("Hello world, I'm an ERROR level message");
}
}
Зверніть увагу на використання поточного класу для створення виділеного реєстратора, який дозволить SLF4J / LogBack форматувати вихід і вказати, звідки походить повідомлення журналу.
Як зазначається в посібнику SLF4J , типова схема використання в класі зазвичай:
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
public class MyClass {
final Logger logger = LoggerFactory.getLogger(MyCLASS.class);
public void doSomething() {
// some code here
logger.debug("this is useful");
if (isSomeConditionTrue()) {
logger.info("I entered by conditional block!");
}
}
}
Але насправді декларувати реєстратор із формою ще частіше:
private static final Logger LOGGER = LoggerFactory.getLogger(MyClass.class);
Це дозволяє використовувати реєстратор і в статичних методах, і він розподіляється між усіма примірниками класу. Це, швидше за все, є вашою бажаною формою. Однак, як зазначив Брендан Лонг у коментарях, ви хочете бути впевненими, що розумієте наслідки та приймаєте відповідне рішення (це стосується всіх фреймворків журналу, що слідують за цими ідіомами).
Є й інші способи інстанціювання реєстраторів, наприклад, за допомогою рядкового параметра для створення названого реєстратора:
Logger logger = LoggerFactory.getLogger("MyModuleName");
Рівні налагодження
Рівень налагодження варіюється в залежності від однієї рамки до іншої, але загальні - це (в порядку критичності, від доброякісного до поганого, і, напевно, дуже поширеного до сподіваюсь, дуже рідкого):
TRACE Дуже детальна інформація. Потрібно писати лише в журнали. Використовується лише для відстеження потоку програми на контрольних пунктах.
DEBUG Детальна інформація. Потрібно писати лише в журнали.
INFO Визначні події виконання. Повинно бути видно на консолі, тому використовуйте економно.
WARNING Диваки виконання та помилки, що підлягають відновленню.
ERROR Інші помилки виконання або несподівані умови.
FATAL Сильні помилки, що спричиняють передчасне припинення.
Блоки та гвардії
Скажімо, у вас є розділ коду, де ви збираєтесь написати ряд заяв про налагодження. Це може швидко вплинути на вашу ефективність, як через вплив самого ведення журналу, так і на генерування будь-яких параметрів, які ви могли б перейти до методу ведення журналу.
Щоб уникнути подібного роду питань, вам часто хочеться написати щось із такої форми:
if (LOGGER.isDebugEnabled()) {
// lots of debug logging here, or even code that
// is only used in a debugging context.
LOGGER.debug(" result: " + heavyComputation());
}
Якщо ви раніше не використовували цей захист перед блоком операторів налагодження, навіть якщо повідомлення можуть не виводитися (якщо, наприклад, ваш реєстратор наразі налаштований для друку лише речей, що перевищують INFOрівень), heavyComputation()метод все одно буде виконаний .
Конфігурація
Конфігурація дуже залежить від вашої системи реєстрації журналів, але вони пропонують здебільшого ті самі методи для цього:
- програмна конфігурація (під час виконання, через API - дозволяє змінювати час виконання ),
- статична декларативна конфігурація (під час запуску, як правило, через XML або файл властивостей - це, можливо, спочатку потрібно ).
Вони також пропонують в основному ті ж можливості:
- конфігурація формату вихідного повідомлення (часові позначки, маркери тощо),
- конфігурація вихідних рівнів,
- конфігурація дрібнозернистих фільтрів (наприклад, для включення / виключення пакетів або класів),
- конфігурація додатків для визначення місця входу (консолі, подачі файлів, веб-сервісу ...) і, можливо, що робити зі старими журналами (наприклад, з файлами автоматичної прокатки).
Ось загальний приклад декларативної конфігурації з використанням logback.xmlфайлу.
<configuration>
<appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
<!-- encoders are assigned the type
ch.qos.logback.classic.encoder.PatternLayoutEncoder by default -->
<encoder>
<pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern>
</encoder>
</appender>
<root level="debug">
<appender-ref ref="STDOUT" />
</root>
</configuration>
Як згадувалося, це залежить від вашої основи, і можуть бути інші альтернативи (наприклад, LogBack також дозволяє використовувати сценарій Groovy). Формат конфігурації XML також може відрізнятися від однієї реалізації до іншої.
Щоб отримати додаткові приклади конфігурації, зверніться (серед інших) до:
Деякі історичні забави
Будь ласка , зверніть увагу , що Log4J бачить серйозне оновлення в даний момент, перехід від версії 1.x до 2.x . Можливо, ви хочете ознайомитись як з більшою історичною забавою, так і з заплутаністю, і якщо ви вибрали Log4J, напевно, віддаєте перевагу версії 2.x.
Варто зазначити, як Майк Партрідж згадував у коментарях, що LogBack був створений колишнім членом команди Log4J. Що було створено для усунення недоліків рамки Java Logging. І що майбутня основна версія Log4J 2.x сама є інтеграцією кількох функцій, взятих з LogBack.
Рекомендація
Підсумок, будьте відокремлені, скільки зможете, пограйте з кількома, і подивіться, що для вас найкраще. Врешті-решт, це просто рамка ведення журналу . За винятком випадків, коли у вас є дуже конкретна причина, крім простоти користування та особистих уподобань, будь-яка з них зробить досить гаразд, тому немає сенсу навішувати її. Більшість з них також можна розширити на ваші потреби.
Все-таки, якби мені сьогодні довелося вибрати комбінацію, я б пішов з LogBack + SLF4J. Але якщо ви запитали мене через кілька років, я б порекомендував Log4J за допомогою журналу Apache Commons, тому слідкуйте за своїми залежностями та розвивайтесь з ними.