Jersey里面对message body reader/writer的匹配，以及对tracing logger的相关实现
ReaderInterceptorExecutor里面的proceed(...)方法对MsgTraceEvent.RI_BEFORE和RI_AFTER的使用：
org.glassfish.jersey.message.internal.ReaderInterceptorExecutor.proceed().png
下面是ReaderInterceptorExecutor的class diagram：
可以看到它包含一个inner class叫做TerminalReaderInterceptor，这个class里面的aroundReadFrom(...)方法还包含了MsgTraceEvent.MBR_FIND的记录：
所以说，实现这些和reader/writer/interceptor相关tracing events的工作，是个细致活，有很多地方要加入tracing events进行记录。
RESTEasy这边各个classes里面的aroundReadFrom(...)方法都是传入ReaderInterceptorContext的instance：
ReaderInterceptorContext的通用实现是AbstractReaderInterceptorContext，它里面的proceed()方法是需要tracing的地方：
AbstractReaderInterceptorContext有两个扩展classes，分别是ClientReaderInterceptorContext和ServerReaderInterceptorContext：
其中ServerReaderInterceptorContext含有HttpRequest：
client这边不含HttpRequest，可以后续考虑专门的机制来获取tracing logger。
回到Jersey这边，以下是InterceptorExecutor的class diagram：
在InterceptorExecutor当中，可以看到对tracing logger的使用方法：
上面的方法被用在ReaderInterceptorExecutor和WriterInterceptorExecutor的proceed(...)方法当中：
RESTEasy这边的内部接口设计与实现完全不同，需要独立考虑。