[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdi-dev] About parsing beans.xml files in Lite
|
Hi Mark
> OSS is mostly based on mailing lists. 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. And I do absolutely assume positive intent. I just wanted
> to set the baseline.
There have been numerous threads on this mailing list (over several past months?) and more will surely emerge regarding this topic.
We definitely didn't mean to cut someone out of the discussion.
However, the effort wasn't moving so smoothly and since many people expressed their confusion, we decided to establish a weekly meeting for at least some time.
There are still meeting notes and most of the discussion there was just a more in-depth dive on what went through this mailing list anyway.
And for myself, I do feel the meetings are definitely helping to get a better agreement and understanding of the topic between the participating community members.
> 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.
That's integrations though, not user apps. And yes, sadly we cannot take existing extensions into runtime.
The 90% Ladislav mentioned is user apps being able to use CDI as they do now. And that would be true for Lite because all their beans, interceptors, events etc would still be there.
OFC there are even user apps with some extensions but they are not nearly as common.
You are right that integrators would need to have a slightly different implementation to support Lite - exactly what we saw happen in Quarkus and SmallRye as its MP impl.
In many cases it really is just the extension logic that you need to rewrite (assuming you don't want further optimization to avoid heavy lifting at runtime) and we are trying to come with an extension SPI that works in build time and allows you to do just that, ideally in the same scope.
> 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.
In build time environment, not much else apart from `annotated` makes sense when it comes to discovery.
The marker file approach can be a further optimization to lessen the amount of beans processed.
Name of the file (as I actually said in mails) doesn't need to be beans.xml.
But if it were, then it's easier to understand for existing users of CDI as such and could mean you take an existing app and just consume it with Lite as a bean archive.
Regards
Matej
----- Original Message -----
> From: "Mark Struberg" <struberg@xxxxxxxxxx>
> To: "cdi developer discussions" <cdi-dev@xxxxxxxxxxx>
> Sent: Monday, January 25, 2021 9:17:24 AM
> Subject: Re: [cdi-dev] About parsing beans.xml files in Lite
>
> Hi Ladislav!
>
> OSS is mostly based on mailing lists. 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. And I do absolutely assume positive intent. I just wanted
> to set the baseline.
>
> 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.
>
> 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.
>
> 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
>
>
>
>
> 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
>
>
> _______________________________________________
> 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
>
