| Hi Mark,
I can certainly understand disagreement, but can we avoid mischaracterizing what’s in the drafts? In all of the various proposals the overwhelming majority of the Core API, including contextual scopes, is retained which is certainly a lot more than just the name. It certainly does intend to be less than Full (the proposal is called Lite after all) and more than AtInject.
I do share your opinion on Jigsaw.
-Jason
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 !
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@xxxxxxxxxxxTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdi-dev
|
