Add support to configuration file per profile #11145

marcelorubim · 2020-08-01T22:02:49Z

As described on issue #6810, this change adds the support to use a configuration file per-profile.

The user can have an application.properties with general configuration and one file for each profile, like application-dev.profile for dev profile.

Closes #6810

famod · 2020-08-02T23:01:20Z

@radcortez This might be of interest to you. I am wondering whether this has any impact on #9895 / smallrye/smallrye-config#363.

radcortez · 2020-08-03T10:00:02Z

Sort of.

These are two different things, since Quarkus way to define profiles as you know is to list them all in the same file. For a multi-profile, multi-file approach we would need to look as many files as profiles defined, not just an additional file.

famod · 2020-08-03T18:40:34Z

Ok, thanks for your feedback. I just wanted to make sure that this not "diametrical" to what you have in mind for smalrye-config in context of #9895.

radcortez · 2020-08-03T22:35:07Z

BTW, I've already added support for profile aware microprofile-config.properties files, which is coming in 2.0. For Quarkus, probably it would still require some custom implementation since the files names are not the same.

smallrye/smallrye-config@96bada1

Anyway, we probably have to look into making Quarkus / SmallRye Config more consistent and off load most of the work to SmallRye Config.

marcelorubim · 2020-08-03T22:55:13Z

Nice! Maybe I should already add the same support for the MicroProfile files per profile in this PR.

radcortez · 2020-08-04T09:48:11Z

Ideally we should support both at the same time. It would look weird to support one type of file and not the other, even considering that most people will use the application.properties file.

marcelorubim · 2020-08-04T13:25:51Z

I included the treatment for MicroProfile files per profile as well.

...untime/src/main/java/io/quarkus/runtime/configuration/ApplicationPropertiesConfigSource.java

Ladicek · 2020-08-18T12:32:02Z

I really don't think I'm the one who should review this, but FWIW, this LGTM :-)

(I actually prefer this style of config profiles over the %profile.whatever style Quarkus has. Thorntail had it right ;-) )

famod · 2020-08-18T12:38:37Z

@marcelorubim it seems you included an unrelated commit (awssdk update).
Please also use rebase to update PR branches, not vanilla merge. Thank you very much!

marcelorubim · 2020-08-18T12:54:08Z

@marcelorubim it seems you included an unrelated commit (awssdk update).
Please also use rebase to update PR branches, not vanilla merge. Thank you very much!

Sorry! I did some mess while rebasing. Now it's fixed! Thanks for warning me!

radcortez · 2020-08-18T15:07:48Z

...untime/src/main/java/io/quarkus/runtime/configuration/ApplicationPropertiesConfigSource.java

