[
https://issues.apache.org/jira/browse/THRIFT-5164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17134372#comment-17134372
]
Serhii Kanin commented on THRIFT-5164:
--------------------------------------
[~fishywang] it is not a problem to retrieve a data from TProtocol, the
question is how to parse it, parsing logic is autogenerated for every argument.
so your suggestion is to have a switch/case for every method?
argument creation works like this:
{code:java}
//autogenerated code, DIFFERENT for EVERY server method
func (p *ServiceMethodProcessor) Process(ctx context.Context, seqId int32,
iprot, oprot thrift.TProtocol) (success bool, err thrift.TException) {
args := Argument{} // this argument object contains all the logic to PARSE a
data from iprot. This is a basic implementation of bridge pattern.
//args.Read contains list of calls to iprot, this calls are different for every
autogenerated argument
if err = args.Read(iprot); err != nil {
iprot.ReadMessageEnd()
x := thrift.NewTApplicationException(thrift.PROTOCOL_ERROR, err.Error())
oprot.WriteMessageBegin("arg", thrift.EXCEPTION, seqId)
x.Write(oprot)
oprot.WriteMessageEnd()
oprot.Flush(ctx)
return false, err
}
//interceptors are HERE, working with prepared arguments.
res, err2 := p.opts.Interceptor(ctx, "argument", args, func(ctx
context.Context, arg interface{}) (result interface{}, err error) {
return p.handler.processCall(ctx, arg.(Argument).TArgs_)
})
{code}
I hope this simple snippet explains the problem.
[~jensg] it's already here [PR|https://github.com/apache/thrift/pull/1992]
> 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)
