-
Notifications
You must be signed in to change notification settings - Fork 624
spring cloud stream destroys The readyness state #2083
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
I read now the history of the code up and down. @philwebb Would it ok for you to: Hand over here an argument like "--lister=suppress" To suppress all listeners including: if (Arrays.asList(args).contains("--lister=suppress")) {
return Collectiosn.emptyList();
} |
It is a bit of pain that |
I think that the new config data api could be used rather than Spring application |
Yes please, @spencergibb. If using the config data API lets you get rid of the context hierarchy, that sounds ideal to me. It would also simplify some other problems we've seen in SCS (IIRC) with the logging system when there's a child app with a different lifecycle to its parent. |
@spencergibb and I talked about this, so it is on my list of things to do, but will admit, low in priority especially with SCSt plans for 4.0. |
@olegz Can you give any release estimations? Or better time ranges? |
Describe the issue
Originally invented @philwebb with: spring-projects/spring-boot#7656
The "readiness" framework, that enables to register "ApplicationRunner" to ensure for example a "cache" is loaded before the application is ready to server.
But when spring cloud stream is used following happend:
@org.springframework.boot.SpringApplication#run(java.lang.String...)
refreshContext(context);
--> ScSt wants to create the binder
--> DefaultBinderFactory starts a new inner SpringApplication
--> It run again: SpringApplication#run(java.lang.String...)
--> callRunners(context, applicationArguments); // will not find any "ApplicationRunner", what is correct
--> listeners.running(context); // called and fire the "ReadinessState.ACCEPT". This is the BUG
--> .... spring cloud stream set up its binders ...
callRunners(context, applicationArguments); // will execute the "ApplicationRunner" that is set up my application cache.
listeners.running(context); // The "ReadinessState.ACCEPT" event gets fired that i expect.
To Reproduce
Steps to reproduce the behavior:
Expected: status: "OUT_OF_SERVICE"
Current state: status: "OK"
Expected: status: "OK"
Current state: status: "OK"
The text was updated successfully, but these errors were encountered: