[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [cdi-dev] CDI future - problems and proposal
|
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
example
https://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