Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdi-dev] This is StillDI

On Tue, Mar 9, 2021 at 1:23 PM Matej Novotny <manovotn@xxxxxxxxxx> wrote:
Side note - I think we should avoid adding into spec any notion of something being executed at runtime or at build time.

Agree. I'd specify it in terms of "application startup", which may look loose, but is in fact exactly what users care about. It is up to the implementor to define what exactly that means -- for fully runtime implementations, a hypothetical `AfterApplicationStartup` event may be an alias to `@Initialized(ApplicationScoped.class) Object` event.

LT
 
It could be pretty limiting to future implementations.

As to your question - you cannot really do that for two reasons:
1) The event is basically overloaded and you can have people who take it as "app started" and people who actually use it to detect the scope activation and want to perform some logic (regardless of whether it's in build or runtime)
 - the latter group can still fully leverage the event in build time
2) By moving the event to runtime you'd violate the specification that requires to fire this event when the context is initialized[1] - and you're leveraging build time approach to initialize it even before running the app.

Matej
________________________________________________________________________
[1] https://jakarta.ee/specifications/cdi/2.0/cdi-spec-2.0.html#application_context


----- Original Message -----
> From: "Andrew Rouse" <ANROUSE@xxxxxxxxxx>
> To: cdi-dev@xxxxxxxxxxx
> Sent: Tuesday, March 9, 2021 1:06:17 PM
> Subject: Re: [cdi-dev] This is StillDI
>
>
>
> From: Ladislav Thon <lthon@xxxxxxxxxx>
> 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.)
> This is easy to implement in a fully runtime environment, so I took the
> liberty of adding that to StillDI, even though it isn't part of the
> extension API.
> Is there some reason that the `@Initialized(ApplicationScoped.class) Object`
> event has to run at build time? Could it just be specified that it happens
> at runtime?
> Currently I think this is the only way to ensure that something runs at
> startup with CDI so it would be a shame to break things that rely on that.
> Regards,
> Andrew
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cdi-dev
>

_______________________________________________
cdi-dev mailing list
cdi-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdi-dev


Back to the top