missing reflection data for `CGLIB$SET_THREAD_CALLBACKS` in configuration properties class about spring-framework

[wilkinsona]

Thanks for the report.

There's quite a lot going on in the demo application. There are many classes that I don't think are related to the problem. Kotlin is also involved which makes things quite a bit more complicated, particularly when using GraalVM. Can you please reduce the classes involved to the bare minimum required to reproduce the problem and, unless the problem only occurs with Kotlin, please write those classes in Java.

[cmdjulian]

I minified the example in the repository. Please check again. I now identified the main problem. It is not related to kotlin. The main problem seems to be the @Lazy in the BeanPostProcessor. Without that @Lazy the tests run successfully.

[cmdjulian]

I also tried refactoring my code to use ObjectProvider<MqttProperties> via class MqttSubscriberCollector(private val config: ObjectProvider<MqttProperties>) : BeanPostProcessor but this seems to not work here, as the following error is reported: Caused by: org.springframework.beans.factory.BeanCurrentlyInCreationException: Error creating bean with name 'mqtt-de.smartsquare.starter.mqtt.MqttProperties': Requested bean is currently in creation: Is there an unresolvable circular reference?

Any other way I could ditch the @Lazy as a workaround?

[wilkinsona]

Thanks very much for minimising the sample.

Using ObjectProvider<MqttProperties> seems to work for me (with your Java-based sample) so I'm not sure what's happening for you when you try it using Kotlin.

The use of @Lazy causes MqttProperties to be proxied. Ideally, Spring Framework's AOT support would generate the necessary reflection metadata for this automatically but that isn't happening. I also tried using a @Bean method with a @Lazy parameter:

@Bean
static MqttSubscriberCollector mqttSubscriverCollectior(@Lazy MqttProperties properties) {
    return new MqttSubscriberCollector(properties);
}

My goal was to make the use of @Lazy more obvious such that it would be automatically detected by Framework but it was not successful.

We'll transfer this to the Framework team so that they can investigate.

[cmdjulian]

Yeah I got it working with ObjectProvider meanwhile. Was just a stupid mistake to eagerly call the getObject() method inside the bean post processors constructor. You were right, that seems to workaround this. Thanks for investigating 😃

[snicoll]

Thanks for the report, I believe this is a duplicate of #30985 and we'll validate this sample when we get to it.