What is the order of precedence when there are multiple Spring's environment profiles as set by spring.profiles.active

Question

I am just wondering what the order of precedence is when multiple Spring active profiles have been specified.

Say I want the default profile to be active but the dev profile to override it when there are several identical elements (beans for instance) to choose from but with different profiles...

Say for instance I have two PropertySourcesPlaceholderConfigurer beans configured with "default" and "dev" values a environment profiles.

If I use the following profile activation: -Dspring.profiles.active="default,dev"

Will the dev profile override the default one?

If not how can the above behavior be achieved?

Answer 1

The order of the profiles in the spring.profiles.active system property doesn't matter. "Precedence" is defined by the declaration order of the beans, including beans specific to a profile, and the last bean definition wins.

Using your example, if -Dspring.profiles.active="default,dev" is used, the props bean in the default profile would be used here, simply because it's the last active definition of that bean:

<beans profile="dev">     <bean id="props" class="org.springframework.context.support.PropertySourcesPlaceholderConfigurer">         <property name="location" value="classpath:META-INF/dev.properties"/>     </bean> </beans> <beans profile="default">     <bean id="props" class="org.springframework.context.support.PropertySourcesPlaceholderConfigurer">         <property name="location" value="classpath:META-INF/default.properties"/>     </bean> </beans> 

Invert the order of the beans, and then the dev version would be used, regardless of how the profiles are ordered in spring.profiles.active.

Notice that I did not use <context:property-placeholder/> because it does not allow you to explicitly specify a bean id, and so I'm not sure what behavior it would exhibit if more than one is used. I imagine that the properties would be merged, so that properties defined by both would use the last definition, but properties specific to each file would remain intact.

Otherwise, in my experience, you would typically define beans in this order:

1. "Default" bean definitions, not specific to a profile
2. Overriding bean definitions in an environment-specific profile
3. Overriding bean definitions in a test-specific profile

This way, test profile beans would win if used in combination with other profiles; else you would either use environment-specific beans or default beans based on the profile.