Support AND operator in @Profile annotation [SPR-12458]

[spring-projects-issues]

Artem opened SPR-12458 and commented

As of v4.1.2 @Profile annotation does not support AND operator, being OR by definition.

This significantly limits it's applicability in our project since we have profiles: PROD, TEST, CONFIG1, CONFIG2, etc. And we want to have beans autowired based in PROD && CONFIG1 style to be able to setup config1 in production and TEST && CONFIG1 to setup same profile for test.

The good example would be config being MQENABLED profile. Which in case of production will be set on @Configuration class with RabbitTemplate bean configuration, but for test we want to have our own implementation of AmqpTemplate (instead of RabbitTemplate).

---

Affects: 4.1.2

Issue Links:

• @Profile should be able to define profiles to accomplish the 'and' scenario [SPR-15634] #20193 @Profile should be able to define profiles to accomplish the 'and' scenario ("is duplicated by")
• Improve testability of new Profiles support [SPR-16962] #21500 Improve testability of new Profiles support
• Profile activation: not operator does not work consistently [SPR-16465] #21010 Profile activation: not operator does not work consistently
• @Profile mishandles "not" operand mixed with "&" [SPR-17606] #22138 @Profile mishandles "not" operand mixed with "&"
• Support inclusive profiles [SPR-13939] #18511 Support inclusive profiles

18 votes, 30 watchers

[spring-projects-issues]

Vladimir Rozhkov commented

+1 for this. Had to write simple condition matcher to get job done:

public class AndProfilesCondition implements Condition {

    public static final String VALUE = "value";
    public static final String DEFAULT_PROFILE = "default";

    @Override
    public boolean matches(final ConditionContext context, final AnnotatedTypeMetadata metadata) {
        if (context.getEnvironment() == null) {
            return true;
        }
        MultiValueMap<String, Object> attrs = metadata.getAllAnnotationAttributes(Profile.class.getName());
        if (attrs == null) {
            return true;
        }
        String[] activeProfiles = context.getEnvironment().getActiveProfiles();
        String[] definedProfiles = (String[]) attrs.getFirst(VALUE);
        Set<String> allowedProfiles = new HashSet<>(1);
        Set<String> restrictedProfiles = new HashSet<>(1);
        for (String nextDefinedProfile : definedProfiles) {
            if (!nextDefinedProfile.isEmpty() && nextDefinedProfile.charAt(0) == '!') {
                restrictedProfiles.add(nextDefinedProfile.substring(1, nextDefinedProfile.length()));
                continue;
            }
            allowedProfiles.add(nextDefinedProfile);
        }

        for (String nextActiveProfile : activeProfiles) {
            if (DEFAULT_PROFILE.equals(nextActiveProfile) && allowedProfiles.isEmpty()) {
                continue;
            }
            if (!allowedProfiles.contains(nextActiveProfile) || restrictedProfiles.contains(nextActiveProfile) || allowedProfiles.size() != activeProfiles.length) {
                return false;
            }
        }
        return true;
    }

}

It will be nice to have expressions support in @Profile annotation.

[spring-projects-issues]

Stephen Bellchester commented

We are developing a spring boot application to run in WebSphere, with our test suite running in Jetty using @WebIntegrationTest.
We would like to be able to specify some beans (eg transaction managers) to be different between environments that run in Websphere, and those running on Jetty.
As the set of environments that are not running on WebSphere is the smaller and more static of the two, the neatest way to do this would be something like the following, which is currently not possible.

@Bean
@Profile({"!lcl && !ci"})
public JtaTransactionManager transactionManager() {
    return new WebSphereUowTransactionManager();
}

[spring-projects-issues]

Martin Wegner commented

I would use the acceptsProfiles() method for the condition implementation:

public class ProfileAndCondition implements Condition {

  @Override
  public boolean matches(final ConditionContext context, final AnnotatedTypeMetadata metadata) {
    final Environment contextEnvironment = context.getEnvironment();

    if (contextEnvironment == null) {
      return true;
    }

    final MultiValueMap<String, Object> allProfileAnnotations = metadata
        .getAllAnnotationAttributes(Profile.class.getName());

    if (allProfileAnnotations == null) {
      return true;
    }

    final List<?> allProfileAnnotationValues = allProfileAnnotations.get("value");

    if (allProfileAnnotationValues == null) {
      return true;
    }

    for (final Object value : allProfileAnnotationValues) {
      final String[] neededProfiles = (String[]) value;

      for (final String neededProfile : neededProfiles) {

        if (!contextEnvironment.acceptsProfiles(neededProfile)) {
          return false;
        }

      }

    }

    return true;
  }

}

[spring-projects-issues]

Juergen Hoeller commented

Indeed, implementing a custom condition along those lines is what I would recommend at this point.

As for 4.3, it's primarily a design question: How to express 'and' semantics in @Profile itself? Custom parsing of expressions would go a bit far... It might be more appropriate to introduce an enum on the annotation, indicating 'and' vs 'or' semantics for multiple profiles specified. In combination with making @Profile repeatable, this would deliver quite an amount of expressiveness already. Everything beyond that I would rather leave to custom programmatic condition implementations.

Juergen

[spring-projects-issues]

Sam Brannen commented

FWIW, @Profile can already be repeated when declared as a meta-annotation on multiple composed annotations (even though it's not technically a repeatable annotation).

[spring-projects-issues]

Juergen Hoeller commented

In the meantime, I'll rather leave this up to 5.0, along with other condition-related fine tuning there.

[spring-projects-issues]

Jared Jacobs commented

Spring Boot assumes AND semantics are desired when negated profiles are combined with non-negated profiles:

If both negated and non-negated profiles are specified for a single document, at least one non-negated profile must match and no negated profiles may match.

— Spring Boot Reference Guide 24.6.3

I wish @Profile would behave the same way. This is the only situation where I’ve ever needed AND semantics.

[spring-projects-issues]

Juergen Hoeller commented

Stéphane Nicoll, assigning this to you for further consideration... in particular in alignment with Boot 2.0.

[spring-projects-issues]

DJ Kulkarni commented

We have a similar requirement and our solution was to have a @Repeatable(Profiles.class) @Profile which otherwise has the same implementation as that of org.springframework.context.annotation.Profile

 
Then @Profiles does an AND while the default behavior for @Profile remains OR .
 
So now we can do-

@Profile("p1")
@Profile({"p2","p3")
@Bean

Which translates to-
p1 AND (p2 OR p3)

[spring-projects-issues]

Sam Brannen commented

That sounds like an elegant custom solution, DJ Kulkarni.

[spring-projects-issues]

Juergen Hoeller commented

Indeed... Let's consider rolling a variant of this into 5.1.

[spring-projects-issues]

Eric Deandrea commented

Let me see if our company rules allow us to contribute our solution back (DJ works with me...).

[spring-projects-issues]

Phil Webb commented

See also spring-projects/spring-boot#12469 in case we want to align solutions.

[spring-projects-issues]

Phil Webb commented

FWIW the multiple @Profile approach won't be much use for spring-projects/spring-boot#12469. That may or may not sway the design but I'd personally prefer it if the same syntax could be used in the @Profile annotation and the application.properties file.

I was thinking something like a simple + might do the trick. e.g:

@Profile("p1", "p2+p3")

Of course, that could break back compatibility if an existing profile happened to have a + in it.

[spring-projects-issues]

Stéphane Nicoll commented

FWIW, I don't like the repeatable approach because its semantic isn't as explicit as a profile expression. I wonder how likely + is going to be used in a profile name.