User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
On 25. 01. 21 7:58, Mark Struberg
wrote:
Once again: if CDI-lite is not binary and
otherwise just a subset of CDI, then PLEASE find a different
name for it.
How is anything of the discussed not a strict subset of CDI?
What you want is more like a JSR-330 container
with some sprinkles from CDI features here and there - but
with a different API.
I don't know about others, but from what I've seen (and
suggested), we want like 90 % of CDI (or, as I like to call it,
"CDI, the good parts"), not "some sprinkles here and there".
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.
That is what I expect as well.
The _only_ exception is extensions, because those just can't be
taken to build-time. From the remaining API, my proposal is to
take like 90 % of it verbatim and don't change anything there
(even though there would be very good reasons to make changes!).
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!
I'd also like to ask you one thing: please assume positive
intent, and feel free to attend the regular calls if you think we
need to clarify anything.
>
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.