-Dspring.profiles.active breaks @ActiveProfiles

[lrozek]

No description provided.

[snicoll]

Could you please provide a better description for your issue? Duplicate of #1095 ?

[lrozek]

here is reproduction for this:
https://github.com/lrozek/spring-boot-1109

When Dspring.profiles.active is set then application-${profile}.properties isn't picked up by @activeprofiles

please run to get failing test:
mvn clean test -Dspring.profiles.active=someProfile

[snicoll]

You may have tried this without boot and noticed it would work as you expected but that's actually an issue, see SPR-8982.

spring.profiles.active overrides the list of active profiles, which is why your application-test.properties is not read. If you want to add one, you have to use spring.profiles.include.

That is already properly covered in the documentation

[lrozek]

hello,

thank you for such a quick response.

However, I have a follow-up questions:

1. shouldn't than
   assertThat( environment.getActiveProfiles(), hasItemInArray( "test" ) )
   fail in first place?

2. after removing @activeprofiles("test") in
   lrozek/spring-boot-1109@819d528
   I executed mvn clean test -Dspring.profiles.include=test
   It still failed.

3. This one is indirectly related to the topic. What is a more straightforward approach to override certain properties in tests using boot?

• @IntegrationTEST does the trick, but I think property file is more desired
• @activeprofiles("test") and /src/test/resources/application-test.properties also works

However, with boot attempt to simplify things as most as possible I expected that just dropping application.properties in scr/test/resources would do the thing out of the box. Unfortunately, it seems that spring picks up the first one found in a classpath. In my case it was in fact src/test/resources/application.properties, completely ignoring src/main/resources/application.properties.

Thank you for your support

[snicoll]

As a general rule, it would be best to post your question on StackOverflow with the spring-boot tag.

1. Please look at the SPR issue. It should take that override into account but it doesn't. Profile is not a boot specific feature.
2. Again, look at the documentation. It states it is a property. We agree here that it's a bit strange you can't override that by some other means. Feel free to raise an issue for that.
3. I would not rely on classpath ordering and overriding resources with the same location is just going to be hard to understand. You already found the ways to do this, profile is probably best if you have several things to tune.

[lrozek]

thank you for your answers