> 1. Is there a portable way to run some code during application startup? The
> `@Initialized(ApplicationScoped.class) Object` event is fired during
> container initialization, which can be during application build, so that's
> not it. I propose CDI standardizes an `AfterStartup` event (symmetrically to
> existing `BeforeShutdown`), which is guaranteed to be fired during
> application startup. I personally find `AfterStartup` and `BeforeShutdown` a
> lot more natural than `@Initialized(ApplicationScoped.class) Object` and
> `@Destroyed(ApplicationScoped.class) Object`. (Though to be perfectly
> honest, `BeforeShutdown` seems misnamed and, since all CDI contexts are
> invalid at that point in time, also quite useless.)
I am totally +1 for `AfterStartup` as a marker of "application started" milestone because what you say with `@Initialized` is a problem in build env.
However, it cannot be symmetrical to `BeforeShutdown` because that is a lifecycle event that you can observe in extensions and `AfterStartup` should instead be a standard CDI event that you can observe from within any CDI bean.
I am pretty sure that's what you meant, I just wanted to make it clear :)
Correct. Sorry, I didn't realize `BeforeShutdown` is a lifecycle event when writing this.
I personally find the `@Initialized(ApplicationScoped.class) Object` and `@[Before]Destroyed(ApplicationScoped.class) Object` events very non-obvious and unfriendly. And, with build-time wiring we're trying to enable, also non-portable (at least the `@Initialized` part; the `@[Before]Destroyed` part should be OK portability-wise).
I'd really like to have regular CDI events that applications can observe for "just started" and "about to shut down". Too bad that the `BeforeShutdown` name is already taken, because `AfterStartup`/`BeforeShutdown` are really good descriptive names. We should be able to come up with another pair of names though. Worst case, we can go with `StartupEvent`/`ShutdownEvent` (like Quarkus does), or `AfterApplicationStartup`/`BeforeApplicationShutdown`, or `OnStartup`/`OnShutdown`.
(This also ties into the "define EJB as a set of CDI stereotypes" idea. I'd very much like to have something like EJB's `@Startup` in CDI proper.)
> 2. The in-extension part of initialization code (complemented by synthetic
> beans, as described above) often needs to know the full set of beans in the
> application. The `AppDeployment` API provides access to that, but there's
> currently nothing in the API that would let you know "all beans have been
> processed". Even though the API is push-based, both implementations I
> currently have (in Quarkus and on top of Portable Extensions) are actually
> synchronous, so I was able to make it work, but there's clearly something
> missing. At this point, I'm thinking we'll probably have to add something
> similar to Portable Extensions `ProcessBean` and `ProcessObserver`. That
> would be before the `@Synthesis` phase, and `@Synthesis` would then serve as
> the "all beans have been processed" point. I really wanted to avoid this,
> but it seems inevitable. Another option is to add a "all done" callback to
> the `AppDeployment` API.
>
This is.... puzzling :-D
I more or less get what you're trying to do but I think it would be nice to hear from Micronaut folks whether or not this is blocking and if we aren't missing something.
Yea this is totally non-obvious. I guess I didn't help it when designing the API the way it is designed (with programmatically registering callbacks in a method that is also supposed to contain code that runs after all those callbacks finish).
I'll try to figure something out for the CDI call next week and we can talk about it.
LT
