Skip to content

add a portable event corresponding to application startup #496

@Ladicek

Description

@Ladicek

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).

Metadata

Metadata

Assignees

Labels

spec-featureAn issue requesting an addition specification

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions