Closed spring-projects-issues closed 12 years ago
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/* ?
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}.
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.
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.
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
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?
Arjen Poutsma commented
Scott, do you have any examples of paths that are wrongly mapped?
Arjen Poutsma commented
Fixed.
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:
10035
@RequestMapping
best match gives wrong Controller method when using wildcards ("is duplicated by")10401
@Controller
method order effects@RequestMapping
behavior in ways not expected10593 REOPENED -PathVariable mappings are greedy over hard coded mappings
12183 Synchronization in AnnotationMethodHandlerAdapter
Referenced from: commits https://github.com/spring-projects/spring-framework/commit/4108927b28a00d4918e2852f09c8bde10c3fd0bb, https://github.com/spring-projects/spring-framework/commit/c7d1d3ccb87cb46f718424a2d71c28d5fa4b004c