Nathaniel Mills

Greenhorn
+ Follow
since Aug 01, 2008
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Nathaniel Mills

By placing a file named logging.properties in the webapps/myappl/WEB-INF/classes directory you can control logging for your web application. In my case, I added one with lines like this (that causes a timestamped log file starting with myapp in the <catalina_home>/logs directory.

handlers = org.apache.juli.FileHandler, java.util.logging.ConsoleHandler

############################################################
# Handler specific properties.
# Describes specific configuration info for Handlers.
############################################################

org.apache.juli.FileHandler.level = FINE
org.apache.juli.FileHandler.directory = ${catalina.base}/logs
org.apache.juli.FileHandler.prefix = myapp.

java.util.logging.ConsoleHandler.level = FINE
java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter
org.apache.wink.level = ALL
11 years ago
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).
11 years ago
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).
11 years ago