my dog learned polymorphism*
The moose likes Web Services and the fly likes What is the best way to debug REST calls not matching your expected settings Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Java » Web Services
Bookmark "What is the best way to debug REST calls not matching your expected settings" Watch "What is the best way to debug REST calls not matching your expected settings" New topic
Author

What is the best way to debug REST calls not matching your expected settings

Nathaniel Mills
Greenhorn

Joined: Aug 01, 2008
Posts: 3
I have developed JAX-RS REST services that run fine in WebSphere but when I attempt to move them to Tomcat, they are not being routed to the service class. The catalina*.logs don't show any errors and show the class was loaded (e.g., web.xml is correct) and even shows the stem for the class in an INFO message claiming the server has registered the JAX-RS resource class X with @Path(/v1/) so the class was loaded and interpreted.

This is based on using the Apache Wink JAX-RS implementation v1.2

Is there a preferred way to turn on expanded logging or debugging to help catch the incoming message and determine why it doesn't match the filters established by the @Consumes (for the media type) or @Path statements. In my case I used an @Path for the class to specify the version of the service (v1) and for each method, extended the @Path for the actual service being requested (e.g., @Path("/create/Actor") so the URI would be host:port/display-name/url-pattern/v1/create/Actor with the body of the request containing the information needed to perform the POST. It would be great if I could define a Java environment variable to increase logging output or to have the application framework (apache wink) dump what was received and/or its maps used for matching URI content so we could understand why the incoming request wasn't routed to our code.

As an aside, I've noticed if you specify media type APPLICATION_FORM_URLENCODED (application/x-www-form-urlencoded) that it will eat the requestBody by reading it to find @FormParam's without resetting the input stream to the original mark (so your receiving application can not review what was actually sent... you can only see what you hoped to find). It would be great if they reset the inputstream after reading it so we could still read its content if desired for debugging purposes (e.g., to see why what was sent didn't match the string we'd provided in the @FormParam).
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: What is the best way to debug REST calls not matching your expected settings