4

I have an application, for which I can specify the profiles I want to run it on. but I also want to group these profiles into things like credentails, application performance, memory-print, application behaviour etc. Ex. I can run the following profiles

-Dspring.profiles.active=production,cached-local,db-connection-pooled...

but I would prefer initializing it as

-Dspring.profiles.active=production,super-fast
#the above activates method level caches, db connection pooling etc
#super-fast triggered activation of cached-local, db-connection-pooled profiles

or

-Dspring.profiles.active=dev,low-footprint
#the above dosent enable caching, or db connection pooling

can this be achieved without writing any custom code like How to set active spring 3.1 environment profile via a properites file and not via an env variable or system property. I am fine even if I can load these from properties files or inside spring-xml config. I am using xml only config on spring 3.1.

Community
  • 1
  • 1
user918953
  • 173
  • 1
  • 2
  • 9

2 Answers2

2

Spring Boot have since added functionality to address this problem, called "Profile Groups". A profile group allows you to define a logical name for a related group of profiles.

For example, we can create a production group that consists of our proddb and prodmq profiles.

This allows for a grouping to be defined, which is added to the spring-profiles-active, which when enabled, in turn, enables other profiles.

For more information see https://docs.spring.io/spring-boot/docs/current/reference/html/features.html#features.profiles.groups

abh
  • 422
  • 6
  • 16
0

I don't know of any way to achieve this without custom code which would manipulate the active profiles in a ConfigurableEnvironment.

We're trying to achieve the same indirection pattern as rights vs. roles (group of rights) in a security framework, but since this doesn't come out of the box, I ended up having to work around it.

I kept my profiles general, e.g. production and super-fast in your case, and for each bean that is sensitive to those profiles, I set the correct @Profile. To make refactoring easier, I used two techniques.

  1. Create a meta-annotation for each profile, e.g. @Production, @SuperFast and make the profile name a public constant, e.g. Production.PROFILE_NAME = "production".
  2. When marking the profile of any bean, use your new meta-annotation if it only applies to one profile, or use @Profile({Production.PROFILE_NAME, ...}) if it applies to multiple profiles. You have to do this because you can't apply two profile meta-annotations to the same bean, at least not until 4.0.

For example,

@Profile(Production.PROFILE_NAME)
public @interface Production {

    public static String PROFILE_NAME = "production";
}

The point of all this is that you can now use your IDE to look for usages of @Production or Production.PROFILE_NAME if you need to quickly understand or change what beans are being pulled in.

Emerson Farrugia
  • 11,153
  • 5
  • 43
  • 51