[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdi-dev] About parsing beans.xml files in Lite
|
On 26. 01. 21 13:38, Mark Struberg
wrote:
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.
Given that we've now repeated many times that what we're trying
to build is a subset of CDI, I have to assume that you're talking
exclusively about extensions. So here's a thing: portable
extensions can't be made to work under the set of constraints I've
outlined previously (not without making significant breaking
changes). So we're trying to come up with a new extension API. If
we put it into CDI Lite, it's no longer a subset of CDI, and if we
don't, then there's no extension mechanism and that's wrong too.
See the catch 22 here?
I would hope that this gordian knot could be cut by specifying
something like "implementations have to support at least 1 of the
specified extension mechanisms", but that is very much an open
question. I personally don't see a perfect answer.
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.
Just moving a significant part of processing ("pre-wiring") to a
separate JVM does make the entire runtime footprint light.
(That is of course a property of implementation, not the
specification. The specification probably wouldn't require this, I
guess. Also, we propose to exclude some corner-case APIs from
Lite, so that makes it somewhat lite.)
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.
By definition, what's in the CDI spec is "the CDI spec". All
other claims of what is and isn't CDI are just aesthetical word
play, not an argument.
I would hope that any and all attempts to evolve CDI are not shot
down solely because they are "not CDI".
Then the next argument: Extensions are not being
used.
Hopefully that doesn't refer to my "the number of extension
authors is orders of magnitudes smaller than the number of
extension users", but if it does, and you're framing it as
"extensions are not being used", then you can't be surprised I'm
calling you out on using strawman arguments. Because "extensions
are not being used" is totally _not_ what I'm saying.
And while I explained that before, I'll repeat that I'm saying
this purely to explain why I think breaking extensions is
significantly less concerning than breaking the end-user API. I'd
love to be proven wrong or naive here.
A quick search shows that there are over 7k
Extension implementations on github. And this is just the
public part.
If you could share a URL (or instructions) how you found that
number, I'd totally appreciate that, because I wasn't able to come
up with any reasonable result using GitHub search.
I would personally expect that number to be a lot smaller, but
again, I'd love to be proven wrong.
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.
MicroProfile is a set of specifications, all of which can be
fully implemented using other mechanisms. Again, property of
implementation, not a specification.
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.
My understanding is that they run everything at runtime, thereby
achieving zero of the benefits we'd like to enable with CDI Lite.
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...
I'd really like a "spec lawyer" to stand up and explain whether
the proposal really isn't a subset of what CDI currently allows.
Any takers? :-)
LT
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@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
