Re: [cdi-dev] CDI Lite compatible extension lead

[Matej Novotny <manovotn@xxxxxxxxxx>]

Coming back from a PTO, there is tons of questions and messages so I will try my best to answer it although I might miss a things or two...

Firstly, I am sorry people felt like this wasn't discussed. The idea is to do just that - bring up the Lite topic again and discuss it right now.
We just didn't want to do that empty handed, so we came with a draft that we hoped would stir discussion and editing. 
I understand that the draft isn't exactly small but that goes hand in hand with CDI extensions not being a tiny matter either.
That being said, I wouldn't expect people to provide technical feedback on it within five minutes of opening the issue anyway.

Emily,

the proposal came with quick impl on Quarkus side exactly for that reason - so you can play with the API and see how to add beans or veto them and so forth.
>From Ladislav's fork, there are at least two showcases of the API in action, firstly there is ChangeQualifierTest[1] and secondly there is a Lite extension which overrides the original integration of MP FT into Quarkus which is here[2].
None of them are all too detailed and they focus on annotation transformation because that is, as already stated, the most elaborate part of the draft at the moment.
Especially the test[1] is a good place where you can easily play with other parts on API and explore it.

Now for the three scenarios you picked...
Vetoing beans can be done by existing annotation transformation - simply put @Vetoed to the class/producer that you want to veto.
For adding beans - this can mean several things. If you are talking about registering classes that are to be considered beans, you can look into the Discovery phase[3] in the draft.
If it is synthetic components, than that is the TODO part in the Synthesis[4] phase which we have yet to figure out because that's non-trivial in (possibly) build-time environment.
Lastly, interceptors - you can add them similarly as other beans, in the Discovery[3] phase. Basically the same thing as in current extensions where you'd add register a class as an annotated type and that class can be either bean class or it might as well be an interceptor. If it's juggling with with bindings that you referred to, then that circles back to annotation transformation.


Mark,

I agree that CDI extensions are one of the key points letting integrators hook into CDI lifecycle and add their own bits.
The recognition of importance of extensions is one of the reasons this draft exists. If there is to be CDI Lite, there should also be a proper extension API that will cover the range of use cases extensions have now (or all those we agree on) and will at the same time be build-time friendly.
So I am sorry but I don't quite see the point of your comment that it is no longer CDI - it actually tries to preserve the essence of CDI and carry that capability over to Lite landscape.


Lastly, I have also noticed repeated questions about capabilities of Lite extensions.
Personally I think that it should cover most of the cases current extensions allow you to do. 
I do say "most" on purpose because with the distinct metamodel[5] it brings, some things are done differently so that capability will be missing. However, the use case it covered should still be doable - for instance you were adding a bean via registration of new AnnotatedType. Well, you are still able to add a new bean now, you will just do it differently.
Let me re-phrase again that the draft is not complete, so if you do not see support for something, we probably just didn't figure it's missing yet or didn't have time to draft it.
Suggestions and contribution in that direction are of course most welcome :)

Hope this answers at least some of the questions
Matej
________________________________________________________________________________________________________
[1] https://github.com/Ladicek/quarkus-fork/blob/experiment-cdi-lite-ext/independent-projects/arc/tests/src/test/java/io/quarkus/arc/test/cdi/lite/ext/ChangeQualifierTest.java
[2] https://github.com/Ladicek/quarkus-fork/blob/experiment-cdi-lite-ext/extensions/smallrye-fault-tolerance/runtime/src/main/java/io/quarkus/smallrye/faulttolerance/runtime/SmallRyeFaultToleranceCdiLiteExtension.java
[3] https://github.com/Ladicek/quarkus-fork/blob/experiment-cdi-lite-ext/independent-projects/arc/cdi-lite-ext-api/src/main/java/cdi/lite/extension/phases/Discovery.java
[4] https://github.com/Ladicek/quarkus-fork/blob/experiment-cdi-lite-ext/independent-projects/arc/cdi-lite-ext-api/src/main/java/cdi/lite/extension/phases/Synthesis.java
[5] https://github.com/Ladicek/quarkus-fork/tree/experiment-cdi-lite-ext/independent-projects/arc/cdi-lite-ext-api/src/main/java/cdi/lite/extension/model


