Re: [cdi-dev] CDI future - problems and proposal

[Matej Novotny <manovotn@xxxxxxxxxx>]

Hi,
comments inline.

----- Original Message -----
> From: "Tomas Langer" <tomas.langer@xxxxxxxxxx>
> To: "cdi developer discussions" <cdi-dev@xxxxxxxxxxx>
> Sent: Wednesday, October 21, 2020 5:17:21 PM
> Subject: Re: [cdi-dev] CDI future - problems and proposal
> 
> Hello,
> I will try to address the comments from previous e-mails:
> 
> From Arjan Tijms:
> - Interceptors on programmatically created beans - I understand there should
> be a way to get appropriate decorated instance, that would apply all
> interceptors when methods are invoked on the returned instance; I think this
> must be handled with care with regard to the new features we discuss, as a
> bean computed at build time would already know about all its interceptors.
> Bean.create in such a case returns an already decorated instance. Why cannot
> this be done using extension to add an interceptor binding to the bean
> before it is set up?
> - Access to injection point in Bean#create() - Do you envision what change in
> API would be useful here? What is the needed (additional) metadata you want
> to obtain from the injection point? I guess some sort of “synthetic”
> injection point could be created when requesting this programmatically. Or
> we could add support for parameters to @Produces methods, that could be
> explicitly defined when invoking this...
> 
> From Matej Novotny:
> - Bean Metadata - there is a need for build-time processing API, but the
> runtime model I think should be built into the existing model in CDI to make
> it capable of reflection free handling, with the reflected methods being
> deprecated. If two models are really needed, we can work on your PR to come
> up with a model good for both annotation processing and byte code
> processing. We could have a `jakarta.cdi.lite` model for build time
> annotation metadata, and have the current CDI meta model extend it to add
> the reflection methods (that may be used in EE or existing extension and
> beans).

The current model is unfit for build-time, reflection-free approach though.
And even if you somehow combine them (which I was thinking about as well), then you end up creating lots of additional metadata that has to exist even at runtime just for the sake of it.
What I mean is that neither Lite nor Full will need or want to consume both metamodels.
Well, technically you could have the new metamodel used in full instead of the previous one assuming Lite extension would work in both environments.
But that's inconvenient because some parts of Lite are going to be way more complex compared to current runtime solutions; for instance synthetic component declaration.

> - Extensibility - agreed, the extensibility model should be designed in
> cooperation, to make sure it works for either build time approach; I will
> add the link to the document. Luckily there are not three parties, we have
> written the document with Graeme, so we should be on the same page here

Noticed that; I didn't mean competing parties but rather three projects looking to achieve similar goal ;-)

> - beans.xml - see below, this one is a bit longer; can you please explain how
> you approach this for build time and runtime in your proposal? Maybe I am
> missing some use case that requires a different approach

Not sure I follow the question. By preserving beans.xml, you can use it as a marker file for Lite and as additional config file for "full".
Nowadays, you can put lots of options in beans.xml, even different discovery modes.
So you kill two flies with one XML file that you don't even need to parse in Lite :)

> - reduction of scope - this is a complicated topic, I can see problems
> starting with jakarta.inject (Provider should be deprecated and extend
> Supplier, and Supplier used instead, maybe consider adding NonBinding as it
> belongs to Qualifier, and I would consider some additional scopes as they
> make sense in general, such as Dependent and RequestScope), and
> jakarta.annotation-api (I have doubts about the security, sql package,
> ManagedBean class, Resource class - seems like a mixture of classes that are
> from different areas, not all of them have meaning in SE; we should also add
> Nullable and Nonnul annotations), there are some areas in interceptor API
> that may be improved, and of course the areas in the CDI spec itself. The
> question here is whether these should be dropped from the specification
> (e.g. deprecated and eventually removed), or just not part of a profile, or
> a combination of both

Note that not all annotations from linked specification (such as jakarta.annotation-api) are necessarily used by CDI today.
Lite can keep using a subset it needs. I am not sure CDI is the sole consumer of those specification so we won't have the right to say what's to be deprecated and what isn't.

