| Re: [cdi-dev] This is StillDI |
It's CDI Lite still :-)
A temporary name (and a play on "Still CDI"?) for the repository which demonstrates that CDI Lite extensions can be implemented in full via an aggregation in runtime extension (effectively proving it is a subset in this regard).
It also shows the API of the currently proposed Lite extensions and let's you play with it.
Matej
----- Original Message -----
> From: "Werner Keil" <werner.keil@xxxxxxx>
> To: "cdi developer discussions" <cdi-dev@xxxxxxxxxxx>
> Sent: Tuesday, March 9, 2021 2:00:26 PM
> Subject: Re: [cdi-dev] This is StillDI
>
>
>
> What’s this whole „StillDI“ thing, a true subset and module inside the „Full
> CDI“ or something else that is neither part of nor compatible with CDI?
>
>
>
> Werner
>
>
>
> Gesendet von Mail für Windows 10
>
>
>
>
> Von: Ladislav Thon
> Gesendet: Dienstag, 9. März 2021 13:36
> An: cdi developer discussions
> Betreff: 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
>
>
>
> _______________________________________________
> 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