Fixes: #6792 Currently, by default `AbstractJmsChannel` implementations use Java serialization for storing `Message<?>` instance into JMS destination. The deserialized message is produced from the channel as is. There might be use-cases when some JMS properties could be useful in downstream flows. * Add `DefaultJmsHeaderMapper` into the `AbstractJmsChannel` as a conditional logic to map headers to/from JMS when `jmsTemplate.getMessageConverter()` is not a `MessagingMessageConverter`. Otherwise, then conversion of the message and header mapping is done in that converter * Refactor logic in the `AbstractJmsChannel` to common API * Fix Nullability formatting in the `PollableJmsChannel` * Use lambda style for `MessageListener` in the `SubscribableJmsChannel` instead of inner extra class * Ensure in the `PollableJmsChannelTests` and `SubscribableJmsChannelTests` that header mapper does it job * Fix `JmsChannelParserTests` to not assert on the `messageBuilderFactory` since now a `MessageListener` in the `SubscribableJmsChannel` is a direct method of the class * Fix `JmsChannelHistoryTests` verification according to a new internal logic of the `AbstractJmsChannel` * Document new feature in the `jms.adoc` and `whats-new.adoc`

Commits

Commits on Feb 26, 2026

GH-6792: Add headers mapping to JMS channels