Is Spring's @Profile on methods a good practice

问题

I have a Spring Boot Web application exposing rest services.

I'm asking myself how to correctly manage profiles on Filters. Actually, my app has 2 profiles: dev and prod (you guess what it stands for...)

In prod mode, i have more filters to activate than in dev mode.

My Filters configuration class is the following:

@Configuration
public class FiltersConfig {

    @Bean
    public FilterRegistrationBean filterRegistrationBean(CompositeFilter compositeFilter){
        FilterRegistrationBean filterRegistrationBean = new FilterRegistrationBean();
        filterRegistrationBean.setDispatcherTypes(EnumSet.allOf(DispatcherType.class));
        filterRegistrationBean.addUrlPatterns("/*");
        filterRegistrationBean.setFilter(compositeFilter);
        return filterRegistrationBean;
    }

    @Bean
    @Profile("dev")
    public CompositeFilter devCompositeFilter(){
        CompositeFilter compositeFilter = new CompositeFilter();
        List<Filter> filtersList = new ArrayList<>();
        //filtersList.add(filter1());
        compositeFilter.setFilters(filtersList);
        return compositeFilter;
    }


    @Bean
    @Profile("prod")
    public CompositeFilter prodCompositeFilter(){
        CompositeFilter compositeFilter = new CompositeFilter();
        List<Filter> filtersList = new ArrayList<>();
        //filtersList.add(filter1());
        compositeFilter.setFilters(filtersList);
        return compositeFilter;
    }
}

My questions are:

Is it a good practice to add @Profile on method?
Is there a way to force the compiler to exclude classes, methods, etc. annotated with a diferent profiles than the one set as current? (I don't want my production jar/war populated with unnecessary code!)
Does spring boot provide a clearer way to organize profiles?

thx.

回答1:

I think it would be better to have configurations for different environments in distinct packages. You don't want to mix your configuration. The structure might look like this:

config
    - Config1.java
    - Config2.java
    dev
        - WebConfig.java
        - DataConfig.java
    prod
        - WebConfig.java
        - DataConfig.java

回答2:

In my own experience, using @Profile in any java code is not a good idea. This is why I think you have to avoid using it in the code:

You can always define property like my.feature-for-the-profile.enabled to achieve the same goal by using profile.
Profiles diverge sometimes, keep every changing configuration as properties give you more control on everything, everywhere.
Spring Boot has a well defined profile-specific externalize properties support (like application-prod.yml). Having profile in you code base will make things more complicated and sometimes misleading.
You can modify or override by using properties more easily than update and recompiling your code.
ProfileCondition (as meta-annotation on @Profile) is not a SpringBootCondition, you can not use /autoconfig to determine is it activated or not.

The bottom line: Define profiles for properties, not for @Configurations nor @Beans.

If you really want to exclude test stuff for your production code, take a look on the documentation of spring-boot-devtools, if your using Maven, you can put all test classes/resources in a separate module, and mark its as <optional>true</optional> or define maven profile for it. Notice, having maven profile and spring boot profile at the same time maybe confusing!

回答3:

Is it a good practice to add @Profile on method?

It is the spring approach to this problem - so it is in keeping with the spring ecosystem

Is there a way to force the compiler to exclude classes, methods, etc. annotated with a diferent profiles than the one set as current? (I don't want my production jar/war populated with unnecessary code!)

You would have to tune your build to exclude classes - another approach is to configure the beans with id's, and use the ID's and configuration per environment. An approach similar to to

In my experience Profiles are easier