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

@PreDestroy methods: messages logged with logback are lost #24431

Closed
Katharsas opened this issue Jan 26, 2020 · 3 comments
Closed

@PreDestroy methods: messages logged with logback are lost #24431

Katharsas opened this issue Jan 26, 2020 · 3 comments
Assignees

Comments

@Katharsas
Copy link

Katharsas commented Jan 26, 2020

Affected:
Spring MVC: 5.2.2 (and older most likely)
Logback Version: 1.2.3

When using SLF4J with logback to log in a @PreDestroy method of a @Service class, the messages are lost because apparently logback shuts itself down before the user's @PreDestroy methods complete. Its easy to not notice the missing logs for a while.

The current workaround is to disable the servlet lifecycle feature of logback. Ideally either Spring or Logback would figure out when to shut Logback down without users having to workaround this (btw, i don't know if the current workaround has any negative effects like preventing proper Logback shutdown).

This is basically the same issue as:
https://stackoverflow.com/questions/47184045/spring-predestroy-no-logging-because-logback-stops-too-soon
and similar to (but for Spring instead of Spring Boot and logback instead of Log4j2):
spring-projects/spring-boot#11360

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged or decided on label Jan 26, 2020
@rstoyanchev
Copy link
Contributor

rstoyanchev commented Jan 27, 2020

You could try a web-fragment to your WAR mode that fixes the order of spring_web relative to other fragments with a declaration like this:

<absolute-ordering>
    <others/>
    <name>spring_web</name>
    <name>ch.qos.logback.classic.servlet.LogbackServletContainerInitializer</name>
</absolute-ordering>

If this can be confirmed to work, I can add something to our docs, but I don't think we are in a position to control the order of ServletContainerInializers are invoked.

This reminds me also of a recent change in Tomcat related to the order of SCI initialization. If you're using Tomcat it's worth trying one of the fixed versions to see if it makes a difference.

@rstoyanchev rstoyanchev self-assigned this Jan 27, 2020
@rstoyanchev rstoyanchev added the status: waiting-for-feedback We need additional information before we can continue label Jan 27, 2020
@spring-projects-issues
Copy link
Collaborator

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

@spring-projects-issues spring-projects-issues added the status: feedback-reminder We've sent a reminder that we need additional information before we can continue label Feb 3, 2020
@spring-projects-issues
Copy link
Collaborator

Closing due to lack of requested feedback. If you would like us to look at this issue, please provide the requested information and we will re-open the issue.

@spring-projects-issues spring-projects-issues removed status: waiting-for-feedback We need additional information before we can continue status: feedback-reminder We've sent a reminder that we need additional information before we can continue status: waiting-for-triage An issue we've not yet triaged or decided on labels Feb 10, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants