Spring Boot 1.3.2.RELEASE

During initialization of Logback SpringBoot uses its own class SpringBootJoranConfigurator (that extends JoranConfigurator) to suppoer configuration feature. And then it uses it like this:

private void configureByResourceUrl(
             LoggingInitializationContext initializationContext,
             LoggerContext loggerContext, URL url) throws JoranException {
       if (url.toString().endsWith("xml")) {
             JoranConfigurator configurator = new SpringBootJoranConfigurator(
                           initializationContext);
             configurator.setContext(loggerContext);
             configurator.doConfigure(url);
       }
       else {
             new ContextInitializer(loggerContext).configureByResource(url);
       }
}

At the same time Logback (when running with scan=true option) uses turbofilter ReconfigureOnChangeFilter to monitor for logback.xml file changes and when that change happens run this code to reconfigure itself:

private void performXMLConfiguration(LoggerContext lc) {
      JoranConfigurator jc = new JoranConfigurator();
      jc.setContext(context);
      StatusUtil statusUtil = new StatusUtil(context);
      List<SaxEvent> eventList = jc.recallSafeConfiguration();
      URL mainURL = ConfigurationWatchListUtil.getMainWatchURL(context);
      lc.reset();
      long threshold = System.currentTimeMillis();
      try {
      jc.doConfigure(mainConfigurationURL);
      if (statusUtil.hasXMLParsingErrors(threshold)) {
        fallbackConfiguration(lc, eventList, mainURL);
      }
      } catch (JoranException e) {
      fallbackConfiguration(lc, eventList, mainURL);
      }
}

and at that moment JoranConfigurator simply doesnt know how to process springProperty::

ERROR in ch.qos.logback.core.joran.spi.Interpreter@4:71 - no applicable action for [springProperty], current ElementPath is [[configuration][springProperty]]

This all makes springProperties unusable when running with logback autoreload feature enabled (scan=true)... Do you have any plans or thought on this issue?

Comment From: philwebb

Thanks for the detailed analysis! Unfortunately I don't use scan=true so I missed this one.

It looks like it's going to be very tricky to hook into ReconfigureOnChangeFilter, I guess the only thing we could do is write our own version (which seems like a lot of work). Spring Cloud already has support for updating log levels, so if that's the only thing you need scan=true for, perhaps you could use that?

I'm afraid for now, we'll probably need to leave this as a known limitation :(

Comment From: timomeinen

One can workaround the problem with Conditional processing using the Janino library:

    <if condition='property("spring.profiles.active").contains("development")'>
        <then>
            <include resource="org/springframework/boot/logging/logback/base.xml" />
        </then>
        <else>
            <include resource="org/springframework/boot/logging/logback/defaults.xml" />
    …

Comment From: onkarsarkate22

Hello, I'm facing the same issue while using Logback scan=true with springProperty. Can someone provide an update on whether this has been resolved or if there's a workaround available now? Thank you !

Comment From: wilkinsona

This remains a known and documented limitation. Unfortunately, there are no known workarounds beyond the suggestion above.