Enable CDI beans based on profiles

[jonathanvila]

Description
Based on a profile especified (env var) an Annotated bean will be added to the context or filtered out.

[geoand]

cc @mkouba

[geoand]

So the idea is to conditionally create a bean based on whether or not a profile is active, correct?

Of course this can't work with profiles defined at runtime, but seems very useful for build time profiles

[jonathanvila]

Exactly that is the idea.
Basically we can activate few beans on "test" profile, others on "prod" profile..... specially databases related beans, file persistance beans.....

[mkouba]

Of course this can't work with profiles defined at runtime, but seems very useful for build time profiles

Hm, that's something I'm concerned about. The first question will be "I do set my profile to staging when running my app and the beans are still there, why?".

[geoand]

Yes...

Just an idea: Perhaps we could expand the concept of profile to encompass the build-time vs run-time difference? Or would that make things more confusing... I don't know :)

[jonathanvila]

I'm not sure to understand. In runtime setting the -Dquarkus.profile=whatever has absolutely no effect as it only works in the maven command.....so, my idea is when we build the app we specify the profile used (-Dquarkus.profile ) but obviously this wont have any effect on the result. This is taking into account we can not do anything on runtime.

…

On Wed, Dec 18, 2019 at 10:15 AM Georgios Andrianakis < ***@***.***> wrote: Yes... Just an idea: Perhaps we could expand the concept of profile to encompass the build-time vs run-time difference? Or would that make things more confusing... I don't know :) — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#6238?email_source=notifications&email_token=AAOALERDC7VFFLV4EJAL6WDQZHS2TA5CNFSM4J3743IKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHFOL5Q#issuecomment-566945270>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAOALESOLVRQGATUTAKWVW3QZHS2TANCNFSM4J3743IA> .

[geoand]

The issue is that -Dquarkus.profile=whatever does have an effect on user supplied properties (properties in application.properties prefixed with %whatever like %whatever.greeting.message) will be active.

So if we introduce the profiles support for beans users will get the false sense that if they use -Dquarkus.profile=whatever then beans for the whatever profile will be activated. So we would need to find a good user experience that would allow the functionality you propose but that wouldn't confuse users.

[jonathanvila]

Ohhh I see. So passing the quarkus profile on Runtime makes the app to take the values for those profile properties. So then que quarkus profile is a Runtime feature not a build feature? El mié., 18 dic. 2019 14:44, Georgios Andrianakis <[email protected]> escribió:

…

The issue is that -Dquarkus.profile=whatever does have an effect on user supplied properties (properties in application.properties prefixed with %whatever like %whatever.greeting.message) will be active. So if we introduce the profiles support for beans users will get the false sense that if they use -Dquarkus.profile=whatever then beans for the whatever profile will be activated. So we would need to find a good user experience that would allow the functionality you propose but that wouldn't confuse users. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#6238?email_source=notifications&email_token=AAOALETG34DX44AM4YKG4ETQZISMLA5CNFSM4J3743IKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHGEZDA#issuecomment-567037068>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAOALEQGBWLS24IKZED77OLQZISMLANCNFSM4J3743IA> .

[geoand]

Exactly. So if we are to make something like this available for CDI beans, we need to be very careful how to make a good user experience

[mkouba]

So then que quarkus profile is a Runtime feature not a build feature?

IIUIC it's both - the build-time and the runtime feature.

[geoand]

So then que quarkus profile is a Runtime feature not a build feature?

IIUIC it's both - the build-time and the runtime feature.

My interpretation is that run-time implies build-time as well :)

[jonathanvila]

which is the impact in build time of the quarkus.profile ?

…

On Wed, Dec 18, 2019 at 2:56 PM Georgios Andrianakis < ***@***.***> wrote: So then que quarkus profile is a Runtime feature not a build feature? IIUIC it's both - the build-time and the runtime feature. My interpretation is that run-time implies build-time as well :) — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#6238?email_source=notifications&email_token=AAOALEX7OIMAG2SFTVNJ5GLQZITZPA5CNFSM4J3743IKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHGF7EY#issuecomment-567041939>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAOALETGENK5AHYEURPT6GDQZITZPANCNFSM4J3743IA> .

[geoand]

Besides affecting the configuration stuff, it also set implicitly when running tests and the dev mode

[stuartwdouglas]

I don't think that the build time only aspect of this is an issue, as we already have the concept of build time only config.

[geoand]

I also like this idea a lot, but I my concern is summed up very well by this comment from @mkouba

[stuartwdouglas]

It is now possible to enable CdI beans via config, and #9933 allows them to be enabled per test easily.

[mkouba]

For the record - there's also @IfBuildProfile and @UnlessBuildProfile: https://quarkus.io/guides/cdi-reference#enabling-beans-for-quarkus-build-profile