User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
Hi,
On 25. 01. 21 9:17, Mark Struberg
wrote:
OSS is mostly based on mailing lists.
that might have been true in the 90's, but these days, I find
that OSS projects often have both synchronous and asynchronous
means of communication (while the async one doesn't necessarily
have to be mailing lists, but that's not our case).
This is what allows people from different time
zones and company background to contribute. Additional online
meetings are of course great, but they should not replace
information via the mailing list.
Right, so, I don't disagree here, but I wanted to explicitly
invite you to join the calls because I found that, at least for
me, it makes achieving consensus much faster. And that is, again
at least for me, usually because various people tend to use and
understand various terms differently, which is much faster to
resolve synchronously. Shared understanding of our vocabulary is
critical to building any kind of consensus.
And I do absolutely assume positive intent. I just
wanted to set the baseline.
Alright, thanks!
By excluding Extensions you imo remove 50% of CDI
functionality. Basically most of the integration works via
Extensions. Try to run any MicroProfile implementation without
Extensions. You will not even be able to start them up properly.
Yea, so extensions are special. I remember back in the days when
discussions about CDI Lite started, people were very vocal about
not losing extensions. So there's a proposal for build-time
compatible extensions, which are somewhat different from portable
extensions, but should be similarly powerful. How to make them
part of CDI is yet to be determined.
Personally, I think we can break extensions a bit, because the
number of extension authors is orders of magnitudes smaller than
the number of extension users -- but that's totally just my gut
feeling, definitely not backed by any even remotely scientific
data. Getting opposite opinions here is very welcome.
For me, it's crucial to not break any user-facing APIs.
Same with beans.xml
Afaiu you want to have the container pick up
beans.xml as a pure marker (like in CDI-1.0) but with the bean
discovery mode 'annotated', isn't? I fear that's not compatible
with what is defined in CDI right now.
So I think what we're after is a "strict subset of CDI". That
only implies compatibility in one way, from CDI Lite to CDI full,
not the other way around. If "bean discovery mode is always
annotated, and beans.xml is only used to find which JARs to scan"
isn't a strict subset of CDI, then I'd guess we would work towards
making it a strict subset of CDI :-)
LT
LieGrue,
strub
Am 25.01.2021 um 08:51 schrieb Ladislav Thon
<lthon@xxxxxxxxxx>:
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 canmean
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.