Spring MVC selects the wrong controller method

Question

In my application, I have a situation where spring mvc sequentially selects the wrong controller method to execute. the debug log from spring below shows the problem, it finds two matches, one for my general purpose, processes the entire unhanded display controller that maps to /api/** , and one for the actual thing I'm looking for api/companies/2/records/cabinets/FileTypes/50/1 spring mvc then selects the /api/** handler for the more specific handler that it found.

My understanding of spring is that if there are two matches for matching requests, then spring will choose a descriptor method with a longer URL. Why does spring mvc choose a shorter display?

Given the following mappings:

• /api/companies/{id}/records/cabinets/FileTypes/{fileTypeId}/{versionId} associated with method1
• /api/** mapped to method2

And the api/companies/2/records/cabinets/FileTypes/50/1 path, which spring mvc should choose as the handler method for the two above URLs.

here the corresponding lines form the debug log.

 17:58:49,858 DEBUG [DispatcherServlet] DispatcherServlet with name 'main' processing PUT request for [/web/api/companies/2/records/cabinets/FileTypes/50/1] 17:58:49,858 TRACE [DispatcherServlet] Testing handler map [org.springframework .web.servlet.mvc.method.annotation.RequestMappingHandlerMapping@ 2b25f2be] in DispatcherServlet with name 'main' 7:58:49,858 DEBUG [RequestMappingHandlerMapping] Looking up handler method for path /api/companies/2/records/cabinets/FileTypes/50/1 17:58:49,859 TRACE [RequestMappingHandlerMapping] Found 2 matching mapping(s) for [/api/companies/2/records/cabinets/FileTypes/50/1] : [{[/api/**],methods=[PUT],params=[],headers=[],consumes=[],produces=[],custom=[]}, {[/api/companies/{id}/records/cabinets/FileTypes/{fileTypeId}/{versionId}],methods=[PUT],params=[],headers=[],consumes=[],produces=[],custom=[]}] 

Answer 1

This is really a mistake (see here and here ).

I believe the mapping takes into account the number of brackets in the first expression:

 /api/companies/{id}/records/cabinets/FileTypes/{fileTypeId}/{versionId} ^-- ^-- ^-- 

Since the first has three brackets (patterns), and the second has only one pattern ( ** ), the first is considered more general.

Workaround:

Since * and /* are evaluated equally, try making the second expression instead of /api/** , for example:

 /api/**/**/**/** 

It has four patterns, making it "more general" than the other. In practice, this is equivalent to /api/** . This will make him appreciate at last.

Since this somewhat “lightweight” workaround exists, I believe the bug will be fixed for a long time if it ever is.

Answer 2

I can reproduce the behavior that you see. So your behavior is related to two mappings:

. /api/companies/{id}/records/cabinets/FileTypes/{fileTypeId}/{versionId}

. /api/**

the request /api/companies/2/records/cabinets/FileTypes/50/1 corresponds to the second path.

I tried a slightly different way:

. /api/companies/{id}/records/cabinets/FileTypes

. /api/**

with the request /api/companies/2/records/cabinets/FileTypes , this time around the first matches up!

I think this is a mistake, I would recommend submitting a ticket to the Spring JIRA website.