@@ -54,19 +56,25 @@

    public static final class InJar extends ApplicationPropertiesConfigSource {
        public InJar() {
-            super(openStream(), 250);
+            super(openStream(null), 260);


Shouldn't we keep the same ordinal?

I'm going to follow up your sugestions.

I just keet the same pattern to add +10 for each one. But you're right. I would be better to not change the ordinal and only add +1.

radcortez · 2020-08-18T15:08:22Z

...untime/src/main/java/io/quarkus/runtime/configuration/ApplicationPropertiesConfigSource.java

            }
            return is;
        }
    }

    public static final class InFileSystem extends ApplicationPropertiesConfigSource {
        public InFileSystem() {
-            super(openStream(), 260);
+            super(openStream(null), 280);


Shouldn't we keep the same ordinal?

radcortez · 2020-08-18T15:09:18Z

core/runtime/src/main/java/io/quarkus/runtime/configuration/ConfigUtils.java

@@ -123,10 +114,9 @@ public static void addSourceProviders(SmallRyeConfigBuilder builder, Collection<
    }

    static class EnvConfigSource implements ConfigSource, Serializable {
+        static final Pattern REP_PATTERN = Pattern.compile("[^a-zA-Z0-9_]");


This change doesn't seem necessary.

radcortez · 2020-08-18T15:13:56Z

Since we are adding new sources with new ordinals, there is a chance (low, but it is there) that user custom sources (if in the range of the used ordinals), conflict with the new ones. Everything will work, but maybe some configuration resolution may yield different results.

I would probably stick to use the same ordinal for the original sources and only increase the ordinal by +1 for the profile based properties. The chance will always be there, but it will make it even lower.

marcelorubim · 2020-08-21T13:10:09Z

@gsmet @geoand could you please take a look at this PR?

geoand · 2020-08-21T13:22:09Z

I'll take a look some time next week. There is a ton of work that has pilled up

geoand · 2020-08-24T07:51:40Z

Question:

What happens with this PR when a user add %dev.quarkus.some.key=value to application-dev.properties?
What happens if the user adds %test.quarkus.some.key=value?

marcelorubim · 2020-08-24T10:00:13Z

Question:

What happens with this PR when a user add %dev.quarkus.some.key=value to application-dev.properties?

If the user adds %dev.quarkus.some.key=value and quarkus.some.key=value1, the config with the profile prefix will be one loaded.

What happens if the user adds %test.quarkus.some.key=value?

It will be ignored, as the file is only loaded for the dev profile

@geoand

geoand · 2020-08-24T10:05:39Z

Question:
What happens with this PR when a user add %dev.quarkus.some.key=value to application-dev.properties?

If the user adds %dev.quarkus.some.key=value and quarkus.some.key=value1, the config with the profile prefix will be one loaded.

So essentially a user can continue using the profile prefix inside the profile specific file?

What happens if the user adds %test.quarkus.some.key=value?

It will be ignored, as the file is only loaded for the dev profile

I guess I wasn't clear. My question was what happens if %test.quarkus.some.key=value is added to application-dev.properties and then the dev profile is active.

marcelorubim · 2020-08-24T10:19:42Z

So essentially a user can continue using the profile prefix inside the profile specific file?

Yes. I will be kind of redundant, but he can.

I guess I wasn't clear. My question was what happens if %test.quarkus.some.key=value is added to application-dev.properties and then the dev profile is active.

Quarkus will not load the application-dev.properties when the test profile is active, so the value will be ignored.

And during the dev profile, it will work the same as the default application.properties. Only the configurations without prefix or with the dev profile prefix will be loaded.

geoand · 2020-08-24T10:29:36Z

OK, thanks.

I am +0 on this TBH (because we might be introducing too many ways to do the same thing), so I'll let others approve it.

famod · 2020-10-09T14:01:58Z

@geoand

so I'll let others approve it.

Is there anyone you'd suggest? Unfortunately this has stalled for over a month...

geoand · 2020-10-09T14:19:43Z

I'd propose sending an email to the mailing list with a link to this to get more opinions

YunaBraska · 2020-10-19T14:21:56Z

This is awesome but I think the changes are also needed for yaml configs like on io.quarkus.config.yaml.runtime.ApplicationYamlProvider
And second what's still missing for my use case coming from spring boot is to configure multiple profiles - but that's maybe a next topic since this pull request is opened for long enough. Can't wait to get it merged 👍

radcortez · 2020-10-19T14:27:44Z

And second what's still missing for my use case coming from spring boot is to configure multiple profiles - but that's maybe a next topic since this pull request is opened for long enough. Can't wait to get it merged 👍

Multiple profiles are going to be available with #12789.

AlbozDroid · 2020-10-26T11:13:39Z

This is very important for us too, it helps to keep the config clean. Is there any plan for when to merge this?

vsevel · 2020-10-30T11:44:52Z

hello, I think this is a good idea. here is a use case: https://groups.google.com/g/quarkus-dev/c/xCU6Yvw__ks

radcortez · 2020-10-30T15:18:46Z

There is also some work going to support additional locations:
smallrye/smallrye-config#431

gsmet · 2021-04-01T08:53:49Z

@radcortez didn't you implement it now?

radcortez · 2021-04-01T10:21:00Z

Yes.

Sorry @marcelorubim. This is now provided by SmallRye Config as part of the MicroProfile Config 2.0 work (since this was added into the spec). Thank you for your effort.

famod · 2021-04-01T11:34:37Z

@radcortez Isn't Quarkus still on SmallRye Config 1.x? AFAICS, SmallRye Config 2.x is based on MicroProfile Config 2.0, right?

radcortez · 2021-04-01T11:52:38Z

@radcortez Isn't Quarkus still on SmallRye Config 1.x? AFAICS, SmallRye Config 2.x is based on MicroProfile Config 2.0, right?

Yes, but I back ported all the features that didn't have any API changes to the 1.x branch.

famod · 2021-04-01T12:01:10Z

Ah, I see. Do you remember in which PR you did that? I would like to assign this issue to a milestone and temove triage/invalid. Thanks!

radcortez · 2021-04-01T12:08:08Z

#15282

boring-cyborg bot added area/config area/core labels Aug 1, 2020

marcelorubim force-pushed the master branch 3 times, most recently from 91c02cc to 55d8c5c Compare August 2, 2020 19:42

boring-cyborg bot added the area/documentation label Aug 2, 2020

marcelorubim force-pushed the master branch 3 times, most recently from 6170530 to 1ddae35 Compare August 4, 2020 10:55

Ladicek reviewed Aug 18, 2020

View reviewed changes

...untime/src/main/java/io/quarkus/runtime/configuration/ApplicationPropertiesConfigSource.java Show resolved Hide resolved

marcelorubim force-pushed the master branch from 1ddae35 to ef5b29e Compare August 18, 2020 09:07

marcelorubim requested a review from Ladicek August 18, 2020 11:30

marcelorubim force-pushed the master branch from ef5b29e to e0fec5b Compare August 18, 2020 12:00

boring-cyborg bot added the area/dependencies Pull requests that update a dependency file label Aug 18, 2020

Ladicek removed their request for review August 18, 2020 12:29

marcelorubim force-pushed the feature/multiple-configuration branch from a734475 to ea9026c Compare August 18, 2020 12:51

radcortez requested changes Aug 18, 2020

View reviewed changes

marcelorubim force-pushed the feature/multiple-configuration branch from ee09a08 to 06e9ef4 Compare August 18, 2020 15:37

radcortez approved these changes Aug 18, 2020

View reviewed changes

marcelorubim force-pushed the feature/multiple-configuration branch from 06e9ef4 to 553a447 Compare August 18, 2020 20:11

Add support to configuration file per profile

06c2d2f

marcelorubim force-pushed the feature/multiple-configuration branch from 553a447 to 06c2d2f Compare August 19, 2020 08:46

Base automatically changed from master to main March 12, 2021 15:54

radcortez closed this Apr 1, 2021

quarkus-bot bot added the triage/invalid This doesn't seem right label Apr 1, 2021

famod removed the triage/invalid This doesn't seem right label Apr 1, 2021

famod added this to the 1.13.0.CR1 milestone Apr 1, 2021

liuzqt mentioned this pull request Jul 1, 2021

what the behavior of multi-profile properties config? #18292

Closed

fbricon mentioned this pull request Jul 7, 2021

Add support for configuration file per profile redhat-developer/vscode-quarkus#371

Closed

Add support to configuration file per profile #11145

Add support to configuration file per profile #11145

Conversation

marcelorubim commented Aug 1, 2020 • edited

famod commented Aug 2, 2020

radcortez commented Aug 3, 2020

famod commented Aug 3, 2020

radcortez commented Aug 3, 2020

marcelorubim commented Aug 3, 2020

radcortez commented Aug 4, 2020

marcelorubim commented Aug 4, 2020

Ladicek commented Aug 18, 2020

famod commented Aug 18, 2020

marcelorubim commented Aug 18, 2020

radcortez Aug 18, 2020

Choose a reason for hiding this comment

marcelorubim Aug 18, 2020

Choose a reason for hiding this comment

radcortez Aug 18, 2020

Choose a reason for hiding this comment

radcortez Aug 18, 2020

Choose a reason for hiding this comment

radcortez commented Aug 18, 2020 • edited

marcelorubim commented Aug 21, 2020

geoand commented Aug 21, 2020

geoand commented Aug 24, 2020

marcelorubim commented Aug 24, 2020 • edited

geoand commented Aug 24, 2020

marcelorubim commented Aug 24, 2020

geoand commented Aug 24, 2020 • edited

famod commented Oct 9, 2020

geoand commented Oct 9, 2020

YunaBraska commented Oct 19, 2020

radcortez commented Oct 19, 2020

AlbozDroid commented Oct 26, 2020

vsevel commented Oct 30, 2020

radcortez commented Oct 30, 2020

gsmet commented Apr 1, 2021

radcortez commented Apr 1, 2021

famod commented Apr 1, 2021

radcortez commented Apr 1, 2021

famod commented Apr 1, 2021

radcortez commented Apr 1, 2021

marcelorubim commented Aug 1, 2020 •

edited

radcortez commented Aug 18, 2020 •

edited

marcelorubim commented Aug 24, 2020 •

edited

geoand commented Aug 24, 2020 •

edited