[
https://issues.apache.org/jira/browse/THRIFT-5164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17134321#comment-17134321
]
Serhii Kanin commented on THRIFT-5164:
--------------------------------------
[~fishywang] with middleware we don't have an access to request and response,
that's the thing because the code that creates arguments from input protocol is
autogenerated for every service method this is a reason why it was implemented
as an interceptor. We also don't like the approach to alter compiler's logic
but we need to provide request and response logging for every call.
GRPC solution to provide logging (close to PR we provided):
[https://github.com/grpc-ecosystem/go-grpc-middleware/blob/master/logging/logrus/payload_interceptors.go#L33]
Middleware does not fit our needs, we still use our fork.
> Go middleware support
> ---------------------
>
> Key: THRIFT-5164
> URL: https://issues.apache.org/jira/browse/THRIFT-5164
> Project: Thrift
> Issue Type: Improvement
> Components: Go - Library
> Reporter: Yuxuan Wang
> Assignee: Duru Can Celasun
> Priority: Major
> Labels: Breaking-Change
> Fix For: 0.14.0
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> I saw that this idea was discussed before in THRIFT-4553, but want to reopen
> the discussion to see if there's a change of mind.
> We (Reddit) recently implemented TProcessor level middleware support in our
> Baseplate.go library, and we think that our implementation is generic enough
> that it might make sense to contribute that into the thrift library. The
> related implementation are all in this file:
> https://github.com/reddit/baseplate.go/blob/4225e42dc8dde56b222ac7ea3a4ff63aa726f6a6/thriftbp/middlewares.go
> https://github.com/reddit/baseplate.go/blob/4225e42dc8dde56b222ac7ea3a4ff63aa726f6a6/tracing/middlewares.go#L40-L64
> is an example of how a tracing middleware is implemented.
> If we think that's a good idea, then we can contribute that into thrift repo
> (with renames, of course). One implementation detail I'm not sure is that
> whether we want to expand the TProcessor interface to also include
> ProcessorMap and AddToProcessorMap, or do we want to keep the two iinterfaces
> separate.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
