While i'm trying to use @ActiveProfiles to resolve properties on yaml, it does not resolved properly.
For example, my application.yml exists like this.
mangkyu.config=${spring.profiles.active}
And this is the test code to resolve properties.
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.core.env.Environment;
import org.springframework.test.context.ActiveProfiles;
import static org.assertj.core.api.Assertions.assertThat;
@ActiveProfiles({"local", "test"})
@SpringBootTest
class MangKyuListenerService333Test {
@Autowired
private Environment environment;
@Test
void sadfjp() {
String result = environment.getProperty("mangkyu.config");
assertThat(result).isNotBlank();
}
}
This is an error that test code throws.
java.lang.IllegalArgumentException: Could not resolve placeholder 'spring.profiles.active' in value "${spring.profiles.active}"
at org.springframework.util.PropertyPlaceholderHelper.parseStringValue(PropertyPlaceholderHelper.java:180)
at org.springframework.util.PropertyPlaceholderHelper.replacePlaceholders(PropertyPlaceholderHelper.java:126)
at org.springframework.core.env.AbstractPropertyResolver.doResolvePlaceholders(AbstractPropertyResolver.java:239)
at org.springframework.core.env.AbstractPropertyResolver.resolveRequiredPlaceholders(AbstractPropertyResolver.java:210)
at org.springframework.core.env.AbstractPropertyResolver.resolveNestedPlaceholders(AbstractPropertyResolver.java:230)
at org.springframework.boot.context.properties.source.ConfigurationPropertySourcesPropertyResolver.getProperty(ConfigurationPropertySourcesPropertyResolver.java:79)
at org.springframework.boot.context.properties.source.ConfigurationPropertySourcesPropertyResolver.getProperty(ConfigurationPropertySourcesPropertyResolver.java:60)
at org.springframework.core.env.AbstractEnvironment.getProperty(AbstractEnvironment.java:594)
at com.example.testing.event.MangKyuListenerService333Test.sadfjp(MangKyuListenerService333Test.java:26)
But if i rewrite a test code like below, it works well.
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.core.env.Environment;
import org.springframework.test.context.ActiveProfiles;
import static org.assertj.core.api.Assertions.assertThat;
@SpringBootTest("spring.profiles.active=local,test")
class MangKyuListenerService333Test {
@Autowired
private Environment environment;
@Test
void sadfjp() {
String result = environment.getProperty("mangkyu.config");
assertThat(result).isNotBlank();
}
}
As i debug how active profiles are registered, this one is happened by SpringBootContextLoader
ActiveProfiles are saved with array index and it does not resolved properly.
While this one is the property by the rewritten code.
Thanks for reading!
Comment From: wilkinsona
You cannot safely assume that spring.profiles.active will have been set using a comma-separated string. You will see a similar problem with the following YAML:
spring:
profiles:
active:
- local
- test
I would recommend consuming the active profiles using Environment.getActiveProfiles(). Similarly, for other properties that may have multiple values, binding to a @ConfigurationProperties class with an array, set, or list property is a more robust approach.
If you have any further questions, please follow up on Stack Overflow or Gitter. As mentioned in the guidelines for contributing, we prefer to use GitHub issues only for bugs and enhancements.
Comment From: MangKyu
@wilkinsona
Thanks for your reply.
I already know about Environment.getActiveProfiles() and @ConfigurationProperties but this is not the case.
My situation is like below. @ActiveProfiles cannot resolve my logging path.
logging:
config: classpath:${spring.profiles.active}/log4j2.yml
I would rather using another way. thanks.
Comment From: wilkinsona
I don't think you should use spring.profiles.active in that way as it won't work for multiple values, irrespective of how they're configured. Profile-specific logging configuration looks like a better option. As I said above, if you have any further questions, please follow up on Stack Overflow or Gitter. As mentioned in the guidelines for contributing, we prefer to use GitHub issues only for bugs and enhancements.