Logback autoreload feature (scan=true) not compatible with springProfile and springProperty

[oxygensar]

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?

[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 :(