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
Describe the issue
When a binder context is created in DefaultBinderFactory, the protocol resolvers from parent context are not copied to the binder context. In our case it breaks our application because we have a protocol resolver that makes sure that the kafka truststore is a local file (by downloading it), and org.springframework.boot.autoconfigure.kafka.KafkaProperties.Ssl#resourceToPath fails if it is not on file system. I.e. it fails because the protocol resolver is not applied in the binding context, and the KafkaProperties bean is created in that context.
This is caused by the fix for spring-projects/spring-boot#41487 where configuration properties beans are re-created in child contexts rather than inherited from the parent context. I'll leave it for you to evaluate if a fix should go into spring-boot or spring-cloud-stream. E.g. should the protocol resolvers be explicitly copied when creating the child context here? Or should protocol resolvers be automatically inherited from parent context?
To Reproduce
I create this test to demonstrate the issue:
Describe the issue
When a binder context is created in
DefaultBinderFactory
, the protocol resolvers from parent context are not copied to the binder context. In our case it breaks our application because we have a protocol resolver that makes sure that the kafka truststore is a local file (by downloading it), andorg.springframework.boot.autoconfigure.kafka.KafkaProperties.Ssl#resourceToPath
fails if it is not on file system. I.e. it fails because the protocol resolver is not applied in the binding context, and the KafkaProperties bean is created in that context.This is caused by the fix for spring-projects/spring-boot#41487 where configuration properties beans are re-created in child contexts rather than inherited from the parent context. I'll leave it for you to evaluate if a fix should go into spring-boot or spring-cloud-stream. E.g. should the protocol resolvers be explicitly copied when creating the child context here? Or should protocol resolvers be automatically inherited from parent context?
To Reproduce
I create this test to demonstrate the issue:
Version of the framework
4.2.1 (with spring-boot 3.4.3)
Expected behavior
Protocol resolvers are applied also in the child context.
The text was updated successfully, but these errors were encountered: