Re: [cdi-dev] CDI profiles (was RE: About parsing beans.xml files in Lit

[Matej Novotny <manovotn@xxxxxxxxxx>]

I think you might be asking two different things here, so let me split that into two questions and try my best to answer.

1) Would CDI Lite extensions be able to run in runtime instead of build time?

To this, I think the answer is yes. 
The goal is to design it so that the whole of CDI can work in build time, but nothing stops you from executing it at runtime if you (as an integrator) chose to.
Although I have to note that this partly defeats the purpose because you lose all the build time benefits.
But hey, you could take your EE server and re-wire the integration to use Lite and boot the whole thing in runtime.

2) Would CDI Lite extensions be able to run within CDI Full?

This was indeed part of the conversation (or even more of them) that we had and there was no conclusion so far.
My personal opinion is that Lite extensions should *not* be able to run in Full environment.
As two main reasons I could list these:

a) You would be hindering existing runtime implementations.
If you check the proposed SPI, you will see that there is a completely different (and reflection-free) metamodel underneath that isn't 1:1.
This metamodel also doesn't allow to carry over its information into runtime as opposed to AnnotatedType and Full extensions. It's phases, while similar, also cannot be 1:1.
Having both models existing simultaneously would present a significant obstacle for implementations trying to house both.
Not only would the runtime implementation performance suffer, because you would basically uselessly generate dual metamodel data, but it also offers lots of space for grey interoperability areas between both extensions.
You would need to invoke certain phases from both and "weave" them together while they can affect each other between their phases - e.g. an AT register by Full extension would still need to appear in Lite extension but as a different metamodel type. The Lite can then still slap an annotation on it, which will then have to be reflected as BeanAttribute in the other extension. And so on...
And that's assuming it would be technically possible which we do not know :)


b) The usability of build-time extensions, while aiming to be equally powerful, won't be so "pretty to use".
Take for instance synthesis phase where you declare synthetic beans - current SPI can easily let you do everything with a configurator and the creation of a bean is a simple callback.
When you move into build time, you cannot do this and you instead need to operate on a much lower level; remember that you are potentially between different JVMs.
Worst case, you would need to declare bytecode for the bean. Best case, we can provide a so-so API with some predefined capabilities and parameter passing, but not as powerful (see the current proposal for details).
The point is - it's not nearly as user friendly becaus eif the env. limitations its designed to meet. Therefore, so I don't see it as a viable replacement.

c) Ok, I have a third semi-point to mention here - I just see no real motivation to do this because Full extensions will inevitably be a user-friendlier and more versatile and variable fit for runtime environments.
They have more fine-grained phases because they are designed to be able to manipulate whole metamodel at runtime while booting CDI container. Whereas in build-time env. you assume to have the whole picture of deployment before you start,
putting you in a completely different position. Furthermore, I haven't yet seen an interested party that would want to combine both (Lite and Full - aka the buildtime and runtime approach) in one actual implementation or platform making this "merge of extensions" vastly theoretical. Tis last point is my just opinionated 0.02$ though :)


Last but not least, I would like to reiterate what Graeme said - the Lite efforts aims to evolve CDI to enable it in wider variety of environments with ideally the capabilities CDI users enjoy today.
However, we do aim to leave existing "Full CDI" working as is - we definitely don't want to break existing users. If they wish to keep running the existing EE CDI, that's perfectly fine and expected.
Hence the talks about profiles and other possible approaches to solving that. I hope that clears up some of the confusion I have seen lately in emails :)

Regards
Matej

----- Original Message -----
> From: "Manfred Riem" <m_riem@xxxxxxxxxxx>
> To: "cdi developer discussions" <cdi-dev@xxxxxxxxxxx>
> Sent: Wednesday, January 27, 2021 5:13:10 PM
> Subject: Re: [cdi-dev] CDI profiles (was RE: About parsing beans.xml files in Lite)
> 
> 
> 
> +1 on answering this question
> 
> 
> 
> 
> From: cdi-dev <cdi-dev-bounces@xxxxxxxxxxx> On Behalf Of Thiago Henrique
> Hupner
> Sent: Wednesday, January 27, 2021 8:47 AM
> To: cdi developer discussions <cdi-dev@xxxxxxxxxxx>
> Subject: Re: [cdi-dev] CDI profiles (was RE: About parsing beans.xml files in
> Lite)
> 
> 
> 
> 
> 
> The build time extensions wouldn't be able to run in runtime if needed?
> 
> _______________________________________________
> cdi-dev mailing list
> cdi-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cdi-dev
>