| Re: [cdi-dev] About parsing beans.xml files in Lite |
Hi,
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.xmlAfaiu 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.
Thanks,
LT
_______________________________________________
LieGrue,strub
Am 19.01.2021 um 16:02 schrieb Emily Jiang <emijiang6@xxxxxxxxxxxxxx>:
_______________________________________________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
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
ThanksEmily
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
_______________________________________________ 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