Details
-
Sub-task
-
Status: Closed
-
Major
-
Resolution: Fixed
-
1.4.0
Description
Right now, a RpcGateway is only implicitly coupled to a RpcEndpoint by specifying it a s type argument and having the RpcCompletenessTest watching that the endpoint implements all methods of the gateway.
This makes it possible that the endpoint and the gateway can have slightly different interfaces. E.g. the gateway defines a method which returns a Future<Integer> whereas this method is implemented by the endpoint as a method which returns Integer. This underlines the fact that the endpoint method call is synchronous whereas the gateway issues an asynchronous call.
The downside is that it is very cumbersome to establish type hierarchies among RpcEndpoints. Thus, it is not easily possible to extend a specific RcpEndpoint to add testing RPCs, for example. Moreover, you rely on the RpcCompletenessTest to catch all not implemented methods instead of relying on the compiler.
I think in the long run, it would be better to let the RpcEndpoints directly implement the RpcGateways because the benefits of being able to extend RpcEndpoints outweigh the benefits of the current approach.
Attachments
Issue Links
- links to
