Регистрация в веб-приложениях: лучшие практики?

Question

Во время развертывания веб-приложения (в тестовой среде) на клиентском сайте возникла проблема с протоколированием приложения. Я в скором времени постараюсь описать текущую ситуацию:

• Реализация использует Logger найденную по java.util.logging и apache.commons.logging.
• В развернутых пакетах есть Commons -logging.properties, указывающие на JUL.
• Приложение работает на Tomcat 6.x

Клиент решил, что он хочет использовать Log4J на кот и настроен, так что он работает (вообще) - конечно, это не работает для указанного приложения.

Похоже, что нам нужно изменить реализацию протоколирования в любом случае - я хотел попросить вас о некоторых передовых методах внедрения ведения журнала в веб-приложении. следующие вещи должны быть возможно:

• Клиент должен быть в состоянии изменить лог-уровня, не изменяя ничего в * .war-файл. -> Если ему придется изменить военный файл, он должен будет сделать это для каждой новой сборки ...
• Должно быть возможно иметь какой-то файл каротажных файлов (например: максимум 10 файлов с макс. 10 МБ каждый) - конечно же, это также зависит от клиента, чтобы определить и изменить этот параметр ...
• Как другой клиент может захотеть использовать стандартную JUL-регистрацию вместо этого - я бы, конечно, код предпочтительной библиотеки (Log4J в этом случае).

Answer 1

Клиент должен иметь возможность изменять уровень журнала, не изменяя ничего в * .war-файле.

Вы можете поместить конфигурационный файл базы протоколирования (log4j.xml или logback.xml) вне файла WAR. Также logback поддерживает автоматическую реконфигурацию при изменении этого файла.

Должна быть обеспечена возможность иметь некоторый вид подвижного файла каротажа

Оба log4j и поддержка Logback откате файлов, как в зависимости от размера и даты, смотри, например, RollingFileAppender.

Как другой пользователь может захотеть использовать стандартное JUL-протоколирование вместо этого - я бы предпочел не жестко кодировать предпочтительную библиотеку (в этом случае Log4J).

apache-commons-logging является fundamentally broken, используйте slf4j вместо этого.Затем вы просто добавляете различные реализации в свой CLASSPTH. Также API SLF4J довольно приятен.

Answer 2

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

Хотя я еще не пробовал, у них даже есть migrator tool, которые должны помочь изменить код, чтобы использовать его.