> - Extensibility #2:
> - “Lite” would only implement build-time
> - SE and EE would support existing portable extension
> - I think we should aim at providing a capability to “transform” output of a
> build-time extension into a portable extension; this would not work for
> synthetic beans created at runtime and for beans added by other portable
> extensions (as the build time extension would not know about them). I think
> we should go through a few use cases to see if this would be useful at all,
> or would just bring confusion
> - My concern - if we create “Lite” with build time extension (only), and “SE”
> and “EE” with portable extensions (only), we would end up with two sets of
> extensions for each feature (such as a “OpenTracingLite” and
> “OpenTracingExtension”) - this may be a good solution, I am myself not sure
> about it

Fair enough. Peronally, I've had similar thoughts and ended up thinking it might be smarter to separate them and force usage of one or another but never both.
Mainly because I was failing to see how to properly intertwine the two without making it confusing or even undefined. Which is to say, I might have missed something :)
Also, there is usually but a few extensions in each application; it's not like they come in hundreds.
Having it separate would also allow two metamodels without the burden or putting them together. 

> 
> Beans.xml and bean discovery:
> You (Matej) consider class path scanning is needed at build time, we were

To make myself clear - we aren't using classic CP scanning. We're using Jandex.
So what we do is query Jandex for classes with bean defining annotations and so on...
But the presence/absence of beans.xml file dictates whether you add/leave out given archive from Jandex index.
This gives you the freedom to determine which archive is or isn't containing CDI bits.

> thinking about class path scanning free approach. Each archive that is a
> bean archive should have appropriate “META-INF/services” with a service that
> provides the list of beans in that archive. If done this way, there is no
> need for beans.xml. This of course implies that each bean archive is
> compiled with build-time processing. We could have a component, that would
> add such metadata on existing bean archives (yet I think this can be vendor
> specific).

I see. It seems pretty inconvenient to have to declare a complete list of beans for each JAR, especially if you are actively developing such an application - you'll need to constantly curate that list of String.
As far as I understood it, annotation processor could also base processing of beans on presence of given annotation (which would be bean defining annotation). What's the issue with that?