----- Original Message -----
> From: "Mark Struberg" <struberg@xxxxxxxxxx>
> To: "cdi developer discussions" <cdi-dev@xxxxxxxxxxx>
> Sent: Tuesday, September 22, 2020 8:02:31 PM
> Subject: Re: [cdi-dev] CDI Lite compatible extension lead
> 
> 
> Just quickly read over the proposal and it seems to me like an entirely
> different DI container approach. It's probably not CDI anymore.
> The Extension mechanism used to be a big part of the success of CDI. Just
> look at Microprofile. Without CDI Extensions we would not have been able to
> plug into that many EE areas so seamlessly. If we remove that many dynamics
> then we are functionally back to Avalon DI from 99.
> But I'm happy to let you explain it to me again. Most likely I've missed some
> important parts.
> 
> LieGrue,
> strub
> 
> 
> 
> 
> 
> Am 21.09.2020 um 19:13 schrieb Emily Jiang < emijiang6@xxxxxxxxxxxxxx >:
> 
> LT,
> There are so many APIs to look at. Furth to Reza's questions, do you have a
> test app to demonstrate how to create a build time extension with the api
> you proposed such as add beans, interceptors, veto beans etc? It will help
> others to understand better if you can demonstrate the usages.
> 
> Thanks
> Emily
> 
> 
> On Mon, Sep 21, 2020 at 3:27 PM reza_rahman < reza_rahman@xxxxxxxxx > wrote:
> 
> 
> 
> Personally I think we should move forward on the technical aspects of this
> conversation. I certainly would like some clarity on how this is going to
> look like for CDI extension writers. Are they now going to need to write two
> extensions? One extension with complicated conditional blocks? Are native
> compiled extensions significantly less feature rich? Do we need two things
> that basically do the same thing? Even amongst vendors targeting native
> compilation, is there sufficient consensus yet?
> 
> Reza Rahman
> Jakarta EE Ambassador, Author, Blogger, Speaker
> 
> Please note views expressed here are my own as an individual community member
> and do not reflect the views of my employer.
> 
> P.S.: Whatever we do, it is a bit difficult to track the conversation in two
> different places. My impression is that more people keep track of the
> mailing list. Personally I find email a bit easier to manage/keep track
> of/respond to.
> 
> Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
> 
> 
> -------- Original message --------
> From: Ladislav Thon < lthon@xxxxxxxxxx >
> Date: 9/21/20 7:41 AM (GMT-05:00)
> To: cdi-dev@xxxxxxxxxxx
> Subject: Re: [cdi-dev] CDI Lite compatible extension lead
> 
> 
> 
> Hello,
> 
> I'm a newbie on this list, but I'm just an ordinary man, nothing special,
> nothing grand, so please allow me to skip the introduction and get to the
> point :-)
> 
> I have authored the PR [1] and the blog post about it [2], so I feel kinda
> responsible for what happened. Communication is hard, especially for
> introverted people like me, so let me try to set things straight. I'll
> probably just repeat what Matej already said, but ... well, I need to start
> somewhere.
> 
> The desire for a "lite" variant of CDI was expressed by multiple people, on
> various places, starting a long time ago. During various discussions (at
> least those that I've seen), one point occured repeatably: whatever CDI Lite
> has or not, it needs to have an extension mechanism. In other words,
> Portable Extensions are immensely popular and people don't want to lose
> them. Totally understandable. At the same time, it seems rather obvious to
> me that Portable Extensions can't be used, because they are inherently
> runtime and heavily based on Java Reflection API, while CDI Lite should be
> implementable [= possible to implement, not constrained to] at build time.
> (This has also been stated many times by many people way before I got
> involved.)
> 
> Some people at Red Hat started thinking about how a new extension API,
> amenable to build time processing, could look like, and I got involved too.
> That's the "we" (and I should probably submit a PR to the blog post to
> clarify this). We use the name "Build Compatible Extension" for now, to
> distinguish from Portable Extensions.
> 
> Now, if I understand correctly, you're all caught by surprise that what we've
> published last week seems very complete, and looks like we're just throwing
> it over the wall. That itself catches me by surprise, because it really is
> not. If you look into the API, there's many TODOs big and small, and it is
> more of a "vertical slice". That is, only one part of it (the annotation
> transformation API, aka @Enhancement) has been developed more thoroughly,
> the other parts went through just a short debate and were only included to
> show that we realize there's more to it than just annotation transformation.
> 
> What I mean is -- we published a sketch. We also said that everything is up
> for debate. I don't know of a better way to start a discussion than to
> publish a concrete proposal. I'm a simple man, I find it easier to build
> abstract ideas from concrete things, and I don't believe in API design
> without implementation (that's why I built a POC, too).
> 
> When I hear that this wasn't discussed, I'm getting confused. Noone started
> any kind of a discussion (that I know of -- I got involved fairly recently).
> This is what we're trying to do -- bring up some concrete ideas so that the
> discussion can start. Anyone and everyone should feel free to publish
> alternative proposals, including ideas how to make Portable Extensions
> build-time-friendly, etc. etc.
> 
> 
> When I hear that this wasn't discussesd, I'm also starting to feel guilty. It
> feels like I violated some universal code that I wasn't aware of. For that,
> I apologize.
> 
> LT
> 
> P.S.: when it comes to discussion medium, I really think GitHub issues would
> be more appropriate, and they integrate with e-mail rather seamlessly, but I
> don't mind using a mailing list either.
> 
> 
> [1] https://github.com/eclipse-ee4j/cdi/pull/451
> 
> [2] http://www.cdi-spec.org/news/2020/09/15/CDI_Lite_extension/
> On 21. 09. 20 11:53, Emily Jiang wrote:
> 
> 
> 
> To be honest, I had the same feeling as Laird and Reza and I commented on the
> PR with confusion. I think maybe some of you involved in the project head
> down and made progress, but the others were not aware of this and did not
> feel they were engaged.
> 
> For future development, can we settle down on the following?
> 1. Use jakarta-cdi to raise issues and discuss issues - list the end user
> story, problems, etc. Blog is for something else. I think wherever we want
> to make changes, we should raise an issue and discuss first.
> I saw Matej raised the issue after the PR. I think it should be the other way
> around. In this case, we can collaborate on the design and we agree with the
> rough design. Then comes PR, so people can review on the details and less
> time-wasting. At the moment, a lot of comments on the PR is about what the
> design should look like.
> 
> 2. As for cdi-spec repo, I don't see why we still need this. Can we merge
> this into jakarta-cdi repo so that we have one central place to collaborate
> with?
> 
> 3. If needed, e.g. a lot of confusion and disagreement on the issue, we
> should call out an one-off hangout to discuss. Even in JCP time, we have
> regular communications so that people are aware of what we are working on.
> 
> Thoughts?
> 
> Thanks
> Emily
> 
> On Sun, Sep 20, 2020 at 9:01 PM Scott Stark < starksm64@xxxxxxxxx > wrote:
> 
> 
> 
> I don't see how this could be taken as close to final in any way when the
> opening post is saying this is the start of a discussion regarding a
> proposed set of apis. There are github issues and a previous blog
> introducing the topic months ago. The only issue I see is lack of
> integrating the blog and github issues with this dev list. The dev list
> should at least have a link anytime an issue or blog is created.
> 
> Again, this is just the start of a discussion to see if there even is common
> ground on which to build a native approach.
> 
> 
> 
> On Sun, Sep 20, 2020 at 2:45 PM reza_rahman < reza_rahman@xxxxxxxxx > wrote:
> 
> 
> 
> To be honest, I also was taken a little by surprise as to how "final" and
> "sudden" the proposal felt. In the future, maybe a better approach would be
> to inform folks here that a concrete and detailed proposal is being worked
> on?
> 
> Now, moving back to the more technical and forward looking aspects. What is
> the thought as to whether this proposal should replace the older portable
> extensions API altogether? How much capability would be lost? The reason I
> mention this is because there is some intrinsic value to be able to write
> CDI extensions using one uniform API that works everywhere.
> 
> Also, I hope all the vendors can agree on an approach that is right for
> native compilation. In fact the ideal case for me would be if as a result of
> this work, CDI adoption by frameworks could be broadened overall beyond just
> one additional runtime (e.g. Quarkus). Has some assessments of these factors
> been made as part of this proposal or do we need to do that here, as part of
> this discussion?
> 
> Reza Rahman
> Jakarta EE Ambassador, Author, Blogger, Speaker
> 
> Please note views expressed here are my own as an individual community member
> and do not reflect the views of my employer.
> 
> Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
> 
> 
> -------- Original message --------
> From: Matej Novotny < manovotn@xxxxxxxxxx >
> Date: 9/18/20 2:33 AM (GMT-05:00)
> To: cdi developer discussions < cdi-dev@xxxxxxxxxxx >
> Subject: Re: [cdi-dev] CDI Lite compatible extension lead
> 
> Hi Laird,
> 
> you didn't miss any communication.
> There were discussions about CDI Lite on CDI repo, in MP circles and there
> was also the blog by Antoine some time ago[1] which I think was reposted to
> this list as well (would have to dig that up).
> From those discussions, extensions were a pain point because Lite was
> supposed to be build time friendly and current extensions are anything but.
> 
> The proposal you seeing now is by far not anything we want to push into
> specification. It is a suggestion but instead of talking abstract designs,
> we wanted to try and come with something concrete.
> It only tries to address Lite extensions - it doesn't solve the issue what
> Lite is and isn't. You can think of it as "if there was Lite spec, what
> would the extension API look like?".
> 
> To set the record straight, the website with blogpost (
> http://www.cdi-spec.org ) is under previous CDI org on GH[2], not sure about
> who can post there.
> It was used mainly because we needed a public place to put a rather big
> article with pieces of code samples - unfit for GH issue and even worse for
> emails if you ask me.
> In order to make it properly public within jakarta cdi community, we then
> created a linking issue, PR and sent an email. All of this was published
> within a short time frame (with the PR coming earlier due to sync issues).
> 
> As for "we" references in the article - it definitely isn't speaking for
> whole committee! That would be daring, silly and rude; we don't mean to
> speak for anyone else ;-)
> The references you are worried about (which I am not sure what they are) are
> likely referring to the group of people who tried to draft this API.
> 
> Now, circling back onto goals and motivation...
> Like I stated above, this proposal isn't defining whole CDI Lite. It focuses
> on just the Lite extension APIs and seeing what those should look like in a
> version of CDI that is build-time friendly.
> The motivation for Lite as such was mentioned throughout various previous
> discussions and posts and varies based on who is discussing that, but I dare
> generalize (so I am sure someone won't agree) that the idea was usage in
> microservices, cloud and build-time environment.
> 
> With the amount of questions you had, there is a chance I missed some, so
> please do ask again if you feel anything is unclear :)
> 
> Regards
> Matej
> 
> _____________________________________________________________________________
> [1] http://www.cdi-spec.org/news/2020/03/09/CDI_for_the_future/
> [2] https://github.com/cdi-spec/cdi-spec.org
> 
> ----- Original Message -----
> > From: "Laird Nelson" < ljnelson@xxxxxxxxx >
> > To: "cdi developer discussions" < cdi-dev@xxxxxxxxxxx >
> > Sent: Friday, September 18, 2020 1:38:35 AM
> > Subject: Re: [cdi-dev] CDI Lite compatible extension lead
> > 
> > On Thu, Sep 17, 2020 at 4:18 PM Scott Stark < starksm64@xxxxxxxxx > wrote:
> > 
> > 
> > 
> > This is a precursor to getting into a spec, so the work has been to extract
> > an api from a build time implementation into something to begin discussions
> > regarding how it might be standardized across implementation. From the blog
> > by Antoine:
> > http://www.cdi-spec.org/news/2020/09/15/CDI_Lite_extension/
> > 
> > (By Ladoslav, I guess; just want to give credit where credit is due.
> > Another
> > question I had is: what's the relationship of that website to this list?
> > Who
> > can post there?)
> > 
> > Is the "we" in that blog article this spec committee (and I missed it)? Or
> > is
> > it Red Hat, or some larger Jakarta EE group, or…? I just want to make sure
> > I'm caught up and not missing messages/activity somewhere else.
> > 
> > May I assume that the goals and use cases that motivated this overall
> > effort
> > are in that blog post? Or are they also laid out somewhere else? Should we
> > spell them out explicitly on this list for long-term posterity? Or In
> > Github
> > Issues We Trust?
> > 
> > Thanks for bearing with my questions.
> > 
> > Best,
> > Laird
> > 
> > _______________________________________________
> > 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
> 
> 
> --
> Thanks
> Emily
> 
> 
> _______________________________________________
> 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
> 
> 
> --
> Thanks
> Emily
> 
> _______________________________________________
> 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
>