Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
oxygensar opened this issue Apr 5, 2016 · 4 comments
Assignees
Labels
type: documentation A documentation update
Milestone

Comments

@oxygensar
Copy link

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?

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Apr 5, 2016
@philwebb philwebb removed the status: waiting-for-triage An issue we've not yet triaged label Apr 6, 2016
@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Apr 6, 2016
@philwebb
Copy link
Member

philwebb commented Apr 6, 2016

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

@philwebb philwebb removed the status: waiting-for-triage An issue we've not yet triaged label Apr 6, 2016
@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Jul 17, 2016
@philwebb philwebb added priority: normal type: documentation A documentation update and removed status: waiting-for-triage An issue we've not yet triaged labels Jan 9, 2017
@philwebb philwebb added this to the 1.4.4 milestone Jan 9, 2017
@wilkinsona wilkinsona changed the title Logback autoreload feature (scan=true) not compatible with springProperty Logback autoreload feature (scan=true) not compatible with springProfile and springProperty Jan 17, 2017
@wilkinsona wilkinsona self-assigned this Jan 17, 2017
@timomeinen
Copy link

timomeinen commented Oct 21, 2017

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" />
    …

@onkarsarkate22
Copy link

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 !

@wilkinsona
Copy link
Member

wilkinsona commented Oct 19, 2023

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: documentation A documentation update
Projects
None yet
Development

No branches or pull requests

6 participants