Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

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

Nathaniel Mills
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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).
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!