10

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.

error1009
  • 151
  • 2
  • 9
  • 1
    Couldn't you programmatically make some dummy changes to the logback.xml file so that it gets reloaded? Like adding and removing blank lines at the end of the file? – rolve Oct 31 '12 at 14:55
  • @rolve I thought about such work around. But I hope there must be more convenient way to do that. – error1009 Oct 31 '12 at 14:59
  • Thanks for the pointer @error1009. I used your suggestion but supplying file explicitly using `System.setProperty(ContextInitializer.CONFIG_FILE_PROPERTY, myNewLobackXmlFile.getPath())` before running `ci.autoConfig();` – ThomasMH Nov 07 '18 at 01:26

3 Answers3

7

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.

Pierre-Henri
  • 1,495
  • 10
  • 14
  • This, sadly, would require the application code be aware of the implementation of logging rather than the interfaces, as LoggerContext is a logback class. This is, of course assuming the poster uses slf4j as the logging facade, as is recommended. – Joel Westberg Oct 31 '12 at 15:05
  • So you propose to check changes in property file. and reload configuration if property were changed? It should work, but I think it is not good for perfomance. – error1009 Oct 31 '12 at 15:11
3

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

Gosha
  • 31
  • 3
0

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 ))

error1009
  • 151
  • 2
  • 9