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

Comment From: 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.

Comment From: 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);
        }
    }

Comment From: 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.

Comment From: somayaj

Can this be worked? Also, is there an agreement on the direction on what the solution should be?

Comment From: wilkinsona

Thanks for the offer. As shown by the comments above, we're not yet sure how to fix this one.

Comment From: somayaj

Andy, is there a good way to know which issues are available to be worked on? I've been trying to see if I can contribute to the bug fixes mainly here. But i'm not sure which ones are available to be worked on. Would help if you can guide.

On Sun, Oct 18, 2020 at 2:06 AM Andy Wilkinson notifications@github.com wrote:

Thanks for the offer. As shown by the comments above, we're not yet sure how to fix this one.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/spring-projects/spring-boot/issues/4929#issuecomment-711126922, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIRAZGKKMRUR2YVYW37OEZDSLKHWTANCNFSM4BYMUT4Q .

Comment From: wilkinsona

As you've already contributed (thanks again for that), unassigned issues labelled ideal-for-contribution are probably your best bet. This search will show all such issues that are currently open.

Comment From: somayaj

Thanks, why can't I contribute towards the other open bugs? Is that available for internal work by the spring team only?

Asha

On Sun, Oct 18, 2020 at 1:06 PM Andy Wilkinson notifications@github.com wrote:

As you've already contributed (thanks again for that), unassigned issues labelled ideal-for-contribution are probably your best bet. This search https://github.com/spring-projects/spring-boot/issues?q=is%3Aopen+label%3A%22status%3A+ideal-for-contribution%22+no%3Aassignee+ will show all such issues that are currently open.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/spring-projects/spring-boot/issues/4929#issuecomment-711344737, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIRAZGIXEDWO36ALUWOLZZTSLMVD5ANCNFSM4BYMUT4Q .

Comment From: wilkinsona

Is that available for internal work by the spring team only?

No, not at all. As I said above, the issues labelled as ideal for contribution are your best option. They're not your only option. However, please note that we only have a limited amount of time to guide someone through a contribution. Issues labelled as ideal for contribution are ones that we think a contributor will probably be able to tackle on their own. If other issues fall into that category for you and you're interested in fixing/implementing them, we'd be happy to review a pull request.

Comment From: somayaj

Thanks Andy, this helps.

On Mon, Oct 19, 2020 at 1:59 AM Andy Wilkinson notifications@github.com wrote:

Is that available for internal work by the spring team only?

No, not at all. As I said above, the issues labelled as ideal for contribution are your best option. They're not your only option. However, please note that we only have a limited amount of time to guide someone through a contribution. Issues labelled as ideal for contribution are ones that we think a contributor will probably be able to tackle on their own. If other issues fall into that category for you and you're interested in fixing/implementing them, we'd be happy to review a pull request.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/spring-projects/spring-boot/issues/4929#issuecomment-711705731, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIRAZGKMYUDHPKMEW2VEMJTSLPPTNANCNFSM4BYMUT4Q .