Affects: 6.0
The failure described in https://github.com/spring-projects/spring-boot/issues/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.
Comment From: snicoll
Thanks for the report.
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.