Support Bean Context for Operation Method Invocation #3945
+31
−2
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
While migrating our gateway service from
spring-cloud-gateway-server-webflux
tospring-cloud-gateway-server-webmvc
, I discovered a limitation in how operation methods are currently invoked inspring-cloud-gateway-server-webmvc
In
spring-cloud-gateway-server-webflux
, it is possible to rely on spring bean lifecycle for dependency injection and to compose logic in a typical spring-oriented manner. However, inspring-cloud-gateway-server-webmvc
,RouterFunctionHolderFactory
currently never attempts to resolve an invocation target when passing anOperationMethod
toReflectiveOperationInvoker
. As a result, methods defined as instance methods within a spring bean cannot be used as operation methods — only static methods are currently supported.In my opinion, given that this project is part of the spring cloud gateway family, it seems natural to support resolving a bean instance from the application context when the declaring type of an OperationMethod is registered as a bean. This behavior would align with spring’s general design philosophy, allowing bean-managed components to participate in operation method invocation without requiring them to be static.
The proposed change introduces a small enhancement to RouterFunctionHolderFactory, enabling resolution of a bean instance from the BeanFactory when invoking non-static OperationMethods. If the declaring type is not registered as a bean or multiple candidates are found, the invocation gracefully falls back to the existing reflective behavior — ensuring full backward compatibility.
Use Case Example