Ability to assign wildcard path to PathVariable [SPR-14032]

[spring-projects-issues]

Laplie Anderson opened SPR-14032 and commented

Currently, the way to get the wildcard part of a request mapping is a bit cumbersome:

@RequestMapping("/somePrefix/{element}/**")
public void myAction(@PathVariable String element, HttpServletRequest request) {
	    String path = (String) request.getAttribute(HandlerMapping.PATH_WITHIN_HANDLER_MAPPING_ATTRIBUTE);
	   // do some path manipulation here
	   // do actual work
}

It would be nicer if we could just have the element assigned directly:

@RequestMapping("/somePrefix/{element}/{**}")
public void myAction(@PathVariable String element, @PathVariable String wildcard) {
	  // do actual work
}

---

Issue Links:

• Wildcard mapping for path segments at the end of a @RequestMapping [SPR-14193] #18766 Wildcard mapping for path segments at the end of a @RequestMapping

[spring-projects-issues]

Rossen Stoyanchev commented

I can see the case but harder to see a more generalized solution. The wildcard variable doesn't have a name, what if it came in a different part of the mapping (beginning or middle), could you have more than one in the same mapping, etc?

The actual work required to do this yourself is actually not that bad. It could be extracted into a method, even a static utility method, something like:

@RequestMapping("/somePrefix/{element}/**")
public void myAction(@PathVariable String element, HttpServletRequest request) {
    String wildcardPath = extractWildcardPath(request, element);
	   // do actual work
}

private static String extractWildcardPath(HttpServletRequest request, String key) {
    int index = request.getRequestURI().indexOf(key);
    return request.getRequestURI().substring(index + key.length());
}

It would also be trivial for you to create and register your own HandlerMethodArgumentResolver that does the above that may not be general enough for any application that you can imagine but meets your specific needs.

[spring-projects-issues]

Laplie Anderson commented

I know it's just a couple lines of code for matching the end, but becomes a bit more if you're trying to match multiple wildcards.

To give a little background, I first tried to solve this using regular expressions. Regular Expressions do allow you to give names to the pattern you're matching against:

@RequestMapping("/somePrefix/{element}/{wildcard:.*}")
public void myAction(@PathVariable String element, @PathVariable String wildcard) {
}

However, regular expressions only match on one part of the path so "/somePrefix/e1/a/b" would not match using "/somePrefix/{element}/{wildcard:.*}"

I guess a general solution would be to allow Ant-style wildcards to be named in the same way that regular expressions can be named currently. That would solve the problem and be consistent with an already used paradigm.

[spring-projects-issues]

Rossen Stoyanchev commented

The curly brace syntax has been in use for URI variables which span one segment. If we re-use the same syntax for named ant-style patterns, we are adding a degree of complexity, since now what looks like a URI variable can actually span multiple segments. There are potential ripple effects in places such as MvcUriComponents and others where we read request mapping patterns. Or we could create a new syntax but that brings similar concerns.

Beyond the given example above which is easy to solve within the application, request mapping patterns with more than one double wildcard seems rather odd and far from common. I just don't see a benefit that makes up for the added complexity.