-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Revise configuration code for better Spring Native support #3502
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
Comments
Looks like Spring requires explicit public default ctor for that type of beans in Native mode:
|
Another more obvious reflection problem:
where the code is like this:
so, need to figure out how to avoid reflection over there or find out the way to teach it to work with Native image... |
Yeah... Better to say this: https://docs.spring.io/spring-native/docs/current-SNAPSHOT/reference/htmlsingle/#how-to-contribute to align with whatever is the latest. |
Reopen: the work is not done yet. |
Or even
and respective Java DSL:
Well, technically every single place where we indeed rely on the reflection at runtime. |
We probably can figure out something on the framework level how to be with this and similar SpEL expressions we use for out-of-the-box and support components, but it is definitely has to be somehow addressed in the target projects for end-user expressions and their types. Probably the same |
Fixes spring-projects#3502 * Move `ChannelInitializer` bean registration into an `AbstractIntegrationNamespaceHandler` - it was never used for annotations and Java DSL... * Rework `IntegrationFlows.fromSupplier()` to call a provided `Supplier` directly - not via reflection in the `MethodInvokingMessageSource` * Resolve new Sonar smells
Fixes spring-projects#3502 * Move `ChannelInitializer` bean registration into an `AbstractIntegrationNamespaceHandler` - it was never used for annotations and Java DSL... * Rework `IntegrationFlows.fromSupplier()` to call a provided `Supplier` directly - not via reflection in the `MethodInvokingMessageSource` * Resolve new Sonar smells * Rework `EndpointSpec` to accept an expected factory bean instance via ctor arg instead of reflection * Rework `Jackson2JsonObjectMapper` to use well-known module instances directly - not via reflection from their class names
I'm moving this issue back to With the latest PR the basic app works well. |
* GH-3502: More refactoring to avoid reflection Fixes #3502 * Move `ChannelInitializer` bean registration into an `AbstractIntegrationNamespaceHandler` - it was never used for annotations and Java DSL... * Rework `IntegrationFlows.fromSupplier()` to call a provided `Supplier` directly - not via reflection in the `MethodInvokingMessageSource` * Resolve new Sonar smells * Rework `EndpointSpec` to accept an expected factory bean instance via ctor arg instead of reflection * Rework `Jackson2JsonObjectMapper` to use well-known module instances directly - not via reflection from their class names * * Revert `DefaultMethodInvokingMethodInterceptor.methodHandleCache` property definition wrap
See more info in Spring Native.
At the moment it is important to revise
ImportSelector
impls and class presence checks.Related to: spring-projects/spring-framework#18353
The text was updated successfully, but these errors were encountered: