• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

REST request mapping parameter type differentiation

 
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I hope cross posting only applies to different section in the same site, as I have asked this already here: http://forum.spring.io/forum/spring-projects/container/738867-rest-request-mapping-parameter-type-differentiation

I have a controller that has two request mappings, one that takes a long and the other a string.
The request mapping path is identical, differentiated only by the type of the path variable.

ie:
/{Long}
vs
/{String}


On some systems this works. I fact it made it through QA without a hitch. Now, we're seeing problems where all requests to this URL are dispatched to the Long variant and this throw on the string to long conversion.

On some systems I get:

curl -s -3kL qa4:8080/content-manager/api/category/Entertainment
....
Error 500 Failed to convert value of type 'java.lang.String' to required type 'java.lang.Long'; nested exception is org.springframework.core.convert.ConversionFailedException: Unable to convert value "Entertainment" from type 'ja
va.lang.String' to type 'java.lang.Long'; nested exception is java.lang.NumberFormatException: For input string: "Entertainment"
....

whereas others running the exact same build interpret the "Entertainment" string as a string and do not force it into the Long method.

My primary question is 'why is the above request being dispatched to the Long variant rather than the String one?'
My other question is 'why would this behavior differ between systems?'

There is zero difference between the installed wars and jetty config.
 
Bartender
Posts: 1682
7
Android Mac OS X IntelliJ IDE Spring Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Not sure how much narrowing Spring will do on type alone. I know the documentation does specify to use only simple type like long, int, Date etc. with @PathVariable. It stands to reason that is should be smart enough to handle your scenario, but if its not it may just be a crap shoot on how it decides to order the matches on the result, or the order the classes are loaded on initialization (could be container specific). Try using a primitive long instead of Long and see if that makes a difference. Primitives I am fairly certain are treated down a different conditional branch then other objects.

Alternatively try to use regex which is matched a little differently. Something like this:



I would have to look at the source to see exactly how it all works to give you a definitive answer but those are a couple things to try for clearing up ambiguities.

*Edit - Oh and cross posting across sites is fine as long as you do what you did and link the other post. This prevents people from wasting time answering an already answered question.
 
Bruce Edge
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Bill. That was helpful. I tried the regex pattern to add a bit more specificity to the Long method and it worked fine on my dev VM, but failed on other hosts. It's the inconsistency of it all that's really puzzling. Same war, jvm, jetty, OS, etc. These are automated deployments so they don't vary from env to env other than local config data.

I ended up remapping the methods to non-conflicting URLs as this whole thing was too unpredictable to have any level of confidence.
 
Bill Gorder
Bartender
Posts: 1682
7
Android Mac OS X IntelliJ IDE Spring Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Bruce,

That certainly sounds like the safest bet for now.

It would be great if you could create an issue on the Spring issue tracker for this. It is simple to do and they are quick to respond to those. I guess I did not ask you which version of Spring you are you using, is it a fairly current one? If you are using the old HandlerMapping class due to older versions of the Spring jars on the classpath of the prod servers (perhaps in a shared library) this could be the cause of the problems. The logic behind RequestMapping changed quite a bit with version 3.1.

In any event barring the scenario I described above (version mismatch across environments) Spring advertises that code should behave the same deployed to any environment, so it should work the same across all of them. This looks like a bug. In the event this type of scenario is not supported the user should see an ambiguous mapping exception the same as you do when you map two methods with identical RequestMappings.

You can find the issue tracker here:
https://jira.springsource.org/secure/Dashboard.jspa

If you do post an issue it would be great if you could post the link here, so we could follow it as well.

Thanks
Bill

 
Bruce Edge
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
We're on a pretty old version of spring, 3.0.5, so it would not be relevant if the mapping changed substantially for 3.1.
Upgrading to a newer spring version is another topic that no one's had the time to commit to.
I've made a note in the code to re-test this once we do upgrade to a current spring release.
Thanks again for your help.
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic