Logback является жизнеспособным решением для решения этой проблемы. После просмотра различных хаков для работы с log4j, мы решили переключиться на Logback. Я использовал следующую конфигурацию с jar Logback внутри веб-приложения.
Файл Logback внутри веб-приложения, который включает внешний файл:
<?xml version="1.0" encoding="UTF-8" ?>
<configuration scan="true" scanPeriod="10 seconds">
<contextListener class="ch.qos.logback.classic.jul.LevelChangePropagator">
<resetJUL>true</resetJUL>
</contextListener>
<contextName>${project.artifactId}</contextName>
<jmxConfigurator />
<include file="${logback.configuration.filepath}" />
</configuration>
${logback.configuration.filepath}
заменяется во время фильтрации Maven точным путем, внешним по отношению к веб-приложению файла конфигурации (что-то вроде / opt / server / conf / loback.included.conf ).
И затем содержимое logback.included.conf
(этот файл является частью проекта, поставляемого с build-helper:attach-artifact
, поэтому ${project.artifactId}
также заменяется во время фильтрации Maven):
<?xml version="1.0" encoding="UTF-8" ?>
<included>
<appender name="file" class="ch.qos.logback.core.FileAppender">
<file>/var/log/server/${project.artifactId}.log</file>
<encoder>
<pattern>[@/%contextName] %date{ISO8601} [%-5level] %thread:[%logger] %msg%n</pattern>
</encoder>
</appender>
<root level="INFO">
<appender-ref ref="file" />
</root>
</included>
Единственное ограничение, содержимое включаемого файла должно соответствовать одному из включаемых файлов. На самом деле просто пишу правила.