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
Prior to issue spring-projects/spring-boot#7656, Spring Cloud Task was able to use the ApplicationReadyEvent to be notified that the ApplicationRunners and CommandLineRunners have been executed. The resolution of that issue breaks Spring Cloud Task in that it moves that event to before the runners have been executed without providing a replacement notification.
The text was updated successfully, but these errors were encountered:
snicoll
changed the title
Boot moving the ApplicationReadyEvent to before the execution of *Runners breaks Spring Cloud Task
Moving the ApplicationReadyEvent to before the execution of *Runners breaks Spring Cloud Task
Jan 3, 2018
Given that an ApplicationRunner can be infinite, using it to determine what a task is seems an abuse to me. Of course, an infinite runner for a Spring Cloud Task app doesn't make any sense at all but ApplicationRunner is a Spring Boot concept and its semantic is wider to what you're using it for. That alone is a reason not to expose it directly.
IMO, it is much better that Spring Cloud Task defines a contract of its own for several reasons:
You get control over the API and you can improve it without relying on the “core” contract in Spring Boot (this issue shows that the semantics do not match)
You get control over the lifecycle and what happens in case of error, etc.
You could wrap an invoker that is an ApplicationRunner behind the scenes and have full control over which task is currently running (in case you have more than one). It's also easier to report what is going on in the logs.
Prior to issue spring-projects/spring-boot#7656, Spring Cloud Task was able to use the
ApplicationReadyEvent
to be notified that theApplicationRunner
s andCommandLineRunner
s have been executed. The resolution of that issue breaks Spring Cloud Task in that it moves that event to before the runners have been executed without providing a replacement notification.The text was updated successfully, but these errors were encountered: