PathVariable mappings are greedy over hard coded mappings [SPR-5367]

[spring-projects-issues]

Scott Andrews opened SPR-5367 and commented

Hard coded request mapping values should take precedence over path variables. Wild card patterns in a path are currently inferior to explicit values. Path variables should be applied after explicit paths and before wild cards.

For example:

@RequestMapping(value = "/resources/new/", method = RequestMethod.GET)
is currently trumped by
@RequestMapping(value = "/resources/{resourceName}/", method = RequestMethod.GET)

@RequestMapping(value = "/resources/new/", method = RequestMethod.GET)
currently trumps
@RequestMapping(value = "/resources/*/", method = RequestMethod.GET)

@RequestMapping(value = "/resources/new/", method = RequestMethod.GET)
should trump
@RequestMapping(value = "/resources/{resourceName}/", method = RequestMethod.GET)
should trump
@RequestMapping(value = "/resources/*/", method = RequestMethod.GET)

---

Affects: 3.0 M1

Issue Links:

• @RequestMapping best match gives wrong Controller method when using wildcards [SPR-5362] #10035 @RequestMapping best match gives wrong Controller method when using wildcards ("is duplicated by")
• @Controller method order effects @RequestMapping behavior in ways not expected [SPR-5731] #10401 @Controller method order effects @RequestMapping behavior in ways not expected
• REOPENED -PathVariable mappings are greedy over hard coded mappings [SPR-5924] #10593 REOPENED -PathVariable mappings are greedy over hard coded mappings
• Synchronization in AnnotationMethodHandlerAdapter [SPR-7525] #12183 Synchronization in AnnotationMethodHandlerAdapter

Referenced from: commits 4108927, c7d1d3c

[spring-projects-issues]

Arjen Poutsma commented

Currently, /resources/{resourceName} is considered to be equally greedy to /resources/*, and I wonder how we can differentiate between the two.

In other words: Which requests should be mapped to /resources/{resourceName}, and which to /resources/* ?

[spring-projects-issues]

Scott Andrews commented

Good point. It is essentially a programmer error to have two otherwise identical mappings contain /resources/{resourceName} and /resources/*. Although, if the system were to choose a mapping, my preference would be for the URI variable mapping over the pure wildcard. It is more important for /resources/new to take precedence over /resources/{resourceName}.

[spring-projects-issues]

Nicolas Spilman commented

I would agree with Scott that for me I would like to see the mapping be more explicit first and then choose the more generic match.

For example, if I have a controller like:

public class TeamController {

@RequestMapping(value = "/fantasyfootball/teams/all")
public String allTeams() {}

@RequestMapping(value = "/fantasyfootball/teams/{teamId}")
public String getTeam(@PathVariable("teamId") String teamId) {}

}

and I make a request to:

/fantasyfootball/teams/all

It will currently go to the getTeam() method with teamId = "all" instead of the allTeams() method.

Thanks.

[spring-projects-issues]

Scott Andrews commented

I again seeing templated paths take precedence over hard coded paths with 3.0.4. The behavior is intermittent, and only occurs for 5-10% of requests.

I have temporarily worked around this issue by providing a regex pattern for the path variable so that it will never match the fixed value.

[spring-projects-issues]

Juergen Hoeller commented

I have no idea where such a regression would come from at this point. In any case, would be great to sort this out for 3.0.5...

Juergen

[spring-projects-issues]

Arjen Poutsma commented

I have no idea either. AFAIK, the mapping code wasn't touched in 3.0.4.

Scott, do you have any examples of paths that are wrongly mapped?

[spring-projects-issues]

Arjen Poutsma commented

Scott, do you have any examples of paths that are wrongly mapped?

[spring-projects-issues]

Arjen Poutsma commented

Fixed.