There's been a longstanding desire for some mechanism to match path variables including slash characters in @RequestMapping templates. The existing workarounds all seem to boil down to grabbing the HTTP request object and manually re-parsing the path.
In my own specific case, I have a hierarchy of parameterized static content that essentially dispatches to views based on the path but needs to set up some model attributes first. This seems to be a common use case and currently requires multiple-mapping hacks.
It would be very helpful to have a mechanism to explicitly specify that a path variable should match internal slash characters, perhaps as an extension of the var:regex syntax (can't include braces there).
Path variables have always worked as variables within a path segment. I'm afraid changing that assumption, even with new syntax, is likely to lead to subtle side effects for any code that relies on the map containing path variables such as matrix variables, redirect URL building, etc. It also raises questions for how this applies to other places where URI variables are used (the c:url tag, UriComponentsBuilder, etc).
Is this something you find commonly needed across an application (i.e. in multiple controllers) or is it a specific place where it's needed? Based on the use case -- i.e. a resource serving handler -- it sounds more like the latter. If that is the case then perhaps doing a little extra work in the controller is acceptable. It's possible to encapsulate that work into a HandlerMethodArgumentResolver but it's not worth it if it's only needed in one or two places.
I'm aware that this would need to be an explicit opt-in, but this is a use case that's been repeatedly looked for over nearly a decade (IIRC, Google hits for searches such as "Spring MVC slash path" went back to 2005). At a minimum, I don't see why the match for ** (which works) can't be passed as a path variable.
Hm, where do I begin? How would you even match the "**" to an @PathVariable method parameter? Normally we use the URI template variable name. Trivial questions aside I mentioned specific areas of the code that access the path variables map. For example the RedirectView inserts parsed path variables and encodes slashes according to path segment rules. Now we'd have to somehow determine whether a path variable is within a path segment or not in order to encode correctly. The support for matrix variables parses path variable values and would also run into similar problems. And it's not simply our code that may rely on the path variables map that could suddenly break.
As for your reference to Google hits, you'll need to be a little more specific. It's a rather general topic (slashes in URL paths) that is much broader than this specific use case. Hence my request for comments from anyone with use cases where something like this is needed across an application.
In the mean time as I said a custom HandlerMethodArgumentResolver is a very feasible route on the application level. It's a little harder to imagine on the framework level not because it's hard to write but because we have to give it a specific name and for that I need to see more use cases to understand what it is exactly that we are adding. Hence my request for more use cases.
I'm happy to consider specific suggestions but I don't think expanding the role of @PathVariable is the way to go.
In most of the cases I've seen, the need for the slash match would be met by being able to capture the group matched by the existing Ant wildcard \*\*, and the logic for mapping to the argument resolver seems to be universal. What about having either a parameter on @PathVariable or an @PathWildcard that would map an argument using the match group for \*\*?
Hmm, looks like the Atlassian markup renderer uses a rather simplistic parser... I think I have it fixed now.
This is precisely what I meant. It's easy to create an argument resolver for a "**" within an application where it meets a specific use case but within a framework we need to consider cases where "**" might appear more than once for example. Furthermore my minimum requirement for a new @MVC annotation is that it should be something that occur commonly across an application and would cause repetition otherwise. I just don't see this in that category.