java 登录扫描不起作用

Logback scan not working

提问by Harinder

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 output, all seems fine. It clearly says the logback.xml file is being monitored for changes every 30 seconds. I am at a loss as to why changes are not being picked up. Just looking for some guidance on how I can troubleshoot this further. Thank you.

我无法使 logback 的自动扫描功能正常工作。它似乎没有接受更改。我已将 debug="true" 添加到部分并阅读它的输出，一切似乎都很好。它清楚地表明每 30 秒正在监视 logback.xml 文件的更改。我不知道为什么没有接受更改。只是在寻找有关如何进一步解决此问题的一些指导。谢谢你。

I should mention that logback is logging to the file just fine, just that changes to logback configuration file are not being picked up.

我应该提到 logback 可以很好地记录到文件中，只是没有接收到对 logback 配置文件的更改。

logback.xml file

logback.xml 文件

<?xml version="1.0" encoding="UTF-8"?>
<configuration scan="true" scanPeriod="30 seconds" debug="true">

    <statusListener class="ch.qos.logback.core.status.OnConsoleStatusListener" />  

    <property name="LOGS_PATH" value="C:\Users\****\Desktop\css_dev\q_logs" />

    <appender name="scheduledTasksAppender" class="ch.qos.logback.core.rolling.RollingFileAppender">
        <file>${LOGS_PATH}/scheduledTasks.log</file>

        <rollingPolicy class="ch.qos.logback.core.rolling.FixedWindowRollingPolicy">
            <fileNamePattern>${LOGS_PATH}/scheduledTasks.%i.log.zip</fileNamePattern>
            <minIndex>1</minIndex>
            <maxIndex>25</maxIndex>
        </rollingPolicy>

        <triggeringPolicy class="ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy">
            <maxFileSize>5MB</maxFileSize>
        </triggeringPolicy>

        <encoder>
            <pattern>%d{MMM/dd/yyyy HH:mm:ss} %-5level %logger{50} - %msg%n</pattern>
        </encoder>
    </appender>

    <logger name="tasks" level="warn" additivity="false">
        <appender-ref ref="scheduledTasksAppender"/>
    </logger>
</configuration>

Output to Tomcat log when web application starts:

Web 应用程序启动时输出到 Tomcat 日志：

