Skip to content
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

Wrong logging pattern with multiple web applications #24835

Closed
windmueller opened this issue Jan 14, 2021 · 2 comments
Closed

Wrong logging pattern with multiple web applications #24835

windmueller opened this issue Jan 14, 2021 · 2 comments
Labels
type: regression A regression from a previous release
Milestone

Comments

@windmueller
Copy link

windmueller commented Jan 14, 2021

After updating Spring Boot from 2.3.5 to 2.4.1, our logging patterns are messed up. Our setup is that we deploy multiple Spring Boot applications onto the same Tomcat. When the first application is deployed, it sets the system property LOG_LEVEL_PATTERN which seems to be evaluated for all applications that are being deployed afterwards.

The log pattern itself is modified by Spring Cloud and looks like

%5p [${spring.zipkin.service.name:${spring.application.name:}},%X{traceId:-},%X{spanId:-}]

When using Spring Boot 2.3.5, spring.application.name could not be resolved during the evaluation of LoggingSystemProperties, but this seems to have changed with 2.4.1.

Is it even possible to disable the system property setting so that there is no conflict between the applications?

Update: I think the difference can be found in org.springframework.boot.logging.logback.LogbackLoggingSystem#loadDefaults. In 2.3.5, LOG_LEVEL_PATTERN was initialized for the logger context in this method. However, in 2.4.1 the context no longer contains this property. It is evaluated in ch.qos.logback.core.subst.NodeToStringTransformer#lookupKey.

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Jan 14, 2021
@wilkinsona
Copy link
Member

Thanks for the report. #23767 removed the code that set the properties on the logger context. This works fine in the common scenario where there's a single application per JVM but not when multiple applications share a JVM as one application's configuration may set system properties that overwrite another's.

@wilkinsona wilkinsona added type: regression A regression from a previous release and removed status: waiting-for-triage An issue we've not yet triaged labels Jan 14, 2021
@wilkinsona wilkinsona added this to the 2.4.x milestone Jan 14, 2021
@mbhave mbhave closed this as completed in 68fc232 Jan 15, 2021
@mbhave mbhave modified the milestones: 2.4.x, 2.4.2 Jan 15, 2021
philwebb added a commit that referenced this issue Jan 15, 2021
Update `LoggingSystemProperties` so that system environment properties
are also applied to the `LoggerContext`. This is required when multiple
applications are deployed to the same Servlet container. In such setups
there's only a single JVM and the System Environment can be changed
when multiple applications start at the same time.

Fixes gh-24835
@windmueller
Copy link
Author

From bug report to release with fix in less than a day. I am impressed, thank you very much!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: regression A regression from a previous release
Projects
None yet
Development

No branches or pull requests

4 participants