Совместное использование одного jar-файла log4j в Tomcat5 между несколькими веб-приложениями с отдельными файлами свойств

Question

Можно ли использовать один файл jar log4j в настройке tomcat 5.5, где он может использоваться несколькими веб-приложениями и иметь отдельную регистрацию для каждого веб-приложения?

У меня есть около 8 различных веб-приложений, написанных там, гдеединственное реальное различие между файлами свойств log4j - это имя файла журнала.Однако, если я попытаюсь переместить log4j из каталога WEB-INF / lib webapp в каталог shared / lib tomcat5, у меня возникнут проблемы.

Все файлы свойств в основном выглядят так же, как показано ниже, где я простоустановите file.name, используя System.setProperty ("file.name",) в коде.Не обязательно на самом деле, но я думал об использовании единого файла свойств для всех компонентов.

log4j.rootLogger=DEBUG, LogFile
# stdout
log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.stdout.layout.ConversionPattern=%d [%t] %-5p %c - %m%n

# LogFile
log4j.appender.LogFile=org.apache.log4j.RollingFileAppender
log4j.appender.LogFile.File=${file.name}
log4j.appender.LogFile.layout=org.apache.log4j.PatternLayout
log4j.appender.LogFile.MaxFileSize=500KB
log4j.appender.LogFile.MaxBackupIndex=5
log4j.appender.LogFile.layout.ConversionPattern=%d [%t] %-5p %c - %m%n

В основном для каждого из компонентов я хотел бы войти в отдельный файл, однако проблемав том, что если я включу log4j в каталог shared / lib, какой бы веб-приложение не было доступно первым, он фактически определяет файл журнала, который будет использоваться всеми веб-приложениями.т.е. я не могу использовать отдельную конфигурацию.

Альтернативы, о которых я знаю: поместите log4j в каталог WEB-INF / lib каждого из файлов war, таким образом я получу отдельнуюКонфигурация для каждого веб-приложения.

Измените приведенную выше ссылку "LogFile", чтобы она была специфичной для каждого веб-приложения, так чтобы фактически каждый файл свойств определял отдельную конфигурацию.Это позволяет избежать следующей ошибки: « log4j: ОШИБКА A» org.apache.log4j.RollingFileAppender "объект не может быть назначен переменной" org.apache.log4j.Appender ". "

т.е. используйте что-то вроде следующего:

Для WebApp1

log4j.rootLogger=DEBUG, LogFileWebapp1
# stdout
log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.stdout.layout.ConversionPattern=%d [%t] %-5p %c - %m%n

# LogFile
log4j.appender.LogFileWebapp1=org.apache.log4j.RollingFileAppender
log4j.appender.LogFileWebapp1.File=${file.name}
log4j.appender.LogFileWebapp1.layout=org.apache.log4j.PatternLayout
log4j.appender.LogFileWebapp1.MaxFileSize=500KB
log4j.appender.LogFileWebapp1.MaxBackupIndex=5
log4j.appender.LogFileWebapp1.layout.ConversionPattern=%d [%t] %-5p %c - %m%n

Для WebApp2

log4j.rootLogger=DEBUG, LogFileWebapp2
# stdout
log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.stdout.layout.ConversionPattern=%d [%t] %-5p %c - %m%n

# LogFile
log4j.appender.LogFileWebapp2=org.apache.log4j.RollingFileAppender
log4j.appender.LogFileWebapp2.File=${file.name}
log4j.appender.LogFileWebapp2.layout=org.apache.log4j.PatternLayout
log4j.appender.LogFileWebapp2.MaxFileSize=500KB
log4j.appender.LogFileWebapp2.MaxBackupIndex=5
log4j.appender.LogFileWebapp2.layout.ConversionPattern=%d [%t] %-5p %c - %m%n

Я бы предпочел придерживаться макета первого файла свойстви сохраняйте его как можно более похожим между веб-приложениями, а также не стоит включать отдельную копию log4j в каждое из веб-приложений.В идеале я надеялся просто использовать символическую ссылку из общего каталога lib tomcat на системную копию log4j.

Есть ли другие варианты?

Answer 1

Я бы этого не делал.Пусть каждое веб-приложение имеет свой собственный log4j.jar и собственный файл log4j.properties.Даже если это работает во всех остальных отношениях, вы никогда не сможете обновить log4j только в одном веб-приложении, и вам будет трудно изменить протоколирование для одного приложения, не затрагивая другие.

Сверх того и вышеболь и страдания из-за обслуживания, существует вероятность утечки памяти, если log4j удерживает ссылки на классы.Каждый раз, когда вы повторно развертываете Tomcat создает новый загрузчик классов приложений с новыми версиями всех классов, без возможности избавиться от старых ссылок, потому что log4j не знает, чтобы отпустить их, единственный способ восстановить память - это перезагрузитьэкземпляр Tomcat.

Вот интересная статья об использовании ведения журнала на уровне контейнера. В ней описывается проблема, с которой вы сталкиваетесь:

При развертывании log4j в пути lib контейнерадля контейнера, который не «log4j-осознает» и вы не настроили «контекстный селектор репозитория» для log4j, вы теряете главную особенность - конфигурация регистрации становится полностью глобальной для всех компонентов в контейнере.Только один файл конфигурации ведения журнала считывается (из пути к классу контейнера), и каждый компонент в контейнере видит одну и ту же конфигурацию ведения журнала.Это просто не сравнимо с ведением журнала.В большинстве случаев это неприемлемое поведение;однако регистрация общего пользования может обеспечить возможность вести себя таким образом, если кто-то действительно считает, что это полезно.

Когда вы развертываете log4j в пути lib контейнера и используете поведение «Селектор репозитория контекста» для получения каждого компонентаконфигурация журналирования И log4j также находится в пути компонента, где вы получаете исключения приведения классов (в настоящее время при регистрации в общем доступе возникает та же проблема).Это действительно отдельная проблема.

Когда вы развернете log4j в пути lib контейнера и используете поведение «Context Repository Selector», чтобы получить конфигурацию ведения журнала для каждого компонента, а log4j не находится в пути компонента, вы получитеутечка памяти происходит точно так же, как это происходит при регистрации в общем-то, и по тем же причинам.

Самое простое решение - избежать этой проблемы, сохранив log4j в WEB-INF / lib каждого приложения.