В io.grp c .internal.AbstractServerImplBuilder вы можете добавить реализации ServerInterceptor в окончательный список
final List<ServerInterceptor> interceptors = new ArrayList<>();
, затем в реализации сервера по умолчанию для построителя - io.grp c. internal.ServerImpl он вызывает их в foreach l oop
/** Never returns {@code null}. */
private <ReqT, RespT> ServerStreamListener startCall(ServerStream stream, String fullMethodName,
ServerMethodDefinition<ReqT, RespT> methodDef, Metadata headers,
Context.CancellableContext context, StatsTraceContext statsTraceCtx, Tag tag) {
// TODO(ejona86): should we update fullMethodName to have the canonical path of the method?
statsTraceCtx.serverCallStarted(
new ServerCallInfoImpl<>(
methodDef.getMethodDescriptor(), // notify with original method descriptor
stream.getAttributes(),
stream.getAuthority()));
ServerCallHandler<ReqT, RespT> handler = methodDef.getServerCallHandler();
for (ServerInterceptor interceptor : interceptors) {
handler = InternalServerInterceptors.interceptCallHandler(interceptor, handler);
}
ServerMethodDefinition<ReqT, RespT> interceptedDef = methodDef.withServerCallHandler(handler);
ServerMethodDefinition<?, ?> wMethodDef = binlog == null
? interceptedDef : binlog.wrapMethodDefinition(interceptedDef);
return startWrappedCall(fullMethodName, wMethodDef, stream, headers, context, tag);
}
, поэтому он выполняет цепочку перехватчиков от последнего зарегистрированного до первого при получении запроса. Такой же порядок соблюдается при ответе обработчика.
Что я удивляюсь и ожидаю, так это то, что он будет следовать шаблону промежуточного программного обеспечения лука, и вы можете явно установить порядок выполнения (аналогично фильтрам сервлетов). Я что-то упускаю?