|-INFO in ch.qos.logback.classic.LoggerContext[default] - Could NOT find resource [logback.groovy]
|-INFO in ch.qos.logback.classic.LoggerContext[default] - Could NOT find resource [logback-test.xml]
|-INFO in ch.qos.logback.classic.LoggerContext[default] - Found resource [logback.xml] at [file:/C:/Users/*****/Desktop/css_dev/ProjectQ/build/web/WEB-INF/classes/logback.xml]
|-INFO in ch.qos.logback.classic.joran.action.ConfigurationAction - Setting ReconfigureOnChangeFilter scanning period to 30 seconds
|-INFO in ReconfigureOnChangeFilter{invocationCounter=0} - Will scan for changes in [[C:\Users\*****\Desktop\css_dev\ProjectQ\build\web\WEB-INF\classes\logback.xml]] every 30 seconds. 
|-INFO in ch.qos.logback.classic.joran.action.ConfigurationAction - Adding ReconfigureOnChangeFilter as a turbo filter
|-INFO in ch.qos.logback.core.joran.action.StatusListenerAction - Added status listener of type [ch.qos.logback.core.status.OnConsoleStatusListener]
|-INFO in ch.qos.logback.classic.LoggerContext[default] - Could NOT find resource [logback.groovy]
|-INFO in ch.qos.logback.classic.LoggerContext[default] - Could NOT find resource [logback-test.xml]
|-INFO in ch.qos.logback.classic.LoggerContext[default] - Found resource [logback.xml] at [file:/C:/Users/*****/Desktop/css_dev/ProjectQ/build/web/WEB-INF/classes/logback.xml]
|-INFO in ch.qos.logback.classic.joran.action.ConfigurationAction - Setting ReconfigureOnChangeFilter scanning period to 30 seconds
|-INFO in ReconfigureOnChangeFilter{invocationCounter=0} - Will scan for changes in [[C:\Users\*****\Desktop\css_dev\ProjectQ\build\web\WEB-INF\classes\logback.xml]] every 30 seconds. 
|-INFO in ch.qos.logback.classic.joran.action.ConfigurationAction - Adding ReconfigureOnChangeFilter as a turbo filter
|-INFO in ch.qos.logback.core.joran.action.StatusListenerAction - Added status listener of type [ch.qos.logback.core.status.OnConsoleStatusListener]
|-INFO in ch.qos.logback.core.joran.action.AppenderAction - About to instantiate appender of type [ch.qos.logback.core.rolling.RollingFileAppender]
|-INFO in ch.qos.logback.core.joran.action.AppenderAction - About to instantiate appender of type [ch.qos.logback.core.rolling.RollingFileAppender]
|-INFO in ch.qos.logback.core.joran.action.AppenderAction - Naming appender as [scheduledTasksAppender]
|-INFO in ch.qos.logback.core.joran.action.AppenderAction - Naming appender as [scheduledTasksAppender]
|-INFO in ch.qos.logback.core.rolling.FixedWindowRollingPolicy@298f464e - Will use zip compression
|-INFO in ch.qos.logback.core.rolling.FixedWindowRollingPolicy@298f464e - Will use zip compression
|-WARN in ch.qos.logback.core.rolling.FixedWindowRollingPolicy@298f464e - Large window sizes are not allowed.
|-WARN in ch.qos.logback.core.rolling.FixedWindowRollingPolicy@298f464e - Large window sizes are not allowed.
|-WARN in ch.qos.logback.core.rolling.FixedWindowRollingPolicy@298f464e - MaxIndex reduced to 21
|-WARN in ch.qos.logback.core.rolling.FixedWindowRollingPolicy@298f464e - MaxIndex reduced to 21
|-INFO in ch.qos.logback.core.joran.action.NestedComplexPropertyIA - Assuming default type [ch.qos.logback.classic.encoder.PatternLayoutEncoder] for [encoder] property
|-INFO in ch.qos.logback.core.joran.action.NestedComplexPropertyIA - Assuming default type [ch.qos.logback.classic.encoder.PatternLayoutEncoder] for [encoder] property
|-INFO in ch.qos.logback.core.rolling.RollingFileAppender[scheduledTasksAppender] - Active log file name: C:\Users\*****\Desktop\css_dev\q_logs/scheduledTasks.log
|-INFO in ch.qos.logback.core.rolling.RollingFileAppender[scheduledTasksAppender] - Active log file name: C:\Users\*****\Desktop\css_dev\q_logs/scheduledTasks.log
|-INFO in ch.qos.logback.core.rolling.RollingFileAppender[scheduledTasksAppender] - File property is set to [C:\Users\*****\Desktop\css_dev\q_logs/scheduledTasks.log]
|-INFO in ch.qos.logback.core.rolling.RollingFileAppender[scheduledTasksAppender] - File property is set to [C:\Users\*****\Desktop\css_dev\q_logs/scheduledTasks.log]
|-INFO in ch.qos.logback.classic.joran.action.LoggerAction - Setting level of logger [tasks] to WARN
|-INFO in ch.qos.logback.classic.joran.action.LoggerAction - Setting level of logger [tasks] to WARN
|-INFO in ch.qos.logback.classic.joran.action.LoggerAction - Setting additivity of logger [tasks] to false
|-INFO in ch.qos.logback.classic.joran.action.LoggerAction - Setting additivity of logger [tasks] to false
|-INFO in ch.qos.logback.core.joran.action.AppenderRefAction - Attaching appender named [scheduledTasksAppender] to Logger[tasks]
|-INFO in ch.qos.logback.core.joran.action.AppenderRefAction - Attaching appender named [scheduledTasksAppender] to Logger[tasks]
|-INFO in ch.qos.logback.classic.joran.action.ConfigurationAction - End of configuration.
|-INFO in ch.qos.logback.classic.joran.action.ConfigurationAction - End of configuration.
|-INFO in ch.qos.logback.classic.joran.JoranConfigurator@5b63e18f - Registering current configuration as safe fallback point
|-INFO in ch.qos.logback.classic.joran.JoranConfigurator@5b63e18f - Registering current configuration as safe fallback point

回答by Arnab Biswas

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

