Actuator with management.port takes the same WebMvcConfigurerAdapter

[kadkaz]

The WebMvcConfigurerAdapter will be executed methods twice (addViewControllers, addResourceHandlers) if you use management.port = 9251 (for instance). There are two application contexts and they use the same WebMvcConfigurerAdapter.

That's why the same urls does not work. if you have rest api with /health for example.

I guess the good solution is don't give management (Actuators) use WebMvcConfigurerAdapter.
or found the solution to filter it out form Actuators.

server:
  port: 9250
  address: 0.0.0.0
  context-path: /path
  session-timeout: 300
management:
  port: 9251
  address: 0.0.0.0
  addApplicationContextHeader: false
  context-path: /
  security:
    enabled: false
    role: ADMIN

[wilkinsona]

This isn't straightforward to straighten out. The current implementation relies on WebMvcAutoConfiguration.WebMvcConfigurationAdapter being found from the parent so that, for example, spring.jackson.* configuration properties affect the Actuator's JSON output. This means that we can't simply ignore configurers from the parent context.

[wilkinsona]

One (gross?) possibility:

    /**
     * Configuration equivalent to {@code @EnableWebMvc} that only allows Spring Boot's
     * own WebMvcConfigurers to be used, preventing application configurers in the parent
     * context from leaking into the child management context.
     */
    @Configuration
    public static class ManagementWebMvcConfiguration
            extends DelegatingWebMvcConfiguration {

        @Override
        @Autowired(required = false)
        public void setConfigurers(List<WebMvcConfigurer> configurers) {
            List<WebMvcConfigurer> filtered = new ArrayList<WebMvcConfigurer>(
                    configurers);
            Iterator<WebMvcConfigurer> iterator = filtered.iterator();
            while (iterator.hasNext()) {
                if (!iterator.next().getClass().getName()
                        .startsWith("org.springframework.boot")) {
                    iterator.remove();
                }
            }
            super.setConfigurers(filtered);
        }
    }

[wilkinsona]

Another possibility, suggested by @snicoll:

Split a normal Boot application into a parent that contains all of Spring Boot's beans and a child that contains the beans configured by the user. The management context would then be a sibling of the child context and therefore would no longer inherit any beans configured by the user.