You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The failure described in spring-projects/spring-boot#37637 occurs because there's a bean property value that is an instance of MultipartConfigElement. The code generation that runs during AOT processing doesn't know how to handle such a value and it fails. This can be addressed by using an inner-bean to describe the multipart config but, as discussed with @snicoll, it would be nicer if this wasn't necessary.
This could perhaps be achieved by allowing custom org.springframework.beans.factory.aot.BeanDefinitionPropertyValueCodeGenerator.Delegate or similar implementations to be plugged in through aot.factories or some other mechanism.
The text was updated successfully, but these errors were encountered:
I wonder if this goes in the territory of custom code generation or not. Registering a "generic" delegate that would handle MultipartConfigElement is probably more desirable unless there is special knowledge of how the instance is structured. We could change BeanDefinitionPropertyValueCodeGenerator so that it has a ClassLoader to load implementations from aot.factories.
There is then the question of ordering those instances against the default. Ideally the ones that are hard-coded should have a predictive order. so that you could eventually override some behavior.
This commits allows ValueCodeGenerator$Delegate implementations to be
loaded from `META-INF/spring/aot.factories` and considered for code
generation of bean definition property values. This default behavior
in DefaultBeanRegistrationCodeFragments can be customized as usual.
Closesspring-projectsgh-31427
Affects: 6.0
The failure described in spring-projects/spring-boot#37637 occurs because there's a bean property value that is an instance of
MultipartConfigElement
. The code generation that runs during AOT processing doesn't know how to handle such a value and it fails. This can be addressed by using an inner-bean to describe the multipart config but, as discussed with @snicoll, it would be nicer if this wasn't necessary.This could perhaps be achieved by allowing custom
org.springframework.beans.factory.aot.BeanDefinitionPropertyValueCodeGenerator.Delegate
or similar implementations to be plugged in throughaot.factories
or some other mechanism.The text was updated successfully, but these errors were encountered: