Question

Idea is to make an ability to change logback configuration without redeploy. Slf4j and logback are used in project. logback.xml file is in ear, but it reads some properties from property file, which is placed out of ear. Something like that:

<configuration scan="true" scanPeriod="5 seconds">
<property file="${logconfig}"/>

<appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> 
    <encoder>
        <pattern>${logback.consolePattern}</pattern>
    </encoder>
</appender>
<root level="DEBUG">
    <appender-ref ref="STDOUT" />
</root>

</configuration>

Problem is that scan checks if logback.xml was changed (and file always the same). That's why changing values in property file doesn't changes configuration of logback. Changes are applied only after redeploy.

So what is the best way to have an ability to modify logback configuration without redeploy? Is there some mechanism that allow to realize it?

upd: changes would be made very rarely. but they should be applied as soon as possible. performance is also important.

Was it helpful?

Solution 3

After some comparing I think it would be easier and more comfortable to place logback.xml out of ear. It can be realized by specifying system property logback.configurationFile in server configuration. To make editing more convenient for people I plan to define some properties in the beginning of the file. Like that

<property name="consolePattern" value="%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n"/>

And then use them in configuration

<pattern>${consolePattern}</pattern>

It will handle problem with dynamic changes and it is almost userfriendly ))

OTHER TIPS

I manage to reload it by doing this :

LoggerContext loggerContext = (LoggerContext) LoggerFactory.getILoggerFactory();
loggerContext.reset();
ContextInitializer ci = new ContextInitializer(loggerContext);
ci.autoConfig();

In my use case, I do that to add some properties to the context by doing :

loggerContext.putProperty("logDirectory", getLogDirectory().getAbsolutePath());

before the autoConfig.

Reading properties from the properties file should work too.

Perhaps command "touch" will be useful for a fictitious file modification, after properties set.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top