How to log the MessageBodyReader used for a Web Service Call in Apache TomEE+ - jax-rs

Question

I own a few web services in a large code base. I see several custom MessageBodyReaders attached to my application.
I would like to know which one is used for a web service call.
I've looked around, but I can't seem to find a way to log that.

Answer 1

Your question is somewhat broad and therefore hard to answer. I'll try it anyways.
You have multiple services with multiple MessageBodyReader<>s, maybe distributed across several applications. While CXF itself supports tracing and message logging, there isn't a switch you can just turn on to see which MessageBodyReader implementations are readable and which not.
1. Approach - Adding logging to the implementing classes
One might think this is a good idea, and yes it is! On first sight.
Adding log outputs to every isReadable(..) method on every implementing class would solve your issue but is not practical, as it involved way too much manual logging and code changes.
2. Approach - AOP to the rescue!
Aspect Oriented Programming specifically addresses issue like that. You want to take actions (logging) over several classes and even log out, what happened in that classes. Those requirements are aspects as they don't add functionality to your classes, but to your program on a technical point of view.
It basically involves adding proxies around the isReadable(..) method on every MessageBodyReader implementation and log out whether it returned true or false.
Let's start
Assume a simple MessageBodyReader<InputStream> like the example I took from the CXF online documentation:
#Consumes("application/octet-stream")
#Provider
public class MyReader implements MessageBodyReader<InputStream> {
#Override
public boolean isReadable(Class<?> aClass, Type type, Annotation[] annotations, MediaType mediaType) {
return return (type == MyEntity.class);
}
public InputStream readFrom(Class<InputStream> clazz, Type t, Annotation[] a, MediaType mt,
MultivaluedMap<String, String> headers, InputStream is) throws IOException {
return new FilterInputStream(is) {
#Override
public int read(byte[] b) throws IOException {
return is.read();
}
};
}
}
To reach this class and every other implementation, we create an Advice with the following Pointcut:
execution(public boolean javax.ws.rs.ext.MessageBodyReader+.isReadable(..))
For the sake of simplicity we will just log out what was returned. Using Spring AOP this is ridiculously easy. We just use the #AfterReturning annotation:
#Slf4j
#Component
#Aspect
public class MyReaderLoggerAspect {
#AfterReturning(value = "execution(public boolean javax.ws.rs.ext.MessageBodyReader+.isReadable(..))", argNames = "joinPoint,called", returning = "called")
public void logReaderName(JoinPoint joinPoint, boolean called) {
log.info(String.format("MessageBodyReader %s executed: %s", joinPoint.getTarget().getClass().getName(), called));
}
}
And our logging output looks like:
2020-07-06 17:56:04.305 INFO 9204 --- [ restartedMain] o.s.b.w.embedded.tomcat.TomcatWebServer : Tomcat started on port(s): 8080 (http) with context path ''
2020-07-06 17:56:04.313 INFO 9204 --- [ restartedMain] com.example.demo.DemoApplication : Started DemoApplication in 2.424 seconds (JVM running for 3.676)
2020-07-06 18:02:03.480 INFO 9204 --- [ scheduling-1] c.e.demo.test.MyReaderLoggerAspect : MessageBodyReader com.example.demo.test.MyReader executed: false
2020-07-06 18:03:44.191 INFO 9204 --- [ scheduling-1] c.e.demo.test.MyReaderLoggerAspect : MessageBodyReader com.example.demo.test.MyReader executed: true
2020-07-06 18:03:44.192 INFO 9204 --- [ scheduling-1] c.e.demo.test.MyReaderLoggerAspect : MessageBodyReader com.example.demo.test.MyOtherReader executed: false
This is an easy approach to log out possible candidates for MessageBodyReaders and other automagically invoked implementation classes. You can even log out method parameters, change the invocation, and do much more.
What's next?
You may of course want to add a few more logging to your Advices, because the class name and a simple true or false won't fit real-world-needs, but this is a good starting point on putting some manual tracing to existent software architectures.
Mentioning Tracing - that's only a few steps from using common solutions like OpenTracing in your services. While it generally focuses on identifying bottle necks and issues in long chains of service calls, it would generally allow to answer questions like:
Why is this request taking so long?
What filter is involved in that call chain? <-- You are here
Where is this message processor involved?
Who would be affected by a major change in my service?
And so on