[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [cdi-dev] CDI Lite compatible extension lead
|
On 29. 09. 20 22:06, Jason Greene
wrote:
On Sep 29, 2020, at 1:54 PM, Jason Greene <jason.greene@xxxxxxxxxx> wrote:
Did you see Antoine’s blog in
March?:
Yes. With (truly!!) all respect
to Antoine, it's a bit all over the place and
not a list of use cases or goals.
Can we just put down here, in
simple bullet point formats, what at least the
goals of this effort are?
I don't mean to suggest this is a
trivial exercise, because it is not, and Emily
certainly tried to get it rolling before
(mostly unsuccessfully) with issue #425 (
https://github.com/eclipse-ee4j/cdi/issues/425;
and I applaud her attempt to start with the
use cases). But let's try again, here,
publicly, on this list.
For the record, I'm definitely
aware of {handwave} build time {handwave} no
reflection {handwave} but I'm quite sure we
can do better than that as a group. Here is
an incomplete sketch of one example of the
sort of thing I had in mind.
Meta-goal: disrupt the
specification as little as humanly possible
(true of all specifications everywhere that
are this old)
Goal: permit a CDI SeContainer to
run a precomputed set of beans without having
to run portable extensions
Why: certain products create their
beans at build time/ahead of time: we want
them to be part of the CDI fold as well
Hindrance: the
SeContainerInitializer/portable extension
APIs, even with something like
SeContainerInitializer.disableDiscovery().addExtension(new
Extension() { /* add beans here however they
are generated/created */ }) is insufficient
because of X, Y and Z
Hindrance: all (not just some)
portable extensions must be available at
runtime via BeanManager#getExtension()
…etc. and so on. I can see the
germs of something like this lurking in your
posts and others' and in Antoine's blog
article and elsewhere but I think it is
necessary that we have small, traceable,
actionable goals spelled out here before we
try to solve them.
So I think we have explained the why quite a
bit, and importantly we are talking about fundamental
compatibility differences (two-phase multi-VM execution
vs one phase), so you are already at the point of having
to start anew. It’s not something that a simple API
tweak here and there is going to solve.
Totally agree. I'd highlight what you put into parens :-) I have
never considered it a use case, or anything worth extra
mentioning, which in hindsight is an obivous mistake, so let me
try to phrase it concretely.
Goal: modify the specification and the APIs to no longer assume
that everything happens in a single JVM. It should be possible for
a big part of the "application initialization lifecycle",
including extensions, to run in another JVM, to "pre-wire" the
application statically and enable significant performance gains
during actual application startup.
(I understand this might not necessarily be a SMART goal. Sorry
about that, I'm a simple man and prefer debating concrete ideas
rather than abstract methodologies.)
Just a small clarification that I am specifically referring
to portable extensions (#434) and the proposal (#451) which is
the subject of this thread. This is the area that requires a
reboot, to cover the same extension author use cases.
The other areas of CDI are less of a problem, each of those
items will have their own issue against them (which might
involve small spec wording changes). Some of them might be
future decision points (should lite include X yes/no?) However,
the hardest part of a potential CDI-Lite is solving the portable
extension problem, so IMO it makes sense to tackle this area
first. FWIW we new this would tough, so we first proposed just
leaving this aspect to venders, but a number of commenters
really wanted to see work on a new SPI. So here we go :)
Yes!
LT
-Jason
_______________________________________________
cdi-dev mailing list
cdi-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdi-dev