Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mapping with multiple DispatcherServlets in child contexts seems broken #23761

Closed
fdw opened this issue Oct 19, 2020 · 10 comments
Closed

Mapping with multiple DispatcherServlets in child contexts seems broken #23761

fdw opened this issue Oct 19, 2020 · 10 comments
Assignees
Labels
status: duplicate A duplicate of another issue

Comments

@fdw
Copy link

fdw commented Oct 19, 2020

Affects: 5.2.9 (possibly earlier)

We are building a REST application with Spring Boot.
Because we have several endpoints that behave similarly (but with different parameters), we build several child contexts, each with one DispatcherServlet, under different urlMappings (for example, /fish/* and /cat/* with one @RequestMapping /feed each). Until some versions ago, this worked fine.
With the update to 5.2.9, however, these endpoints return 404 errors. Debugging seems to hint that the RequestMapping is not found because the request contains the path fish/feed while the RequestMappingHandlerMapping only knows about /feed. (According to our debuggin, the UrlPathHelper has alwaysUseFullPath set to true. We don't know why or how.)
We register the DispatcherServlet like this:

val dispatcherServlet = DispatcherServlet()
dispatcherServlet.setApplicationContext(applicationContext)

return ServletRegistrationBean(
  dispatcherServlet,
  "/<cat|fish>/*"
)

What do we need to set so that the original mapping works again? We have not found anything in the documentation or the changelogs that seems to impact the mapping.

@jhoeller jhoeller changed the title Mapping with multiple DispatcherServlerts in child contexts seems broken. Mapping with multiple DispatcherServlets in child contexts seems broken Oct 19, 2020
@jhoeller
Copy link

@rstoyanchev, could this be related to spring-projects/spring-framework#25864 in the sense of another side effect of our 5.2.9 revision there?

@rstoyanchev
Copy link
Contributor

rstoyanchev commented Oct 19, 2020

I think this is a duplicate of #22682 although it's not clear why you're seeing that with 5.2.9 which presumably means Spring Boot 2.3.4. In any case I don't think it's a change in the Spring Framework that leads to this.

Can you clarify the version of Spring Boot? If you try to vary independently the Spring Framework and Spring Boot versions does that show which version change demonstrates the issue?

@bienenstich
Copy link

The Spring Boot version is 2.3.4, we are going to try varying the versions independently and get back to you.

@fdw
Copy link
Author

fdw commented Oct 20, 2020

We tested Spring Boot 2.3.4 and 2.3.0 with Spring Framework 5.2.9. The result is that the older Spring Boot version works, whereas the new one doesn't. It seems that this is not a regression in Spring Framework (as far as I understand this).

Should we open an issue in Spring Boot?

@bclozel
Copy link
Member

bclozel commented Oct 20, 2020

@fdw Could you create a sample project reproducing the problem?
I'm transferring this issue to the Spring Boot tracker.

@bclozel bclozel transferred this issue from spring-projects/spring-framework Oct 20, 2020
@bclozel bclozel added status: waiting-for-feedback We need additional information before we can continue status: waiting-for-triage An issue we've not yet triaged labels Oct 20, 2020
@bienenstich
Copy link

We built you a minimal sample project that reproduces the behavior described above. To test, please follow the instructions in the README.md file provided here

@spring-projects-issues spring-projects-issues added status: feedback-provided Feedback has been provided and removed status: waiting-for-feedback We need additional information before we can continue labels Oct 21, 2020
@bclozel bclozel self-assigned this Oct 21, 2020
@bclozel bclozel added status: duplicate A duplicate of another issue and removed status: feedback-provided Feedback has been provided status: waiting-for-triage An issue we've not yet triaged labels Oct 21, 2020
@bclozel
Copy link
Member

bclozel commented Oct 21, 2020

Rossen was right, this is indeed a duplicate of #22682 and I'm closing this issue as a result.

As of #21499, Spring Boot auto-configures the UrlPathHelper to use the full path, as recommended by the Spring Framework team. This is done only if there's a single DispatcherServlet instance mapped to "/" (as fixed in #22682).

The problem here is that the unusual setup of your sample application prevents the Spring Boot parent context from detecting the additional DispatcherServlet at the right time.

I'm sure there are valid reasons to use this setup, so the simplest way to fix that is to customize the UrlPathHelper yourself like this:

@Configuration
class WebConfig : WebMvcConfigurer {

    override fun configurePathMatch(configurer: PathMatchConfigurer) {
        val urlPathHelper = UrlPathHelper()
        urlPathHelper.setAlwaysUseFullPath(false)
        configurer.setUrlPathHelper(urlPathHelper)
    }
}

Another way would be to simplify your current setup by:

Thanks!

@bclozel bclozel closed this as completed Oct 21, 2020
@fdw
Copy link
Author

fdw commented Oct 22, 2020

First off, thank you very much for your answer and your help! It's actually been a pleasure 🙂

Secondly, one of the reasons for our unusual setup is that we don't know how many/which child contexts we need: We read a list from a property (using Spring's mechanisms) and create them accordingly. If we understand the docs right, this wouldn't be possible when we use the SpringApplicationBuilder, right?

Do you have any hints for us how we might solve that?

@bclozel
Copy link
Member

bclozel commented Oct 22, 2020

I see, in this case I don't know how to solve that particular problem with an unknown number of child contexts. I don't think the SpringApplicationBuilder approach would work there, you're right.

@fdw
Copy link
Author

fdw commented Oct 22, 2020

Pity, but thanks again for your time and help!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: duplicate A duplicate of another issue
Projects
None yet
Development

No branches or pull requests

6 participants