-
Notifications
You must be signed in to change notification settings - Fork 3.4k
Support Bean Context for Operation Method Invocation #3945
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
22f37b6 to
36086a8
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please add a test that verifies the functionality
Please add a test that verifies the functionality
Sure! I will soon
fbb593e to
1d431f2
Compare
Signed-off-by: YeonHo Ju <nerdroid@outlook.kr>
1d431f2 to
2263f2a
Compare
@spencergibb I’ve added a test that verifies non-static methods are properly resolved to Spring beans when available. Let me know if you'd like any adjustments or additional cases.
@spencergibb I'd appreciate it if you could take a look when you get a chance!
Description
While migrating our gateway service from
spring-cloud-gateway-server-webfluxtospring-cloud-gateway-server-webmvc, I discovered a limitation in how operation methods are currently invoked inspring-cloud-gateway-server-webmvcIn
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,RouterFunctionHolderFactorycurrently never attempts to resolve an invocation target when passing anOperationMethodtoReflectiveOperationInvoker. 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