-
Notifications
You must be signed in to change notification settings - Fork 1.6k
No early bean initialization from EmbeddedKafkaContextCustomizer
#2870
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
The problem is rather that the broker is starting "manually" as part of a callback that should not start any bean, see Lines 127 to 128 in 0dfde15
I think it should rather contribute a Here is an example in Spring Boot of what I mean: https://github.com/spring-projects/spring-boot/blob/8f2ec227389391fdd173db0ab64f26abd2752f20/spring-boot-project/spring-boot-test/src/main/java/org/springframework/boot/test/web/client/TestRestTemplateContextCustomizer.java#L62 |
Just debugged one of the test using
Even if we are about migrating to the Thanks |
Again, this isn't a problem with shutdown. It's not even a problem with AOT actually even if it surfaces only when one tries to process the test context using Spring AOT.
There's a huge difference. Spring Kafka creates a singleton and force start it manually at a time where only the context can be customized before the refresh (see javadoc). Spring Boot registers a bean definition that's going to be handled just like any other bean at the appropriate time.
Correct and there's nothing in the issue I can see that's asking to get a way from casting the registry. I've tried to explain that with "Unfortunately, the contract of this method is a bit strange as it should provide a registry, not a context since it has not been refreshed yet.". Within |
Still not clear why is that harmful.
won't have too much difference for the end result. |
The difference is |
Because the code starts a bean at a time where the |
EmbeddedKafkaContextCustomizer
Fixes spring-projects#2870 The `EmbeddedKafkaContextCustomizer` uses `beanFactory.initializeBean()` which is too early according to the `ApplicationContext` lifecycle since it is not refreshed yet for `ContextCustomizer` * Rework the logic in the `EmbeddedKafkaContextCustomizer` to register a `BeanDefinition` for an `EmbeddedKafkaBroker` to include it into standard `ApplicationContext` lifecycle * Also mark `@EmbeddedKafka` with a `@DisabledInAotMode` to disallow this kind of tests in native images
Fixes spring-projects#2870 The `EmbeddedKafkaContextCustomizer` uses `beanFactory.initializeBean()` which is too early according to the `ApplicationContext` lifecycle since it is not refreshed yet for `ContextCustomizer` * Rework the logic in the `EmbeddedKafkaContextCustomizer` to register a `BeanDefinition` for an `EmbeddedKafkaBroker` to include it into standard `ApplicationContext` lifecycle * Also mark `@EmbeddedKafka` with a `@DisabledInAotMode` to disallow this kind of tests in native images
EmbeddedKafkaContextCustomizer
EmbeddedKafkaContextCustomizer
* GH-2870: EmbeddedKafka: register BeanDefinition Fixes #2870 The `EmbeddedKafkaContextCustomizer` uses `beanFactory.initializeBean()` which is too early according to the `ApplicationContext` lifecycle since it is not refreshed yet for `ContextCustomizer` * Rework the logic in the `EmbeddedKafkaContextCustomizer` to register a `BeanDefinition` for an `EmbeddedKafkaBroker` to include it into standard `ApplicationContext` lifecycle * Also mark `@EmbeddedKafka` with a `@DisabledInAotMode` to disallow this kind of tests in native images * * Call `embeddedKafkaBroker.afterPropertiesSet()` explicitly in the `EmbeddedKafkaContextCustomizer` since we need to have broker started and system props initialized before the rest of `ApplicationContext`
See spring-projects/spring-framework#31453 (comment)
While we don't support the embedded broker in native images; the problem seems to be that the broker is not shut down properly.
The text was updated successfully, but these errors were encountered: