@RequestMapping best match gives wrong Controller method when using wildcards [SPR-5362]

[spring-projects-issues]

Antony Bowesman opened SPR-5362 and commented

Reference forum message http://forum.springsource.org/showthread.php?t=64011

Given the following two methods in a Controller

@RequestMapping(value="/rest/mail/v1/ipm/*", method=RequestMethod.GET)
public ModelAndView Method1()

@RequestMapping(value="/rest/mail/v1/ipm/*/**", method=RequestMethod.GET)
public ModelAndView Method2()

Given the request path /rest/mail/v1/ipm/JA8AAAAAAAAAKwAB4awBIfRXAeRU it matches the first method, but then chooses the second path as a BETTER match, resulting in the wrong method being called. This is because of the simplistic implementation of isBetterPathMatch() that decides that a longer length path is a better match regardless of the number of elements in the path.

This occurs in AnnotationMethodHandlerAdapter.ServletHandlerMethodResolver.isBetterPathMatch. It clearly does not take account of the extra / in the second path, which is not present in the given URL.

Although it is possible to make a workaround which involves having a single method, where the code then makes decisions based on the request path, it complicates Controller implementations forcing different sets of business logic to be combined.

---

Affects: 2.5.6

Issue Links:

• PathVariable mappings are greedy over hard coded mappings [SPR-5367] #10040 PathVariable mappings are greedy over hard coded mappings ("duplicates")
• REOPENED -PathVariable mappings are greedy over hard coded mappings [SPR-5924] #10593 REOPENED -PathVariable mappings are greedy over hard coded mappings ("duplicates")

Referenced from: commits 721f2ca

[spring-projects-issues]

Arjen Poutsma commented

This should be fixed in 3.0 M2.