With new JMS Observability integration, JmsDefaultListenerContainerSpec could support a builder setter for new ObservationRegistry attribute

[nightswimmings]

Spring Boot is adding Observability and Traceability to JMS on the new micrometer-tracing layer.
So as soon as this is available in 3.2.0, we will miss a way to pass it in the JmsDefaultListenerContainerSpec builder when creating it like:

 Jms.container(jmsContainerFactory, topicDestination)
         .pubSubDomain(isTopic)
         .sessionAcknowledgeMode(Session.SESSION_TRANSACTED)
         .sessionTransacted(true)
          .cacheLevel(DefaultMessageListenerContainer.CACHE_AUTO)
          .taskExecutor(Executors.newCachedThreadPool())
          **.observarionRegistry(...)**
          .getObject()

See reference ticket: spring-projects/spring-framework#30335 (comment)

[artembilan]

So, the JmsListenerContainerSpec should be enhanced with an observarionRegistry() option to delegate to respective AbstractMessageListenerContainer.setObservationRegistry().

The contribution is welcome: https://github.com/spring-projects/spring-integration/blob/main/CONTRIBUTING.adoc!
Let us know if you are willing to do that!
Or @AdamaSorho will pick it up quickly 😉

[nightswimmings]

I can try at home in the next days if you are not in much hurry!

[artembilan]

Thanks.
Yes, technically, we are in a hurry for upcoming milestone next Tuesday, but since it is not a bug and there is indeed a workaround like I explained here: https://stackoverflow.com/questions/77107286/tracing-in-spring-integration-spring-boot-3-0-9, we are good to wait for the fix later on.

[artembilan]

FYI, I have some related fix which might not require an interaction with listener container in Spring JMS: #8740.
Just because Spring Integration listener is, essentially, a consumer for of those JMS messages, therefore setting one or another observation is enough.
More over we have it pretty convenient on Spring Integration side: just @EnableIntegrationManagement(observationPatterns = "observedJms*") - and those listeners will be observed.

I don't say, thought, that we should not expose the mentioned option on a JmsListenerContainerSpec, which is, essentially, a builder for target AbstractMessageListenerContainer instance and really can be used outside of Spring Integration flows.