You could also use something like UrlRewrite Filter to map all your routes, converting path parameters to query parameters using regular expressions.

http://tuckey.org/urlrewrite/

I don't believe URLRewriteFilter does provide the ability to set query parameters.

http://tuckey.org/urlrewrite/manual/3.0/index.html#configuration

You can set attributes in the request but the docs do not indicate that you can set parameters. Of course, it would be a possible feature using the same approach as Alex's Filter. UrlRewriteFilter does already wrap the request and response which is where you would add this feature.

I'm trying to use this as a filter so to continue using my command bean setup with with the REST-style URLs.

However, it seems that when passing multiple parameters like in the example: /view/c/save/2342443, each of them end up with a trailing slash except the last one.

So using the example from above, a call to cmd.getController() would return "save/" instead of just "save" and cmd.getId() would return "2342443".

I'm wondering if you can replicate this behaviour or if something that I'm doing wrongly...but it seems pretty straight-forward...

I tried to use the ParameterizedUrlHandlerMapping with a simple mapping like "/user/(*\:user)/found" but strangely that sets user to "stefan/" when I request "/user/stefan/found".

You could try something like:

<rule>
  <from>^/world/([a-z]+)/([a-z]+)$</from>
  <to>/world.jsp?country=$1&city=$2</to>
</rule>

To Stefan and Alon:
I had made an error in the dispatcher configuration in this post. The line "<prop key="/view/c/(*:controller)/(*:id)">controller5</prop>" used to have back slashes before the colons. It's necessary to escape the colons if you use the <property name="mappings"><value>prop1=value1</value></property> syntax, but not if you use the <property name="mappings><props><prop key="...">...</prop></props><property> syntax. If you escape the colons in the latter syntax, parameters taken from within the path will have a slash appended. I'm not sure exactly why. I would expect that escaping the colon would either behave identically or cause it to miss the parameter altogether. Anyway, sorry about the mistake. It's been corrected in the text.

To Kim:
I agree that a regexp-based rule syntax would be superior, but I want this to be a drop-in extension to spring's URLHandlerMapping (or at least as close as possible). Its important that developers not have to configure their mappings in two different places, and I want to use the existing spring functionality for the actual routing of requests. These requirements led me to the current set of classes. Given these constraints, the only real flexibility in syntax is in the way we map a segment of the ant style path pattern to a parameter name. Thanks for the suggestion though.

This looks like an interesting approach to implementing REST-ful urls.

One question -- I didn't see a LICENSE.txt in the svn repository. Is this code available for use by the general public?

Excellent point, Dave. I've just checked in an Apache 2.0 style license to the project and included it within each of the class files. Hopefully this makes adoptable by anyone that has a need for it.

Hi ...

Is it worked correctly to anyone? I am stuck at compilation itself at ParameterizedUrlHandlerMapping class.

...
Map handlerMap = (Map) getHandlerMap();

...

It complaits that it cannot find the getHandelerMap() method.

Please any insights ,,,

Thanks
Vin

Hi Vin,
This is almost certainly a problem with your Spring MVC dependency. Either you're missing the Spring jars altogether, or you have an older version with a different API (one in which SimpleUrlHandlerMapping has no getHandlerMap() method). The jars are available at http://www.springframework.org . If you are going to compile the stand-alone java files, you are also going to need the servelet API in your classpath. Hope this helps - alex.

Alex. Thanks! Works great. Only problem is the ParameterizedPathFilter did not work for us, since the handler is a Controller subclass so request does not go back through the RequestDispatcher. Tell Don I say hello!

I used a small HandlerAdapter in place of the Filter:
public class ParameterizedUrlHandlerAdapter extends SimpleControllerHandlerAdapter implements HandlerAdapter {

public ModelAndView handle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
if (request.getAttribute(ParameterizedUrlHandlerMapping.PATH_PARAMETERS) != null) {
request = new ParameterizedPathServletRequest(request);
}
return super.handle(request, response, handler);
}
}

Hi Steve,
I'm glad you found a solution that works for you. I considered using a HandlerAdapter instead of a filter. It's much cleaner, but it only wraps the controller, not the view, so the additional parameters won't be available to the JSP (or whatever technology you're using). You should note that the request does not need to go back through the filter after processing by the Dispatcher servlet. So long as it hit the filter before the dispatcher servlet, the request wrapper will add the parameters as soon as the magic attribute is set. Thanks for your contribution.

Logan is down it seems. I am trying to get the source to look at it. Could you check what's going on?
Would you be so kind to email me the source otherwise?
Thank you much!

This sounds like a great utility, but there seems to be something wrong with the svn server. Specifically, when I click on the download link in the article, it says:

"logan.carbonfive.com has sent an incorrect or unexpected message. Error Code: -12263"

Can I get the code somewhere else?

Ah, yes. SVN now has a dedicated server so the URL has changed. I fixed the links in the post above.

Thanks for this. It has made my job incredibly easier.

I just wanted to say that if you want this to work with annotated controllers and @RequestMapping annotations then you should change the ParameterizedUrlHandlerMapping class to extend DefaultAnnotationHandlerMapping from the spring library instead. This simple change will allow you to use requestmappings and requestparam annotations.

Thanks again for this.

I'd love to figure out how to use this. Maybe I am missing something..

I want to use urls like:

http://mydomain.com/mywebapp/1/2/3/4/5/6/7/8/10
http://mydomain.com/mywebapp/search/somename/someaddress

and so on.

Seems I can't figure out how to allow a single controller handle all cases where it can just get ALL the values aftert the initial /mywebapp context.

I am still learning Spring, very confused with the variety of bean wiring required. Honestly Struts seemed easier to just specify the action class, bean(s), and go. But Spring has so much industry interest I want to learn it.

So can you point out how I might set a controller in the mywebapp-servlet.xml file so that I can just get the list of values after the webapp context name, and do with them as needed?

Thank you.

We had a problem while using the c:param tag of our jsp's. The parameters were not getting set onto the request correctly. So we changed the getParameterValues() method in the ParameterizedPathFiler to get it to set these parameters. This is our new method.

@Override
public String[] getParameterValues(String string) {
String[] values = parameters.get(string);
if(values != null && values.length > 0) {
return values;
}

return super.getParameterValues(string);
}

Other than this, the code works wonderfully! Thanks :)