Spring Batch Integration 7.1.1 breaks Spring Batch Integration JMS

[licenziato]

After upgrading to Spring Integration 7.1.x, remote chunking and remote partitioning configurations fail to progress. The manager step hangs indefinitely waiting for responses from worker nodes.

Bug description
Upon debugging, worker reply messages successfully reach the manager's inbound channel but are rejected or ignored by the internal step Aggregator. The framework-generated correlationId is missing from the incoming message headers.
This is caused by the stricter header-mapping security policies introduced in Spring Integration 7.1.1. Specifically, when utilizing a standard DefaultJmsHeaderMapper with an external broker like ActiveMQ Artemis, core Spring Integration framework headers such as correlationId, sequenceNumber, and sequenceSize are stripped out by default on inbound/outbound passes unless explicitly whitelisted via programmatic configuration.

Upgrading to Spring Boot 4.1.1 / Spring Integration causes remote partitioning over JMS to fail with java.lang.IllegalStateException: Null correlation not allowed

The RemotePartitioningManagerStepBuilderFactory automatically builds a reply aggregator that uses a default HeaderAttributeCorrelationStrategy expecting the correlationId header to be present.

Spring Integration sets the internal correlationId as NOT primitive like a java.util.UUID. Because JMS properties must be primitives or Strings, the DefaultJmsHeaderMapper silently strips the correlationId during serialization. When the worker replies, the header is missing, and the aggregator crashes.

Environment

• Spring Batch Integration 6.0.5
• Spring Integration 7.1.1

Steps to reproduce

1. Configure a standard Remote Chunking or Remote Partitioning Manager using RemoteChunkingManagerBuilder.
2. Transport messages over JMS (e.g., ActiveMQ Artemis) using default Jms.outboundAdapter().
3. Execute the batch job under Spring Integration 7.1.1.
4. Observe that workers process chunks successfully and send responses back, but the manager's aggregation layer never reconciles them because the correlationId header is lost.

Expected behavior
The correlationId is passed around with a provided custom HeaderMapper or the documentation needs to be updated to highlight this blocking situation.

For now my working configuration is using a custom 'all allowed' header mapper:

  @Bean
    public DefaultJmsHeaderMapper batchJmsHeaderMapper() {
        return new DefaultJmsHeaderMapper("*");
    }

and plug it into all the outbound and inbound adapters, e.g. :

Jms.messageDrivenChannelAdapter(connectionFactory)
                    .destination("artemis.batch.replies")
                    .headerMapper(batchJmsHeaderMapper))

Minimal Complete Reproducible example