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

AbstractMessageListenerContainer documentation and code disagree regarding log level #30730

Closed
Sti2nd opened this issue Jun 23, 2023 · 3 comments
Assignees
Labels
in: messaging Issues in messaging modules (jms, messaging) type: documentation A documentation task
Milestone

Comments

@Sti2nd
Copy link

Sti2nd commented Jun 23, 2023

Problem

The documentation for AbstractMessageListenerContainer says it will log any such exception at the error level, but the code in AbstractMessageListenerContainer's invokeErrorHandler() method logs with WARN level.

Also reported in comments on this Stack Overflow answer: https://stackoverflow.com/a/8922645/6113915

Reproduce

Code to create error in JMS Listener and reproduce WARN log.

@JmsListener(destination = "SOME_DEST", containerFactory = "jmsListenerContainerFactory")
fun receiveMessage(message: String, @Header("NON_EXISTING_HEADER") correlationId: String) {
        // Will throw org.springframework.jms.listener.adapter.ListenerExecutionFailedException because header is non existing
    }

Log from above code:

2023-06-23 08:11:04,488 WARN  [org.springframework.jms.JmsListenerEndpointContainer#0-1] AbstractMessageListenerContainer: Execution of JMS message listener failed, and no ErrorHandler has been set.
org.springframework.jms.listener.adapter.ListenerExecutionFailedException: Listener method could not be invoked with incoming message
@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged or decided on label Jun 23, 2023
@sbrannen sbrannen added in: messaging Issues in messaging modules (jms, messaging) type: documentation A documentation task and removed status: waiting-for-triage An issue we've not yet triaged or decided on labels Jun 23, 2023
@sbrannen sbrannen changed the title AbstractMessageListenerContainer documentation and code disagrees about loglevel AbstractMessageListenerContainer documentation and code disagree regarding log level Jun 23, 2023
@sbrannen sbrannen self-assigned this Jun 23, 2023
@sbrannen sbrannen added this to the 6.0.11 milestone Jun 23, 2023
@sbrannen
Copy link
Member

Hi @Sti2nd,

Congratulations on submitting your first issue for the Spring Framework! 👍

The documentation has been updated for inclusion in 6.0.11.

@Sti2nd
Copy link
Author

Sti2nd commented Jun 24, 2023

Thank you 🤝 Good quick work by yourself, @sbrannen!

FYI I created an error handler just to log with error level instead because I can't think of a reason I don't want to know about these errors.

connectionFactory.setErrorHandler { t -> log.error("Error in listener", t) }

I assume that there is some reason for Spring to hide these errors in warning 🤔 If anyone knows I would gladly learn

@sbrannen
Copy link
Member

I assume that there is some reason for Spring to hide these errors in warning 🤔 If anyone knows I would gladly learn

It's been that way since before Spring Framework 3.0, as far as I can tell.

I believe it's simply to reduce the amount of log output when an application is configured to only display ERROR level logging.

Though perhaps @jhoeller can provide further insight.

mdeinum pushed a commit to mdeinum/spring-framework that referenced this issue Jun 29, 2023
This commit updates AbstractMessageListenerContainer's Javadoc
regarding the log level used in invokeErrorHandler() so that the
documentation aligns with the implementation, namely that errors will
logged at WARN level if no ErrorHandler has been registered.

Closes spring-projectsgh-30730
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: messaging Issues in messaging modules (jms, messaging) type: documentation A documentation task
Projects
None yet
Development

No branches or pull requests

3 participants