[
https://issues.apache.org/jira/browse/THRIFT-512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12711680#action_12711680
]
Bryan Duxbury commented on THRIFT-512:
--------------------------------------
I agree with Todd that resetting the transport under the protocol seems a
little sketchy.
If your goal is to log operations, then why not make a wrapper transport that
just hangs on to a copy of everything? It seems like it would be a lot simpler
than rewinding or something like that.
A wrapper transport of some kind could come from a factory. In order to make
the factory stuff unconfusing in relation to TNonblockingServer, we could
always just wrap the user provided factory with a framed one.
> Implement TProtocol.setTransport()
> ----------------------------------
>
> Key: THRIFT-512
> URL: https://issues.apache.org/jira/browse/THRIFT-512
> Project: Thrift
> Issue Type: Improvement
> Components: Library (Java)
> Affects Versions: 0.1
> Reporter: T Jake Luciani
> Priority: Minor
>
> I'm working on a Rewindable or Peek transport that delegates to a base
> transport and buffers the read/write data for access later to the raw stream.
>
> I'm also using TNonblockingServer that currently requires a
> TFramedTransport.Factory()
> Rather than change TNonblockingServer to accept a TTransportFactory, it may
> be safer to allow TProtocol.setTransport(TTransport t) so I can just swap out
> the protocol in the Processor before it starts to read/write.
> I think if someone wanted to use spring they would need this call too.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
