Hello SpringBoot's developers 😀

description :
In the configuration file, if both 【spring.mvc.static-path-pattern】 and 【spring.web.resources.static-locations】 are configured, the Welcome Page ability is invalidated

cause : WelcomePageHandlerMapping's construction method of judging condition : if (welcomePage != null && "/**".equals(staticPathPattern))


Among them : "/**".equals(staticPathPattern) I think can be customized by users If this code is removed, the Welcome Page can be used So I think this code can be changed by the user


I think there are two ways. 1、Add @ConditionalOnMissingBean on WelcomePageHandlerMapping in EnableWebMvcConfiguration 2、Just remove 【 && "/**".equals(staticPathPattern) 】in WelcomePageHandlerMapping's construction

Now I'm going to take approach one :)

I'm glad to participate in the contribution of the project ! Hope my code can be incorporated into the project ❤❤❤

Comment From: pivotal-cla

@chenjjiaa Please sign the Contributor License Agreement!

Click here to manually synchronize the status of this Pull Request.

See the FAQ for frequently asked questions.

Comment From: pivotal-cla

@chenjjiaa Thank you for signing the Contributor License Agreement!

Comment From: chenjjiaa

Hello, when will the classification be completed? 👋👋👋

Comment From: wilkinsona

Thanks for your patience, @chenjjiaa. The team is focused on our 3.0 release at the moment. We will triage this pull request as soon as we can

Comment From: wilkinsona

Thanks for the proposal, @chenjjiaa, and for your patience while we found time to review it.

WelcomePageHandlerMapping is package-private and final. That means that it can't be caused to back off by defining a custom bean of the same type. I guess this is why you've defined a name in your proposed condition. We try to avoid "magic" bean names so I'm not keen on doing this either.

The check for staticPathPattern being /** was added to fix https://github.com/spring-projects/spring-boot/issues/8788. We cannot remove it without regressing that fix.

Unfortunately, for the reasons above, I don't think we should make either of the changes proposed here. Thanks anyway for the PR.