Then why not consider putting the 'light' or whatever part into the 'I' which is Jakarta Injection and out of CDI? Jigsaw is there whether you like how it’s done or not. It may not be as visible as OSGi in Eclipse and other OSGi containers, but many large and popular frameworks like Spring do, although most of them shy away from declaring module-info, but stick to the Automatic-Module-Name in the MANIFEST. Looking at how fast the JDK throws away older stuff, I would not be too surprised, if Java 20 or some version a bit after it removes the legacy 'META-INF/services' mechanism because you can do that much more powerful and with better Control in the module-info. Then more Frameworks or apps will have to use it including all the Jakarta specs that apply the old 'services' files. Werner 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.
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. 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
|
