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