You accused me of being a strawman back then and now again. But I still wait for arguments.
My point is clear:
If the newly proposed API is a strict subset of CDI, then let's call it "CDI light". If not, then please do not use the "CDI" term in the spec name.
That is my opinion and so far I did not hear any argument which convinced me that it's wrong. So I will voice it again.
And then my other arguments: By just moving from one set of API for Extensions to a different other one does NOT make it light. It just changes the API away from the current CDI spec to something different. You move the work from startup via reflection to build time + runtime from statically generated info.
Call it for example SDI for "Static Depencency Injection" or whatever you come up with if you like.
Then the next argument: Extensions are not being used.
A quick search shows that there are over 7k Extension implementations on github. And this is just the public part. I've done many dozen Business projects (after all that's my main job) for many different big companies around the EU. And from this work I can tell you that many of those projects DO use CDI Extensions in their business projects. Just remember that even MicroProfile started out as set of CDI Extensions. And still are today.
And then it is imo perfectly possible to do CDI (or a rather biggish subset) even with GraalVM. Oracle does the same with Helidon. And Apache Meecrowave also runs fine on the GraalVM. So I do not really understand why all this is really necessary. Yes, some changes might make live easier, but they will break compatibility.
And remember: we started this discussion with a proposed incompatible change in the behaviour of beans.xml...
LieGrue,
strub
Here's my take at "one defining feature", though it really is the
same as what Jason wrote: decouple the "initialization" phase
(where beans are discovered, extensions executed etc. etc.) from
the "runtime" phase (where the application just runs) so that
these 2 phases can be executed in 2 different JVM instances.
Note that I already wrote this here on the list at least once. At
this point, I feel like we're running around in circles, attacking
the same strawman over and over and over and over. That is not
productive. How come we got from a very specific quesion on which
everyone's opinion would be very much welcome, to debating "what
is CDI Lite", again?
LT
On 25. 01. 21 22:25, Jason Greene
wrote:
Hi Manfred, response inline:
To clarify if you say
subset do you mean that everything that works in this
version of CDI would also work in the “Full” version of
CDI?
As that is what subset
means to me.
If you are a CDI API user (e.g. a typical EE
developer) then yes.
If you are an integrator extending CDI by
distributing an extension then it depends on if the Full
implementation chooses to implement the build-compatible
extension SPI. In an ideal world we would have one extension
SPI, but the problem is that we can’t change/evolve the
existing extension SPI without impacting compatibility. Full
implementations expect to continue to offer that
compatibility so we effectively arrive at two extension
SPIs.
-Jason
_______________________________________________
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@xxxxxxxxxxxTo unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cdi-dev
