Logback scan not working

Question

I am having trouble getting the auto scan functionality of logback to work. It doesn\'t seem to pick up the changes. I have added debug=\"true\" to section and reading it\'s ou

Answer 1

Scanning does work actually, but the scanning is done on the logback.xml in the target/build directory, which isn't really helpful...

Answer 2

Update (May, 2019) : The bug seems to be fixed now.

=============================================================================

With logback 1.1.7, scanPeriod needs to be explicitly mentioned. Otherwise logback will not scan for changes. This is due to recently introduced bug (Here is the link).

Answer 3

I faced similar issue and the root cause turned out to be the way how I was initializing the logback.

Initial Configuration - Not working:

Below is the code which I used to configure logback using Joran.

LoggerContext context = (LoggerContext) LoggerFactory.getILoggerFactory();
JoranConfigurator configurator = new JoranConfigurator();
configurator.setContext(context);
InputStream is = new FileInputStream(logConfigPath); // 'logConfigPath' is String path of logback.xml.
configurator.doConfigure(is);

In addition, my logback xml looked as below:

<configuration scan="true" scanPeriod="60 seconds">
....
</configuration>

Somehow, it was not re-scanning my changes in logback.xml.

Troubleshooting

So, I enabled debug mode in logback.xml by adding debug attribute as below.

<configuration scan="true" scanPeriod="60 seconds" debug="true">
....
</configuration>

When I ran the application again, I observed a log statement showing the root cause of the issue.

12:23:58,462 |-WARN in ch.qos.logback.classic.joran.action.ConfigurationAction - Due to missing top level configuration file, reconfiguration on change (configuration file scanning) cannot be done.

This log is being logged by ConfigurationAction.java class when it is not able to find mainURL property in ConfigurationWatchList.

Modified configuration - Scan working like a charm

So I changed the code where I was configuring logback via JoranConfigurator. Instead of sending InputStream as parameter to configurator.doConfigure(is) I used the overloaded doConfigure method which takes file path itself as parameter. Updated code looked like this:

LoggerContext context = (LoggerContext) LoggerFactory.getILoggerFactory();
JoranConfigurator configurator = new JoranConfigurator();
configurator.setContext(context);
configurator.doConfigure(logConfigPath);// 'logConfigPath' is String path of logback.xml.

Updated debug log:

12:35:37,173 |-INFO in ch.qos.logback.classic.joran.action.ConfigurationAction - Will scan for changes in [file:/E:/Samples/config/logback.xml]
12:35:37,173 |-INFO in ch.qos.logback.classic.joran.action.ConfigurationAction - Setting ReconfigureOnChangeTask scanning period to 60 seconds

Thats it!! Hurray :)

EDIT :

Looking at GenericConfigurator class, it turns out that, mainURL is registered with ConfigurationWatchList if we use doConfigure() method which takes URL, String or File as parameter.

Other three overloads of the method (with parameters InputStream, InputSource or List<SaxEvent>) do not register it.

Answer 4

With logback 1.2.3, config file rescanning also seems to silently fail if the path to the file contains a +. E.g. this works:

-Dlogback.configurationFile=etc/logback.xml

while this fails:

-Dlogback.configurationFile=etc+/logback.xml

Logback manages to load logback.xml correctly at initialization; it's just the reloading that fails in the latter case. If + doesn't work, it's possible that other characters are also problematic.

I went to file a bug on it but the JIRA instance linked from https://logback.qos.ch/bugreport.html seems to be currently nonfunctional.

Answer 5

You logback.xml appear to be correct.

This is a behavior stated in the manual: http://logback.qos.ch/manual/configuration.html#autoScan,

Given that ReconfigureOnChangeFilter is invoked every time any logger is invoked, regardless of logger level, ReconfigureOnChangeFilter is absolutely performance critical. So much so that in fact, the check whether the scan period has elapsed or not, is too costly in itself. In order to improve performance, ReconfigureOnChangeFilter is in reality "alive" only once every N logging operations. Depending on how often your application logs, the value of N can be modified on the fly by logback. By default N is 16, although it can go as high as 2^16 (= 65536) for CPU-intensive applications.

In short, when a configuration file changes, it will be automatically reloaded but only after several logger invocations and after a delay determined by the scanning period.

Just try to log some more messages and see if the configuration is correctly loaded.

I hope this help you out.

Best regards,

Miguel