Чи повинні нові проекти використовувати logback замість log4j? [зачинено]

Чи повинні нові проекти використовувати logback замість log4j як структуру ведення журналу?

Або іншими словами: "Чи кращий журнал, ніж log4j (залишаючи поруч SLF4J-'особливість 'ретробеку)?'

Для реєстрації слід використовувати SLF4J + Logback.

Він надає чудові функції, такі як параметризовані повідомлення та (на відміну від загальних журналів) відображений діагностичний контекст (MDC, javadoc , документація ).

Використання SLF4J робить протокол реєстрації доступним для обміну досить елегантно.

Крім того, SLF4J підтримує мостування інших фреймворків ведення журналу до фактичної реалізації SLF4J, яку ви будете використовувати, щоб події реєстрації від сторонніх програм відображатимуться у ваших уніфікованих журналах - за винятком java.util.logging, який неможливо перетворити на так само, як і інші фреймворки журналювання.

Перехідний липень пояснюється в javadocs з SLF4JBridgeHandler.

Я мав дуже хороший досвід використання комбінації SLF4J + Logback у кількох проектах, і розробка LOG4J майже затрималася.

SLF4J має наступні недоліки:

• Він не підтримує varargs, щоб залишатися сумісними з Java <1.5
• Він не підтримує використання параметризованих повідомлень і винятків одночасно.
• Він не містить підтримки вкладеного діагностичного контексту (NDC, javadoc ), який має LOG4J.

Автор (як Logback, так і Log4j) має перелік причин для зміни на http://logback.qos.ch/reasonsToSwitch.html .

Ось кілька, що стирчали в мене;

• Швидше впровадження

  На підставі нашої попередньої роботи над log4j, внутрішні дані журналу перепису були переписані, щоб виконувати приблизно в десять разів швидше на певних критичних шляхах виконання. Компоненти реєстрації не тільки швидші, вони також мають менший розмір пам'яті.

• Автоматичне перезавантаження файлів конфігурації

  Logback-classic може автоматично перезавантажувати свій файл конфігурації після модифікації. Процес сканування є швидким і безпечним, оскільки не передбачає створення окремого потоку для сканування. Ця технічна тонкощі гарантує, що ретробек відтворюється добре на серверах додатків і, загалом, у середовищі JEE.

• Стек стеків з даними упаковки

  Коли журнал друкує виняток, трасування стека включатиме дані упаковки. Ось зразок трасування стека, згенерований веб-додатком logback-demo.

  14: 28: 48.835 [btpool0-7] ІНФОРМАЦІЯ cqldemo.prime.PrimeAction - 99 не є дійсним значенням java.lang.Exception: 99 недійсне
  у ch.qos.logback.demo.prime.PrimeAction.execute (PrimeAction.java : 28) [класи /: na] на org.apache.struts.action.RequestProcessor.processActionPerform (RequestProcessor.java:431) [struts-1.2.9.jar: 1.2.9] на org.apache.struts.action. RequestProcessor.process (RequestProcessor.java:236) [struts-1.2.9.jar: 1.2.9] на org.apache.struts.action.ActionServlet.doPost (ActionServlet.java:432) [struts-1.2.9.jar : 1.2.9] на javax.servlet.http.HttpServlet.service (HttpServlet.java:820) [servlet-api-2.5-6.1.12.jar: 6.1.12]
  на org.mortbay.jetty.servlet.ServletHolder.handle (ServletHolder.java:502) [jetty-6.1.12.jar: 6.1.12] на ch.qos.logback.demo.UserServletFilter.doFilter (UserServletFilter.java:44 ) [класи /: na] на org.mortbay.jetty.servlet.ServletHandler $ CachedChain.doFilter (ServletHandler.java:1115) [jetty-6.1.12.jar: 6.1.12] на org.mortbay.jetty.servlet. ServletHandler.handle (ServletHandler.java:361) [jetty-6.1.12.jar: 6.1.12] на org.mortbay.jetty.webapp.WebAppContext.handle (WebAppContext.java:417) [jetty-6.1.12.jar : 6.1.12] на org.mortbay.jetty.handler.ContextHandlerCollection.handle (ContextHandlerCollection.java:230) [jetty-6.1.12.jar: 6.1.12]

  З вищесказаного ви можете зрозуміти, що програма використовує Struts версії 1.2.9 і була розгорнута під версією версії 6.1.12. Таким чином, сліди стеків швидко повідомлятимуть читача про класи, що входять у виняток, а також про версії пакета та пакунку, до яких вони належать. Коли ваші клієнти надсилають вам стек стека, як розробнику вам більше не потрібно буде просити їх надсилати вам інформацію про версії пакетів, які вони використовують. Інформація буде частиною трасування стека. Докладніше див. У слові перетворення "% xThrowable".

  Ця функція може бути дуже корисною до того, що деякі користувачі помилково вважають її особливістю своєї IDE.

