Skip to content

Conversation

artembilan
Copy link
Member

…toryBean`

Fixes: #10309

The call of the BeanFactory.initializeBean() on the internal GatewayProxyFactoryBean instance of the GatewayMessageHandler causes an extra bean to be processed everywhere. Since such a registration happens from the GatewayMessageHandler.start(), the SpringIntegrationTestExecutionListener#prepareTestInstance may suffer from a ConcurrentModificationException on the autoStartupCandidates.
Just because its logic is to call start() from that autoStartupCandidates collection iteration.

Essentially, we don't need that since a GatewayMessageHandler is a bean itself. The GatewayProxyFactoryBean is used internally to avoid logic duplication of the proxy creating on the provided interface.

  • Rework the logic of the GatewayMessageHandler to call all the respective BeanFactory call-backs manually.
  • Add an IntegrationFlow bean with a gateway() into the MockMessageHandlerTests to ensure that SpringIntegrationTestExecutionListener does not suffer from a ConcurrentModificationException anymore.

Auto-cherry-pick to 6.5.x

…gatewayProxyFactoryBean`

Fixes: spring-projects#10309

The call of the `BeanFactory.initializeBean()` on the internal `GatewayProxyFactoryBean`
instance of the `GatewayMessageHandler` causes an extra bean to be processed everywhere.
Since such a registration happens from the `GatewayMessageHandler.start()`,
the `SpringIntegrationTestExecutionListener#prepareTestInstance` may suffer from a `ConcurrentModificationException`
on the `autoStartupCandidates`.
Just because its logic is to call `start()` from that `autoStartupCandidates` collection iteration.

Essentially, we don't need that since a `GatewayMessageHandler` is a bean itself.
The `GatewayProxyFactoryBean` is used internally to avoid logic duplication of the proxy
creating on the provided interface.

* Rework the logic of the `GatewayMessageHandler` to call all the respective `BeanFactory`
call-backs manually.
* Add an `IntegrationFlow` bean with a `gateway()` into the `MockMessageHandlerTests`
to ensure that `SpringIntegrationTestExecutionListener` does not suffer from a `ConcurrentModificationException`
anymore.

**Auto-cherry-pick to `6.5.x`**
@artembilan artembilan requested a review from cppwfs August 13, 2025 18:16
Copy link
Contributor

@cppwfs cppwfs left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM
Good idea!

@cppwfs cppwfs merged commit 60314fe into spring-projects:main Aug 14, 2025
3 of 4 checks passed
spring-builds pushed a commit that referenced this pull request Aug 14, 2025
…toryBean` (#10311)

Fixes: #10309

The call of the `BeanFactory.initializeBean()` on the internal `GatewayProxyFactoryBean`
instance of the `GatewayMessageHandler` causes an extra bean to be processed everywhere.
Since such a registration happens from the `GatewayMessageHandler.start()`,
the `SpringIntegrationTestExecutionListener#prepareTestInstance` may suffer from a `ConcurrentModificationException`
on the `autoStartupCandidates`.
Just because its logic is to call `start()` from that `autoStartupCandidates` collection iteration.

Essentially, we don't need that since a `GatewayMessageHandler` is a bean itself.
The `GatewayProxyFactoryBean` is used internally to avoid logic duplication of the proxy
creating on the provided interface.

* Rework the logic of the `GatewayMessageHandler` to call all the respective `BeanFactory`
call-backs manually.
* Add an `IntegrationFlow` bean with a `gateway()` into the `MockMessageHandlerTests`
to ensure that `SpringIntegrationTestExecutionListener` does not suffer from a `ConcurrentModificationException`
anymore.

(cherry picked from commit 60314fe)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

ConcurrentModificationException When IntegrationFlow uses gateway
2 participants