Well. Again, maybe I'm not up2date. But what I've seen was the replacement of one Extension mechanism (mostly reflection based) with another one (build time modifications with additional processing). So I really would question the 'lighter'. Yes it starts faster. But when is this really important? For the development roundtrip it's just shifting the dynamic processing from the bootstrap phase to the build processing phase. Devs do not leverage nearly as much as the marketing material says. It's almost a net zero game.
It’s a subset that makes significantly less assumptions about the execution environment its running in,
I'd say No. It just forces you to know all the assumptions about the execution environment it's running in upfront during build time already, isn't?
by improving the extension contracts t
Sounds like more code to me. See 'liter'
to feature stronger encapsulation and weaker coupling to implementation details.
Again I don't get this point. It just moves the encapsulation and coupling to the build phase. So it removes some dynamics (which might be good). But the downside is that it makes components and apps way less reusable imo.
LieGrue, strub
It’s “lite”r :)
It’s a subset that makes significantly less assumptions about the execution environment its running in, by improving the extension contracts to feature stronger encapsulation and weaker coupling to implementation details.
Hi all, What is the key defining feature that makes it different from “regular” CDI? Is that something someone can describe in a one liner? Thanks! Kind regards, Manfred Riem I would not use the word „Native“ because it sounds like JNI ;-) Werner Gesendet von Mail für Windows 10 How about calling it CDI native compilation profile or native profile or static profile? Reza Rahman
Jakarta EE Ambassador, Author, Blogger, Speaker
Please note views expressed here are my own as an individual community member and do not reflect the views of my employer. On 1/25/2021 9:31 AM, Manfred Riem wrote: Hi all, I couldn’t agree more with Mark on this one. If it is not a proper sub set but instead borrows concepts from CDI it really is not CDI Lite. Naming is important as it can cause a lot of confusion if done wrong! Thanks! Kind regards, Manfred Riem Once again: if CDI-lite is not binary and otherwise just a subset of CDI, then PLEASE find a different name for it. What you want is more like a JSR-330 container with some sprinkles from CDI features here and there - but with a different API. Yes you probably started at CDI mind wise, but now you are somewhere completely else. Please do not trash CDI by adding something else! Or to say it in different words: If you call it CDI-lite, then people expect that they will be able to run those libs on a fully blown CDI server as well. It this is not the case (because the API is different), then please don't call it CDI-lite. The spec might still be valuable, but please go find another name!
On 16. 01. 21 0:16, Emily Jiang wrote: > As a matter of fact, we currently pour everything into a singular bean archive (which I have to say I came to like as it makes understanding the meaning of bean archive much simpler for users). Ah that is a great point, totally forgot about that! I think we should
do this in Lite. Multiple bean archives made everything really confusing
for me when I started learning CDI. This approach leads to the complication of merging beans.xml. What if the beans.xml has conflicts, which one takes precedence.
The proposal is that in Lite, we don't take beans.xml content into account. We "only" use it as a marker file to find JARs that should be part of the "singular" bean archive. So that is a non-issue, and, in fact, simplification :-)
What about enabling interceptors via beans.xml? Would the enablement be done via @Priority only? Your suggestion of discarding the contents of beans.xml is quite a big change. > Tomas Langer also correctly mentioned that today you can have beans.xml with discovery mode "none" and therefore the presence of beans.xml can mean you don't want to process that archive.
> This is true, although I have to point out that I haven't really seen this used much. It is probably a remnant of CDI 1.0 where default discovery mode was explicit (instead of annotated) and where you needed to always have beans.xml present. The only reason why I think we might want to detect beans.xml
configuring discovery mode to "none" is legacy JARs. Not sure how big of Open Liberty uses this for improving performance for migrated applications. The applications used CDI 1.0 and then migrated to CDI 1.2/2.0. Setting bean-discovery-mode="none" will disable the scanning, which improves the performance.
What I'd like to understand is, how much is that relevant when it comes to Lite? My guess would be: not much.
My statement was about the use case assessment. On 16. 01. 21 0:16, Emily Jiang wrote: > As a matter of fact, we currently pour everything into a singular bean archive (which I have to say I came to like as it makes understanding the meaning of bean archive much simpler for users). Ah that is a great point, totally forgot about that! I think we should
do this in Lite. Multiple bean archives made everything really confusing
for me when I started learning CDI. This approach leads to the complication of merging beans.xml. What if the beans.xml has conflicts, which one takes precedence.
The proposal is that in Lite, we don't take beans.xml content into account. We "only" use it as a marker file to find JARs that should be part of the "singular" bean archive. So that is a non-issue, and, in fact, simplification :-) > Tomas Langer also correctly mentioned that today you can have beans.xml with discovery mode "none" and therefore the presence of beans.xml can mean you don't want to process that archive.
> This is true, although I have to point out that I haven't really seen this used much. It is probably a remnant of CDI 1.0 where default discovery mode was explicit (instead of annotated) and where you needed to always have beans.xml present. The only reason why I think we might want to detect beans.xml
configuring discovery mode to "none" is legacy JARs. Not sure how big of Open Liberty uses this for improving performance for migrated applications. The applications used CDI 1.0 and then migrated to CDI 1.2/2.0. Setting bean-discovery-mode="none" will disable the scanning, which improves the performance.
What I'd like to understand is, how much is that relevant when it comes to Lite? My guess would be: not much. LT On 12. 01. 21 17:26, Matej Novotny wrote:
> As a matter of fact, we currently pour everything into a singular bean archive (which I have to say I came to like as it makes understanding the meaning of bean archive much simpler for users).
Ah that is a great point, totally forgot about that! I think we should
do this in Lite. Multiple bean archives made everything really confusing
for me when I started learning CDI.
> Tomas Langer also correctly mentioned that today you can have beans.xml with discovery mode "none" and therefore the presence of beans.xml can mean you don't want to process that archive.
> This is true, although I have to point out that I haven't really seen this used much. It is probably a remnant of CDI 1.0 where default discovery mode was explicit (instead of annotated) and where you needed to always have beans.xml present.
The only reason why I think we might want to detect beans.xml
configuring discovery mode to "none" is legacy JARs. Not sure how big of
a use case that is.
LT
_______________________________________________
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@xxxxxxxxxxxTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdi-dev
|
