@snicoll this should be the minimal needed change.
Comment From: snicoll
I am not sure I like that the complete creation of the method endpoint is delegated to a single instance in the context for that purpose. What you are asking here is full control and I don't think this is warranted for what you're trying to do.
What happens if something else would like to tune how the endpoint is created?
I think it would be interesting if you shared what you are actually changing in the endpoint and perhaps we can work a on customizer approach instead (full control is also nice but that should be last resort rather than the first and only option).
Comment From: alesj
How is this control different from overriding MethodJmsListenerEndpoint::createMessageListenerInstance method? As I see it, it's just a bit easier way to do it.
What happens if something else would like to tune how the endpoint is created?
This is per BeanFactory, and, imho, I guess one wants the same behavior for whole BF's context? At least from my experience, where you probably know better.
I think it would be interesting if you shared what you are actually changing in the endpoint
Here: * https://github.com/alesj/java-spring-cloud/blob/reg1/opentracing-spring-cloud/src/main/java/io/opentracing/contrib/spring/cloud/jms/TracingJmsListenerEndpointRegistry.java#L99-L120
A simple way to properly add tracing for all JMS communication. Specially for any kind of "@JmsListener" (payload) usage.
Comment From: snicoll
The difference is there is no public API for that. You're offering to provide one so that becomes a feature of the framework. That, on its own, is a reason to put some boundaries.
This is per BeanFactory, and, imho, I guess one wants the same behavior for whole BF's contex
The point I was trying to make is that your solution means one particular component is in full control. Here in the context of tracing. If this is a feature and another component would like to also take action, it does not seem possible. It's a on/off switch.
Here
What you need is post-process the MessagingMessageListenerAdapter, potentially by returning a complete different instance wrapping it. That sounds a better option to me. It looks like all that would be irrelevant if MessagingMessageListenerAdapter were beans because you could then simply create a BeanPostProcessor for them.
WDYT @jhoeller?
Comment From: alesj
@snicoll or if we could be (easily) able to enhance the incoming / outgoing jms Message instance.
Comment From: snicoll
We're going to revisit the observability subject for Spring Framework 6 and #19247 is scheduled in that line. I've revisited the PR once again and I am not keen to proceed this way, thanks for the PR in any case.