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

[Matej Novotny <manovotn@xxxxxxxxxx>]

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
>