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.