Skip to content

Commit

Permalink
Clarify how source ordinal applies with an active profile (#782)
Browse files Browse the repository at this point in the history
* fix(profiles): clarify how source ordinal applies with an active profile
  • Loading branch information
poikilotherm committed Jul 13, 2023
1 parent 346dab8 commit 652461f
Show file tree
Hide file tree
Showing 2 changed files with 103 additions and 4 deletions.
20 changes: 16 additions & 4 deletions spec/src/main/asciidoc/configprofile.asciidoc
Expand Up @@ -44,11 +44,12 @@ If the property `mp.config.profile` is specified in multiple config sources, the
==== On Property level
The configuration property that utilizes the Config Profile is called a "profile-specific" property. A "profile-specific" property name consists of the following sequence: `% <profile name>.<original property name>`.

Conforming implementations are required to search for a configuration source with the highest ordinal (priority) that provides either the property name or the "profile-specific" property name.
If the configuration source provides the "profile-specific" name, the value of the "profile-specific" property will be returned. If it doesn't contain the "profile-specific" name, the value of the plain property will be returned.
Conforming implementations are required to search all configuration sources that provide either the property name or the "profile-specific" property name.
If the configuration source provides the "profile-specific" name, the value of the "profile-specific" property will be returned.
If it doesn't contain the "profile-specific" name, the value of the plain property will be returned.
Thus, the "profile-specific" concept only influences which value is to be surfaced per config source.


For instance, a config source can be specified as follows.
For instance, a config source (ordinal 100) can be specified as follows.

[source, text]
----
Expand All @@ -75,6 +76,17 @@ In more details, if `mp.config.profile` is set to `dev`, the property `%dev.vehi
The properties `%live.vehicle.name` and `%testing.vehicle.name` are inactive config properties and don't override the property `vehicle.name`.

If `mp.config.profile` is set to `live`, the property `%live.vehicle.name` is the active property. The `vehicleName` will be `train`. Similarly, `bike` will be the value of `vehicleName`, if the profile is `testing`.
If no profile is active, `lorry` will be the value of `vehicleName`.

As explained above, the override scope is per configure source.
For instance, an additional source (ordinal 300) may be specified as follows:

[source, text]
----
vehicle.name=helicopter
----

The value of `vehicleName` will be `helicopter` no matter which profile might be active, as the higher ordinal (300 versus 100) makes the later source win.

==== On Config Source level

Expand Down
@@ -0,0 +1,87 @@
/*
* Copyright (c) 2023 Contributors to the Eclipse Foundation
*
* See the NOTICE file(s) distributed with this work for additional
* information regarding copyright ownership.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* You may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
package org.eclipse.microprofile.config.tck.profile;

import jakarta.enterprise.context.Dependent;
import jakarta.enterprise.inject.spi.CDI;
import jakarta.inject.Inject;
import org.eclipse.microprofile.config.ConfigProvider;
import org.eclipse.microprofile.config.inject.ConfigProperty;
import org.jboss.arquillian.container.test.api.Deployment;
import org.jboss.arquillian.testng.Arquillian;
import org.jboss.shrinkwrap.api.ShrinkWrap;
import org.jboss.shrinkwrap.api.asset.EmptyAsset;
import org.jboss.shrinkwrap.api.asset.StringAsset;
import org.jboss.shrinkwrap.api.spec.WebArchive;
import org.testng.annotations.Test;

import static org.hamcrest.MatcherAssert.assertThat;
import static org.hamcrest.Matchers.equalTo;
import static org.hamcrest.Matchers.is;

/**
* Test cases for Config profile
*
* @author Oliver Bertuch
*/
public class OverrideConfigProfileTest extends Arquillian {
@Deployment
public static WebArchive deployment() {
WebArchive war = ShrinkWrap
.create(WebArchive.class, "OverrideConfigProfileTest.war")
.addClasses(OverrideConfigProfileTest.class, ProfilePropertyBean.class)
.addAsResource(
new StringAsset(
"mp.config.profile=dev\n" +
"%dev." + PROPERTY + "=foo\n" +
PROPERTY + "=bar\n"),
"META-INF/microprofile-config.properties")
.addAsWebInfResource(EmptyAsset.INSTANCE, "beans.xml");

return war;
}

private static final String PROPERTY = "mp.tck.prop.dummy";
private static final String EXPECTED = "dummy";

/**
* This test relies on the system property "mp.tck.prop.dummy" being set to "dummy" as described in the TCK README
* as a requirement for runners. System properties are per the TCK requirements at ordinal 120, so shall override
* the given properties in the microprofile-config.properties file (ordinal 100) included in the WAR above.
*/
@Test
public void testConfigProfileWithDevAndOverride() {
assertThat(System.getProperty(PROPERTY), is(equalTo(EXPECTED)));

ProfilePropertyBean bean = CDI.current().select(ProfilePropertyBean.class).get();
assertThat(bean.getConfigProperty(), is(equalTo(EXPECTED)));

assertThat(ConfigProvider.getConfig().getValue(PROPERTY, String.class), is(equalTo(EXPECTED)));
}

@Dependent
public static class ProfilePropertyBean {
@Inject
@ConfigProperty(name = PROPERTY)
private String stringProperty;
public String getConfigProperty() {
return stringProperty;
}
}
}

0 comments on commit 652461f

Please sign in to comment.