Re: [cdi-dev] About parsing beans.xml files in Lite

[Matej Novotny <manovotn@xxxxxxxxxx>]

----- Original Message -----
> From: "Emily Jiang" <emijiang6@xxxxxxxxxxxxxx>
> To: "cdi developer discussions" <cdi-dev@xxxxxxxxxxx>
> Sent: Tuesday, January 19, 2021 4:02:27 PM
> Subject: Re: [cdi-dev] About parsing beans.xml files in Lite
> 
> 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.

Yes, that was one of the things I believe we discussed last time.
Priority is the easiest way to do it anyway. Not to mention that with singular bean archive, there is little point in "per-archive" activation.

That being said, if we see the need for conditional interceptors enablement (testing maybe?), we can always add that.
One of the ways would be parsing the contents of beans.xml but I would still insist on this enablement being treated as global just like priority is right now.
Another would be some form of property. Either way, if we see the demand, we can always add things as opposed to taking them out :-)

> 
> 
> 
> > 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.
> 
> 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.

I see what you mean.
However, note that you are trying to imply that you take CDI 1.0 application and want to port it, without any changes, to CDI Lite which is going to be what? CDI 4.0?
And that's discounting the fact that you will want to move from runtime to buildtime environment where you usually want to optimize your app to take advantage of it.
Frankly, I don't think this scenario should concern us too much.


> 
> On Mon, Jan 18, 2021 at 8:15 AM Ladislav Thon < lthon@xxxxxxxxxx > wrote:
> 
> 
> 
> 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
> a use case that is.
> 
> 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
> 
> 
> 
> 
> Thanks
> Emily
> 
> On Tue, Jan 12, 2021 at 4:37 PM Ladislav Thon < lthon@xxxxxxxxxx > wrote:
> 
> 
> 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
> 
> 
> --
> Thanks
> Emily
> 
> 
> _______________________________________________
> 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
> 
> 
> --
> Thanks
> Emily
> 
> 
> _______________________________________________
> cdi-dev mailing list
> cdi-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cdi-dev
>