[
https://issues.apache.org/jira/browse/THRIFT-746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12852473#action_12852473
]
Mathias Herberts commented on THRIFT-746:
-----------------------------------------
The primary use case is to be able to have a generic pool for Thrift service
clients. The way I do it so far is to have all services extend a base service
(PoolableThriftService), but this won't work when you have to use an external
thrift idl file. So the first thing I need is to have all services (actually
their Client inner class, but might do it for Iface also) inherit from a common
ancestor. The second thing I use right now is indeed reflectivity to create new
instances of Clients (via getConstructor(TProtocol.class).newInstance(...)),
but also access to getInputProtocol/getOutputProtocol to check that the
underlying transports are open (this is my default way of checking pooled
client validity).
I guess I could modify my patch in the following way:
1. Make TService abstract with two abstract methods
getInputProtocol/getOutputProtocol
2. Create interface TServiceClientFactory with methods getClient(TProtocol) and
getClient(TProtocol,TProtocol) that return TService instances.
How does that sound?
> Generated services Iface/Client inner classes do not derive from base classes
> -----------------------------------------------------------------------------
>
> Key: THRIFT-746
> URL: https://issues.apache.org/jira/browse/THRIFT-746
> Project: Thrift
> Issue Type: Improvement
> Components: Compiler (Java)
> Affects Versions: 0.2
> Environment: All
> Reporter: Mathias Herberts
> Attachments: TService.patch, TServiceClient.patch,
> TServiceClient.patch-2
>
>
> When defining a service in Thrift, the generated code looks like
> public class Service {
> public interface Iface {
> ...
> }
> public static class Client {
> ...
> }
> }
> This makes it quite hard to create generic classes which accept any kind of
> Client or Iface as a parameter. One such use case is the pooling of Client
> objects.
> One way to circumvent this is to create a top level thrift service and have
> all other services extend it, but then there will be no coherency across the
> thrift community.
>
> What about introducing a TService class:
> public class TService {
> public interface Iface {}
> public static class Client {
> public Client(TProtocol prot) { this(prot,prot); }
> public Client(TProtocol iprot, TProtocol oprot) {}
> }
> }
> and have generated services inherit from it:
> public class Service {
> public interface Iface extends TService.Iface {
> }
> public static class Client extends TService.Client {
> }
> }
> As a bonus I'll contribute the pooling mechanism I've created for Bibale
> (based on GenericObjectPool).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
