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

Expose a setExceptionListener method in DefaultJmsListenerContainerFactory [SPR-17570] #22102

Closed
spring-projects-issues opened this issue Dec 5, 2018 · 4 comments
Assignees
Labels
in: messaging Issues in messaging modules (jms, messaging) type: enhancement A general enhancement
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

leachad opened SPR-17570 and commented

As a user of the spring-jms artifacts, I would like to be able to register an exception listener on the container(s) that get generated using the DefaultJmsListenerContainerFactory.

Currently, this method is not configurable in the DefaultJmsListenerContainerFactory object but setErrorHandler for message processing is.


Reference URL: https://stackoverflow.com/questions/53639178/why-does-defaultjmslistenercontainerfactory-not-expose-setexceptionlistener-meth/53639840#53639840

@spring-projects-issues
Copy link
Collaborator Author

Stéphane Nicoll commented

There is a setErrorHandler on AbstractJmsListenerContainerFactory that is the parent of DefaultJmsListenerContainerFactory so this method is exposed.

What am I missing?

@spring-projects-issues
Copy link
Collaborator Author

Juergen Hoeller commented

Any particular use case for a custom ExceptionListener there? Any need that couldn't be implemented through an ErrorHandler through an instanceof JMSException check?

@spring-projects-issues
Copy link
Collaborator Author

leachad commented

Juergen Hoeller and Stéphane Nicoll from what I read of the spring-jms docs, the ErrorHandler is used for message handling exceptions. I'm looking at injecting a custom exception listener for connection exceptions, not for message handling exceptions

Specifically, I'm trying to hook into the exception handling that logs this error 

`[DefaultMessageListenerContainer-1] ERROR o.s.jms.listener.DefaultMessageListenerContainer Could not refresh JMS Connection for destination 'my_topic_name``

 I attempted to use an instance of JmsListenerConfigurer to set the exception listener for each DMLC, but since the containers weren't yet created, this proved fruitless.

If there were some way to have inject a preStart configuration class before startIfNecessary is invoked:

MessageListenerContainer container = createListenerContainer(endpoint, factory);
this.listenerContainers.put(id, container);
if (startImmediately) {
    startIfNecessary(container);
}

 

This code snippet is in JmsListenerEndpointRegistry.java:141-146 version 4.3.19.RELEASE

@spring-projects-issues
Copy link
Collaborator Author

leachad commented

I was able to concoct a workaround for my use case and now have telemetry in place for monitoring connections using this exception listener.

Here's what I did. Seems to work with fine running my pub sub tests locally

 

public class MyContainerFactory
extends DefaultJmsListenerContainerFactory {

private ExceptionListener exceptionListener;

/**

  • @see DefaultMessageListenerContainer#setExceptionListener
    */
    public void setExceptionListener(ExceptionListener exceptionListener) {
    this.exceptionListener = exceptionListener;
    }

@Override
protected DefaultMessageListenerContainer createContainerInstance() {
return new DefaultMessageListenerContainer();
}

@Override
protected void initializeContainer(DefaultMessageListenerContainer container) {
super.initializeContainer(container);

if (this.exceptionListener != null) {
container.setExceptionListener(this.exceptionListener);
}
}

}

 

@spring-projects-issues spring-projects-issues added in: messaging Issues in messaging modules (jms, messaging) status: waiting-for-triage An issue we've not yet triaged or decided on type: enhancement A general enhancement and removed type: enhancement A general enhancement labels Jan 11, 2019
@jhoeller jhoeller added type: enhancement A general enhancement and removed status: waiting-for-triage An issue we've not yet triaged or decided on labels Jul 19, 2020
@jhoeller jhoeller self-assigned this Jul 19, 2020
@jhoeller jhoeller added this to the 5.2.8 milestone Jul 19, 2020
FelixFly pushed a commit to FelixFly/spring-framework that referenced this issue Aug 16, 2020
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: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

2 participants