This week's book giveaway is in the Cloud/Virtualization forum.
We're giving away four copies of Building Blockchain Apps and have Michael Yuan on-line!
See this thread for details.
Win a copy of Building Blockchain Apps this week in the Cloud/Virtualization forum!
  • 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 all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Paul Clapham
  • Liutauras Vilda
  • Knute Snortum
  • Bear Bibeault
  • Devaka Cooray
  • Jeanne Boyarsky
  • Junilu Lacar
Saloon Keepers:
  • Ron McLeod
  • Stephan van Hulst
  • Tim Moores
  • Carey Brown
  • salvin francis
  • Tim Holloway
  • Piet Souris
  • Frits Walraven

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

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).
I'm not sure if I approve of this interruption. But this tiny ad checks out:
Java file APIs (DOC, XLS, PDF, and many more)
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!