Move publication of ApplicationReadyEvent back to after runners have been called and provide new event that's published before

[wilkinsona]

#7656 moved the logic that calls any CommandLineRunners and ApplicationRunners to a point after the ApplicationReadyEvent has been fired. This means there's no longer an event that can be used to learn when the runners have been called.

The proposal is to introduce a new event (RunnersCompletedEvent?) that is fired when the runners have been called. We may also want to introduce a second event (RunnersFailedEvent?) that can be fired when one of the runners fails (throws an exception). As things stand an exception from a runner will result in ApplicationFailedEvent being published despite ApplicationReadyEvent already having been published.

[wilkinsona]

I'm currently of the opinion that implementing #7656 was a mistake. That change has created the problem described above, while also meaning that ContextRefreshedEvent and ApplicationReadyEvent are published at, essentially, the same point in the application's lifecycle. The only thing of any real substance that happens between the two is the call to afterRefresh on SpringApplication and that's a no-op by default.

I think we should consider reverting the fix for #7656 and declining this issue.

[wilkinsona]

Actually, rather than completely reverting the fix for #7656, we could continue logging the application started message before calling the runners.

[snicoll]

That's what I was about to write. This looks good to me.

[wilkinsona]

The advantage of a SpringApplicationEvent is that it provides access to SpringApplication. ContextRefreshedEvent does not do so. We're considering introducing an ApplicationStartedEvent that would be published once the context is refreshed but before the runners have been called. ApplicationReadyEvent (possibly renamed to ApplicationRunningEvent) would then be published once the runners have been called and immediately prior to returning from run().