Jersey里面对message body reader/writer的匹配,以及对tracing logger的相关实现

ReaderInterceptorExecutor里面的proceed(...)方法对MsgTraceEvent.RI_BEFORERI_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,分别是ClientReaderInterceptorContextServerReaderInterceptorContext

其中ServerReaderInterceptorContext含有HttpRequest

client这边不含HttpRequest,可以后续考虑专门的机制来获取tracing logger。

回到Jersey这边,以下是InterceptorExecutor的class diagram:

InterceptorExecutor当中,可以看到对tracing logger的使用方法:

上面的方法被用在ReaderInterceptorExecutorWriterInterceptorExecutorproceed(...)方法当中:

RESTEasy这边的内部接口设计与实现完全不同,需要独立考虑。