[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [cdi-dev] CDI future - problems and proposal
|
Good question, and I don't have an answer. Wanna help?
Thinking out loud:
One option is to not split anything, just let Lite
implementations fail (or ignore) if non-Lite API is used.
Another option is to release 2 overlapping API artifacts and
insist that they shouldn't be used at the same time, but that is
way too fragile in my opinion.
Yet another option is to move classes around, but that would
cause a huge pain, so I'd rather not do that either.
Any other ideas?
LT
On 12. 11. 20 9:50, Mark Struberg
wrote:
How would splitting out
the API work?
Since Java9 splitting up the same package into
different jars is not a good idea (actually never was, but
technically the JVM did not complain unless one of the jars
was sealed).
LieGrue,
strub
Hi,
Jason already said that, but I'll
reiterate so that this doesn't fall through the
cracks.
On 11. 11. 20 21:52, Mark Struberg wrote:
CDI core and CDI lite are
different things. After reading the CDI-light
proposal it appears to me, that it shares just the
name 'CDI', but not much more.
It feels a bit like a different spec
with main focus on running well on Graal and not
needing any reflection or dynamic handling.
E.g. the wish to get rid of
Contextual NormalScope proxies will kill CDI.
This is literally the C in CDI !
Isn't it good that noone actually
proposes to do that?! See for examplehttps://docs.google.com/document/d/1jS7EbHnyBBvZZxa56LmthKeoixm2FEHmqHwITGRLljQ/edit where I list
what I think could/should be in the CDI Lite API.
What I propose to "remove" is, on
the API level:
- decorators
- specialization
- conversations
- session scope
- non-contextual injection
- Portable Extensions
There's obviously more to it than
the API, but it should give you an idea.
A lot of the dynamism of CDI can be
achieved by generating code at build time. I haven't
seen anyone wanting to "cripple" the essence of CDI
-- it's all about being able to implement it under a
different set of architectural constraints.
LT
I've added some comments.
And to clarify upfront: I'm not
against such a spec. But it imo would not be CDI
anymore. With removing all the dynamics we are
back to Apache Avalon.
Werner: imo the jigsaw modularity
only works well for the JDK itself. Never have
seen it used in production due to various
reasons.
LieGrue,
strub
Unfortunately this was done
in a rather clumsy way particularly the
" independent " SE Elements that make no
sense in an EE context and vice versa.
While this was not in scope
or targeted by around a third of all
Jakarta EE 9 specs (and because of these
issues I don’t recall CDI even bothered
declaring a module in the MANIFEST yet)
"Jigsaw" modularity that was archieved
for the JDK itself will come as soon as
Jakarta EE 9.1, so CDI2 was not the
answer to a "CDI Lite" yet, it should be
a "CDI Core" or whatever module in a
future CDI Version that has other EE
specific modules on top of it.
Werner
But this already got
addressed in CDI-2.0 with the split
into SE and EE parts of the spec.
A container
not intended for JavaEE is free to
not implement those Beans.
Or like we do
it in Apache OpenWebBeans - keep it
modular with a core which is just
700kB in size and all the
integration is added on top of it.
or
in retrospect
shouldn't be in CDI
in the first place.
Things like:
- decorators
- specialization
- session scope
- conversation scope
- passivation
- non-contextual
injection
I always
felt that just JSR
330/AtInject was way
too small, while JSR
299/CDI might have
been a tad too big. My
personal pet peeve is
the fact that CDI
includes build-in
beans for several
Servlet types, such as
HttpServletRequest. We
tried hard before to
get that out of CDI
and into Servlet.
Likewise, the build-in
bean for Principal
should likely
belong in Jakarta
Security, etc.
Though the
conversation scope is
technically not bound
to Faces, maybe we
should consider moving
it to Faces anyway?
_______________________________________________
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