更新（2019 年 5 月）：该错误现在似乎已修复。

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

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

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

对于 logback 1.1.7，scanPeriod需要明确提及。否则 logback 将不会扫描更改。这是由于最近引入的错误（这是链接）。

回答by ramtech

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

我遇到了类似的问题，根本原因原来是我初始化 logback 的方式。

Initial Configuration - Not working:

初始配置 - 不工作：

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

下面是我用来使用 Joran 配置 logback 的代码。

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:

此外，我的 logback xml 如下所示：

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

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

不知何故，它没有重新扫描我在 logback.xml 中的更改。

Troubleshooting

故障排除

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

因此，我通过添加调试属性在 logback.xml 中启用了调试模式，如下所示。

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

12:23:58,462 |-ch.qos.logback.classic.joran.action.ConfigurationAction 中的警告 - 由于缺少顶级配置文件，无法在更改时重新配置（配置文件扫描）。

This log is being logged by ConfigurationAction.javaclass when it is not able to find mainURLproperty in ConfigurationWatchList.

当ConfigurationAction.java类无法在ConfigurationWatchList 中找到mainURL属性时，它会记录此日志。

Modified configuration - Scan working like a charm

修改后的配置 - 扫描工作就像一个魅力

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

因此，我更改了通过JoranConfigurator. 我没有将其InputStream作为参数发送给configurator.doConfigure(is)我，而是使用了重载的doConfigure方法，该方法将文件路径本身作为参数。更新后的代码如下所示：

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

12:35:37,173 |-ch.qos.logback.classic.joran.action.ConfigurationAction 中的信息 - 将扫描 [file:/E:/Samples/config/logback.xml]
12:35:37,173 |- ch.qos.logback.classic.joran.action.ConfigurationAction 中的信息 - 将 ReconfigureOnChangeTask 扫描周期设置为 60 秒

Thats it!! Hurray :)

而已！！万岁:)

EDIT :

编辑 ：

Looking at GenericConfiguratorclass, it turns out that, mainURLis registered with ConfigurationWatchListif we use doConfigure()method which takes URL, Stringor Fileas parameter.

纵观GenericConfigurator类，事实证明，mainURL与登记的ConfigurationWatchList，如果我们使用doConfigure()方法，取URL，String或File作为参数。

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

该方法的其他三个重载（带有参数InputStream,InputSource或List<SaxEvent>）不注册它。

回答by MiguelKVidal

You logback.xml appear to be correct.

您 logback.xml 似乎是正确的。

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

这是手册中所述的行为：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.

鉴于每次调用任何记录器时都会调用 ReconfigureOnChangeFilter，无论记录器级别如何，ReconfigureOnChangeFilter 绝对是性能关键。如此之多，以至于实际上，检查扫描周期是否已经过去，本身就太昂贵了。为了提高性能，ReconfigureOnChangeFilter 实际上每 N 个日志操作“活着”一次。根据您的应用程序记录的频率，可以通过 logback 动态修改 N 的值。默认情况下，N 为 16，但对于 CPU 密集型应用程序，它可以高达 2^16 (= 65536)。

简而言之，当配置文件更改时，它会自动重新加载，但只有在多次记录器调用和扫描周期确定的延迟之后。

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

只需尝试记录更多消息并查看配置是否正确加载。

I hope this help you out.

我希望这能帮助你。

Best regards,

最好的祝福，

Miguel

米格尔

回答by Vadim Ferderer

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

扫描确实有效，但是扫描是在 target/build 目录中的 logback.xml 上完成的，这并不是很有帮助...

回答by Robert Fleming

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:

使用 logback 1.2.3，如果文件路径包含+. 例如这有效：

-Dlogback.configurationFile=etc/logback.xml

-Dlogback.configurationFile=etc/logback.xml

while this fails:

虽然这失败了：

-Dlogback.configurationFile=etc+/logback.xml

-Dlogback.configurationFile=etc+/logback.xml

Logback manages to load logback.xmlcorrectly 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.

Logback 设法logback.xml在初始化时正确加载；在后一种情况下，只是重新加载失败。如果+不起作用，则可能是其他字符也有问题。

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

我去提交了一个错误，但从https://logback.qos.ch/bugreport.html链接的 JIRA 实例目前似乎无法正常工作。