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