Заброшено ли Log4j в пользу Slf4j?

Кажется, что log4j имеет некоторые class loading issues (среди прочих), и мне кажется, что тенденция состоит в том, чтобы выйти из log4j в сторону slf4j. (Hibernate прекратил использовать первый в пользу последнего)Заброшено ли Log4j в пользу Slf4j?

Это правда?
Каковы основные проблемы в log4j, которые разрешает slf4j?
Является ли slf4j последним словом или есть даже лучший «следующий следующий log4j» отраслевой стандарт?

Update:

Так это answer по delfuego меня смущает, вы можете принять/приемлю его ?:

Вы, кажется, что наткнулся на серьезную проблему с log4j (и Apache Commons Logging), , а именно, что у них смешно трудное время обнаружения и взаимодействия с правильными загрузчиками классов, так как они используются . Существует очень плотное описание , в комплекте с примерами, здесь; сообщение об увольнении состоит в том, что является одной из основных движущих сил для . Новая система регистрации SLF4J была равна , полностью устраняя эти проблемы. Возможно, вы захотите поменять его и посмотреть, есть ли у вас ваша жизнь.

Другие вопросы по log4j загрузки классов: http://articles.qos.ch/classloader.html

источник

2010-01-14 ruchirhhi

В статье, ссылающейся на http://articles.qos.ch/classloader.html, нет проблем с загрузкой классов с помощью log4j, а с помощью Jakarta Commons Logging (другой фасад ведения журнала). Это то, что SLF4J заменяет и связывает код фактической базовой системы ведения журнала (включая, возможно, log4j), чтобы устранить проблемы загрузки классов. –

Возможный дубликат [Если новые проекты используют logback вместо log4j?] (Http://stackoverflow.com/questions/178836/should-new-projects-use-logback-instead-of-log4j) – ripper234

Slf4j - это действительно просто каротажный фасад. Тем не менее, Log4j должен быть преуспел Logback, от тех же авторов.

Update: если вы хотите знать о другом пользу SLF4J, это тот факт, что следующее (уродливые) конструкции не нужны, чтобы избежать toString() ненужно был вызван:

if (logger.isDebugEnabled()) { 
    logger.debug("Message: " + bigObject + ", " + anotherBigObject); 
}

вместо этого вы можете использовать параметризованные сообщения:

logger.debug("Message: {}, {}", bigObject, anotherBigObject);

Также см What is the fastest way of (not) logging?

источник

2010-01-14 12:16:20 BalusC

+1: У меня был очень похожий вопрос только несколько дней назад, и я начал использовать Logback, который использует slf4j в фоновом режиме. – lostiniceland

?! varargs не останавливает выполнение функций ... не так ли? –

Нет, но это останавливает выполнение toString, которое происходит при объединении объекта с строкой. Основная проблема с дорогостоящим протоколированием - это не вызов функции журнала, это построение строки в журнале! –

Глядя на slf4j page это не выглядит, как он будет заменить log4j - это просто позволит вам использовать те же основные рамки протоколирования (например, log4j) для всего вашего приложения, позволяя библиотекам автоматически подключаться к ним.

Это больше похоже на замену Apache Commons Logging, чем log4j.

источник

2010-01-14 12:07:13

SLF4J имеет, на мой взгляд, огромное преимущество в том, что вы можете унифицировать ведение журнала всех библиотек, которые вы используете через мосты, которые он предоставляет. Это не позволяет ни одна из других фреймворков регистрации. Это позволяет проектам плавно переходить на SLF4J и игнорировать выбор рамки ведения журналов, которые были сделаны зависимостями.

источник

2010-01-14 12:08:10

slf4j не является регистрацией фреймворк. Это фасад одной из нескольких фреймворков регистрации. –

Slf4J не является альтернативой для Log4j, но предоставляет фасад для ведения журнала, поэтому вы можете подключить свою собственную систему ведения журнала. Это в основном полезно для библиотек. из slf4j.org:

Простой Logging Facade для Java или (SLF4J) служит простой фасад или абстракции для различных структур регистрации , например java.util.logging, log4j и logback, что позволяет пользователю подключить нужный журнал рамки во время развертывания.

Чтобы ответить на ваш вопрос: SLF4J в настоящее время принят рамки сейчас, но в ваших проектах, вы можете продолжать использовать Log4J (или любой другой)

источник

2010-01-14 12:08:26 EJB

Итак, этот ответ запутан: http: // stackoverflow.com/questions/1974705/log4j-and-the-thread-context-classloader/1974775 # 1974775 подразумевает, что slfJ решает проблемы, созданные Log4j в конце концов ... может быть, что помимо функции Facade, он также имеет хорошую автономность личная реализация каротажа лучше, чем log4j? – ruchirhhi

SLF4J требует реальной реализации каротажа под ним. Это может быть Log4j, или вы можете использовать Logback, который изначально реализует интерфейсы SLF4J (SLF4J и Logback написаны теми же людьми). – SteveD

Это просто фасад. Однако существует новая реализация под названием Logback, предназначенная для реализации SLF4J первого класса. Стоит отметить, что SLF4J, Log4J и Logback были созданы тем же парнем, который в основном видит Log4J как застопорившийся. У него есть учетная запись в StackOverflow (имя пользователя - Ceki) и имеет тенденцию повторять это в большинстве потоков Log4J/SLF4J. – GaryF

Во-первых: важный момент: SLF4J является протоколирование интерфейс (API), который может использоваться ниже большинства основных систем Loggin: например, log4j или java.util.logging. Поэтому лучше сравнить sfl4j с commons-logging.

О состоянии Log4j, цитаты из The state of java logging (один год назад)

Одна вещь, которую я не понял, что развитие log4j в основном мертв. В настоящее время он находится на версии 1.2, и планы на версию 1.3 были отменены в пользу разработки log4j 2.0. Однако, похоже, 2.0 не находится в активной разработке. Стоит отметить, что Ceki Gülcü, оригинальный основатель проекта log4j, перешел на slf4j (см. Ниже).

источник

2010-01-14 12:09:24 Kartoch

Slf4j не является реальным фасадом. Slf4j не поддерживает многие функции своих разработчиков. Для краткости я упоминаю примеры log4j, приведенные ниже.

SLF4J не может указать выбранный пользователем файл конфигурации, но силы пользователю использовать по умолчанию (log4j.properties или log4j.xml) в одном из многих Java корней (каждый Jar имеет один корень плюс JVM корень и классы или корзины). Если у двух файлов JAR есть это, трудно контролировать, какой из них использовать безопасно.
Slf4j не может поддерживать все уровни Log4j, такие как «фатальный». При переключении большого кода с Log4j на Slf4j требуется огромное усилие изменения кода (например, решение о переупорядочении уровней).
Должны быть выбраны два ключевых файла Jar (log4j-over-slf4j.jar или slf4j-log4j12.jar). Если classpath и то, и другое не будет работать. Если выбрать один случайный случай, потеряйте неожиданные функции (например, log4j-over-slf4j.jar не поддерживает несколько файлов журналов для одних и тех же классов, например, один для журнала событий и один для журнала необработанных данных).

источник

2012-07-08 16:20:05

ответ

Смежные вопросы