CDI doesn't provide an event that would correspond to application startup. A commonly used substitute is the @Initialized(ApplicationScoped.class) Object event, but that is fired "when the application context is initialized" (quoting from the spec).
Traditionally, those two situations occur reasonably close in time, but with CDI Lite, we aim to expand the set of possible CDI implementation strategies to include those that initialize a lot of stuff (including the application context) ahead of time. In such case, the @Initialized(ApplicationScoped.class) Object event has no correlation to application startup. It may happen during application startup, or it may happen arbitrary number of hours before.
Hence, I believe CDI should provide an event type that specifically corresponds to application startup. In some ways, it would be nice to restrict it to only be fired after the application fully starts up and everything is initialized, but that has prohibitive runtime costs; even the @Initialized(ApplicationScoped.class) Object event doesn't guarantee that (and firing the new event at the same time as this "old" event should be a valid implementation strategy for "purely runtime" CDI implementations such as Weld). So I propose to add an event type that is fired synchronously during application startup.
As for the name, I originally thought it could be called AfterStartup, because that is symmetric to existing BeforeShutdown, but that reasoning is invalid. BeforeShutdown is a container lifecycle event that is designed for use with Portable Extensions (the spec directly says "observer methods of these events must belong to extensions"). Also, in previous paragraph, I specifically argue we shouldn't restrict the event to "after startup"; it should be "during startup". However, DuringStartup looks ugly.
There's also zero precedent (in CDI) for using naming conventions such as On[Something] or [Something]Event, so I'd like to avoid those. The common event naming strategy in CDI is to just use a descriptive name.
That would, in this case, be simply Startup. However, I'd like to reserve this name for a potential @Startup annotation which would, similarly to EJB's @Startup, force eager initialization of a bean.
Any suggestions? :-)
For symmetry, we may want to declare a corresponding "during shutdown" event. We already have the @BeforeDestroyed(ApplicationScoped.class) Object and @Destroyed(ApplicationScoped.class) Object events, and it's hard to imagine how these event types could be non-portable, so this is certainly not required. As I said, my main reason for adding such event type would be symmetry with the "during startup" event. Maybe also better discoverability (the application context events are, in my experience, not exactly obvious).
CDI doesn't provide an event that would correspond to application startup. A commonly used substitute is the
@Initialized(ApplicationScoped.class) Objectevent, but that is fired "when the application context is initialized" (quoting from the spec).Traditionally, those two situations occur reasonably close in time, but with CDI Lite, we aim to expand the set of possible CDI implementation strategies to include those that initialize a lot of stuff (including the application context) ahead of time. In such case, the
@Initialized(ApplicationScoped.class) Objectevent has no correlation to application startup. It may happen during application startup, or it may happen arbitrary number of hours before.Hence, I believe CDI should provide an event type that specifically corresponds to application startup. In some ways, it would be nice to restrict it to only be fired after the application fully starts up and everything is initialized, but that has prohibitive runtime costs; even the
@Initialized(ApplicationScoped.class) Objectevent doesn't guarantee that (and firing the new event at the same time as this "old" event should be a valid implementation strategy for "purely runtime" CDI implementations such as Weld). So I propose to add an event type that is fired synchronously during application startup.As for the name, I originally thought it could be called
AfterStartup, because that is symmetric to existingBeforeShutdown, but that reasoning is invalid.BeforeShutdownis a container lifecycle event that is designed for use with Portable Extensions (the spec directly says "observer methods of these events must belong to extensions"). Also, in previous paragraph, I specifically argue we shouldn't restrict the event to "after startup"; it should be "during startup". However,DuringStartuplooks ugly.There's also zero precedent (in CDI) for using naming conventions such as
On[Something]or[Something]Event, so I'd like to avoid those. The common event naming strategy in CDI is to just use a descriptive name.That would, in this case, be simply
Startup. However, I'd like to reserve this name for a potential@Startupannotation which would, similarly to EJB's@Startup, force eager initialization of a bean.Any suggestions? :-)
For symmetry, we may want to declare a corresponding "during shutdown" event. We already have the
@BeforeDestroyed(ApplicationScoped.class) Objectand@Destroyed(ApplicationScoped.class) Objectevents, and it's hard to imagine how these event types could be non-portable, so this is certainly not required. As I said, my main reason for adding such event type would be symmetry with the "during startup" event. Maybe also better discoverability (the application context events are, in my experience, not exactly obvious).