> 
> How would this work?
> - build time of a bean archive: the processor (annotation or byte code)
> generates a META-INF/service/jakarta.cdi.lite.BeanDefinitionProvider with a
> list of (generated) implementations for each bean in the archive
> - build time of my application: we process the current application source (or
> byte code) to create the service list (either via annotation processing or
> byte code scanning)
> - run time: we read all the BeanDefinitionProvider instances and create our
> bean landscape from them (the bean landscape is almost fully pre-computed,
> may be using some conditions to limit the list of beans being loaded)
> - in case we want to “enhance” a bean archive that is not our application
> (such as adding an interceptor to an existing bean), we would use a concept
> of “bean import”, with a configurable way to mark classes to be re-computed
> and provide an alternative with higher priority than the original bean
> 
> 
> 
> Thanks a lot on your comments, let’s continue this conversation!
> 
> Tomas
> 
> 
> 
> 
> 
> 
> -------- Original message --------
> From: Matej Novotny < manovotn@xxxxxxxxxx >
> Date: 10/20/20 5:43 AM (GMT-05:00)
> To: cdi developer discussions < cdi-dev@xxxxxxxxxxx >
> Subject: Re: [cdi-dev] CDI future - problems and proposal
> 
> Hello,
> 
> this is a good read o why we need Lite! It echoes a lot of ideas that were
> already said in various discussions/blogs/... and adds more to it.
> It sounds like we are on the same page with the Lite effort that would
> support AOT approach within specification.
> 
> Here are few notes so that we can avoid duplicating efforts:
> 
> * Bean Metadata
> You describe the need to come up with new, reflection free view of metadata
> that we could use.
> This is something that we already included in the draft of extension SPI
> because we came to a similar conclusion; see this[1] link for the model.
> I think we should note it there and point to the PR/issue so that we improve
> that instead of creating duplicities. We are of course open to suggestions
> if you see the model unfit.
> 
> * Extensibility
> The shape of the extension interface that you came up with is a lot like
> phases[2] we drafted in the extension SPI PR.
> We are now working to incorporate Graeme's suggestions[3] into it so that
> it's annotation processor compatible so it will change one way or another.
> However, I suggest you link it in the document and we should make it a joint
> effort - it looks like there are now three various parties willing to make a
> dedicates Lite extension SPI.
> So let's try and draft one SPI that works for us all.
> 
> Other notes:
> 
> * beans.xml handling
> You made beans.xml optional - how do you intend to discover beans and how do
> you know in which of the dependencies (JARs), do they reside?
> I'd say it's way more practical to instead have beans.xml as a marker file
> (== ignoring its contents) denoting that a given archive is to be searched
> for beans.
> That way you can further optimize which archives are to be left alone and
> which are to be taken into account.
> Though maybe I am just misunderstanding how you intend to perform discovery,
> could you please elaborate?
> 
> * Reduction of scope
> Do you also see some other parts of CDI going away? I can imagine some
> not-so-used things such as specialization being a good candidate to drop.
> And there is probably more...
> 
> * Extensibility
> You stated that Lite implements only the new variant of extensions (whichever
> that will be) and that there is an optional module for runtime extensions to
> add.
> So, how would this optionality work in practice? E.g. would there have to be
> an impl doing it all? Because I don't think either side would want to
> consume that implementation.
> AOT approaches would want Lite OFC, but EE servers will require the runtime
> impl anyway.
> And if there is such impl, it would have to have dual bean metadata -
> existing model + new one that we both talked about.
> That can lead to a whole lot of undefined behaviour based on which extension
> changes what metadata and when.
> Not to mention that performing build time extension first means you alter
> metadata, create synth beans and perform validation. And being at build
> time, you could even create proxies at this point.
> Running standard ("full") extensions after all that doesn't make much sense
> as you would have to re-do the whole thing... unless I am missing something.
> I don't have an answer to this situation myself, but when I was pondering
> this over, I didn't see much use in supporting both simultaneously.
> Can you please elaborate on how do you see the co-existence of both working?
> 
> These are just few things from the top of my head. I may come up with more
> later on.
> 
> Regards
> Matej
> 
> ________________________________________________________________________________________________________________
> [1]
> https://github.com/Ladicek/cdi-spec/tree/cdi-lite-extension/api/src/main/java/cdi/lite/extension/model
> [2]
> https://github.com/Ladicek/cdi-spec/tree/cdi-lite-extension/api/src/main/java/cdi/lite/extension/phases
> [3] https://github.com/Ladicek/quarkus-fork/pull/7
> 
> 
> 
> ----- Original Message -----
> > From: "Tomas Langer" < tomas.langer@xxxxxxxxxx >
> > To: cdi-dev@xxxxxxxxxxx
> > Sent: Thursday, October 15, 2020 4:47:58 PM
> > Subject: [cdi-dev] CDI future - problems and proposal
> > 
> > Hello,
> > 
> > After seeing the turmoil related to CDI Lite and the new extension model
> > for
> > CDI, we have made an attempt to summarize the problems we see with CDI
> > specification as it is now, and the possible path forward.
> > 
> > Please see the document:
> > https://docs.google.com/document/d/1Z_7EVD-TY13lAuSM7V7PcrcsuaHz-NgAgTUoumHtmOM/edit?usp=sharing
> > 
> > This document is not final, it's a draft. I am inviting the whole CDI
> > community to read it and provide feedback by replying to this email thread
> > or placing a comment in the document directly. Based on this feedback I'll
> > modify the document and I hope step by step will come to the consensus in
> > the design.
> > 
> > I have tried to preemptively answer some of the common questions, such as
> > “can we handle this with existing portable extension”, and “why should this
> > be in CDI, shouldn’t this be a separate specification”.
> > 
> > With best regards,
> > Tomas Langer
> > Helidon Architect
> > Oracle
> > 
> > 
> > 
> > _______________________________________________
> > 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://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/cdi-dev__;!!GqivPVa7Brio!PWyXMs6hx9gDGqJHfRADm95qxgq9V2mfxfYzmazm1HizCfgUE1vOL3XmX7GZ320v_A$
> 
> 
> _______________________________________________
> cdi-dev mailing list
> cdi-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cdi-dev
>