• Автоматичне видалення старих архівів журналів

  Встановивши властивість maxHistory для TimeBasedRollingPolicy або SizeAndTimeBasedFNATP, ви можете контролювати максимальну кількість заархівованих файлів. Якщо ваша політика прокатки вимагає щомісячного переходу, і ви хочете зберегти журнали на один рік, просто встановіть для властивості maxHistory значення 12. Архівовані файли журналів, старші за 12 місяців, будуть автоматично видалені.

Там може бути упередження, але той самий хлопець написав обидва фреймворки, і якщо він каже, використовуйте Logback через Log4j, мабуть, варто послухати.

Я б використовував slf4j для реєстрації у всіх випадках. Це дозволяє вам вибрати, який фактичний серверний журнал ви хочете використовувати під час розгортання замість часу коду.

Для мене це виявилося дуже цінним. Це дозволяє мені використовувати log4j у старих JVM, та logback у 1.5+ JVM, а також java.util.logging за потреби.

Повторний звіт про Java EE:
загалом (від коду до документації) пам’ятайте про контейнери - як співіснують декілька програм, як реалізовані завантажувачі класів тощо.

від потенційного розробника майже однаково, Logback додає параметризоване ведення журналу (не потрібно використовувати if (logger.isDebugEnabled ()), щоб уникнути накладних витрат на конкатенацію рядків)

Log4j - єдиний гігантський плюс - це стара підтримка JVM, невеликий (IMO) NDC (MDC), деякі розширення. Наприклад, я написав розширення для configureAndWatch для Log4j, такого для Logback немає

оригінал log4j та logback були розроблені та реалізовані тим самим хлопцем.

кілька інструментів з відкритим кодом використовували SLF4J. Я не бачу суттєвих недоліків у цьому інструменті. Отже, якщо у вас немає багато розширень для log4j у вашій кодовій базі, я хотів би продовжити з реєстрацією.

Я вважаю, що ваше рішення повинно звестись до того самого, яке було б, якби ви вирішили між використанням log4j або Джакарта Commons Logging - ви розробляєте бібліотеку, яка буде включена в інші програми? Якщо так, то здається нечесним змушувати користувачів вашої бібліотеки також використовувати вибрану вами бібліотеку журналів.

Якщо відповідь негативна, я б просто погодився з тим, що простіше додати, і чим вам комфортніше. Здається, що зворотний зв’язок настільки ж розтяжний і надійний, як і log4j, тому, якщо вам зручно його використовувати, продовжуйте.

Я не знайомий із SLF4J, і я лише коротко оглянув журнал, але мені спадають на думку дві речі.

По-перше, чому ви виключаєте інструмент з експертизи? Я думаю, що важливо зберігати відкритість і вивчити всі можливості, щоб вибрати найкращу.

По-друге, я думаю, що в деяких проектах один інструмент є кращим, ніж інший, і навпаки, це може бути правдою в іншому проекті. Я не думаю, що один інструмент завжди кращий за інший. Зрештою, немає срібної кулі .

Відповісти на ваше запитання - так і ні. Це залежить від проекту та наскільки команда знайома з одним інструментом. Я б не сказав "не використовуй log4j", якщо вся команда дуже комфортно з ним працює, він відповідає всім потребам, а logback не пропонує нічого, що нам потрібно для виконання завдання.