Re: [cdi-dev] This is StillDI

[Ladislav Thon <lthon@xxxxxxxxxx>]

On Tue, Mar 9, 2021 at 5:35 PM Andrew Rouse <ANROUSE@xxxxxxxxxx> wrote:

----- Original message -----
From: Matej Novotny <manovotn@xxxxxxxxxx>

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.

[1] https://urldefense.proofpoint.com/v2/url?u=https-3A__jakarta.ee_specifications_cdi_2.0_cdi-2Dspec-2D2.0.html-23application-5Fcontext&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=3azP-pEWesGfIewc5ARf-1qgBUmuZ6aE_FWKXZm3Was&m=yotqiM1A5oaA37tMzhKLuOUl-CxbzrYg1QnLCgcSnqo&s=QGRmvSsKVvJDeKFhkyUJvlFR_0uhmu4RRf-yYlMgxeE&e=

Thanks for your answers. I think the part I don't understand (which LT mentioned as well) is why the application context should be active at build time. I'd assumed that at build time you could be processing the beans in the application and synthesizing the classes needed to support them, but I hadn't imagined that you'd create any bean instances or that any contexts would be active.

 

I'm not sure whether I'm missing something fundamental about the requirements for the application context, or whether you're suggesting that users would be able to do much more at build time than I'd understood.

Thanks for pushing this question -- I've been taking some things for granted for so long I didn't realize it isn't obvious to everyone else as well :-) The answer is a little more complex, though, as the motivation is native image compilation.

So, there are 2 "builds" at play when we talk about native image compilation: first, we compile Java source code (producing bytecode), and second, we compile bytecode (producing a native binary). During source code compilation [1], we run bean discovery (including extensions). But during native image compilation, thanks to native image's capacity to snapshot the Java heap, we can actually execute some initialization code [2]. This is when we boot the CDI container, create the application context and fire the `@Initialized(ApplicationScoped.class) Object` event.

[1] Actually during subsequent bytecode manipulation in our (Quarkus) case, but the Micronaut folks actually do it during source code compilation, as they use annotation processors.

[2] Specifically, we can run static initializers. See also https://www.graalvm.org/reference-manual/native-image/ClassInitialization/.

I think this should be an implementation detail, and I think it's a valid implementation strategy. But it also means that application context initialization no longer coincides with application startup.

Makes sense?

Thanks,

LT