You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@thrift.apache.org by "Todd Lipcon (JIRA)" <ji...@apache.org> on 2009/05/21 07:34:45 UTC
[jira] Commented: (THRIFT-512) Implement TProtocol.setTransport()
[ https://issues.apache.org/jira/browse/THRIFT-512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12711469#action_12711469 ]
Todd Lipcon commented on THRIFT-512:
------------------------------------
Personally I prefer the design of having TNonblockingServer take a factory. Allowing the transport to change underneath a protocol seems like a dangerous operation. I'm not sure I entirely understand your use case, but couldn't this be achieved by fully wrapping a transport without any lib code changes?
> 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.