How do you create an instance of message knowing message "type"?
I do know my message type, I just cannot figure out how to create a
Message without having an instance of service object.
The "right" way is to call
"getRequestPrototype"/"getResponsePrototype" on service instance,
which I'd like to
> transport you, probably, don't care, but I'm implementing my own
> transport using asynchronous AMQP protocol. And channel encapsulates
We use the Type parameter available in the message properties
(rabbitmq) to indicate what sort of GPB message is encoded in the
request/response. This seems to
The purpose on RpcChannel is to implement physical wire data transfer
for your service. If you use one of existing implementations of
transport you, probably, don't care, but I'm implementing my own
transport using asynchronous AMQP protocol. And channel encapsulates
sender and listener functionali
On Wed, Feb 24, 2010 at 9:59 AM, ph wrote:
> On the high level I have a wrapper for RpcChannel implements
> transport.
RpcChannel's only reason for existence is for creating stub objects, and
those stubs already know what type of messages to use. Why are you writing
something else that "wraps"
On the high level I have a wrapper for RpcChannel implements
transport. Inside transport I need to parse response. To do that I
need and instance of service.
To create an instance of service (stub) I need to provide and instance
of channel to it. So, my service depends on channel and channel
depend
The way this is intended to work is that you should have a pointer to the
Service object and call its getRequestPrototype() method. I don't
understand why you would need to decode requests without having a Service
object for which they are destined.
On Tue, Feb 23, 2010 at 8:56 PM, ph wrote:
>
Thanks
It looks like there is no elegant way to solve my issue.
In short, I have a transport implementation to use with PB RPC
service.
Service definitions are built-in and I need to convert byte array to
Message inside my transport. I know what service transport handles and
I have method name.
Se
(But to answer your question: Compiled-in types are almost always faster
than DynamicMessage.)
On Tue, Feb 23, 2010 at 4:27 PM, Kenton Varda wrote:
> I'm not sure how your approach works, but since it looks like you're using
> Java reflection, my guess is that it will only work with compiled-in
I'm not sure how your approach works, but since it looks like you're using
Java reflection, my guess is that it will only work with compiled-in
services. If your code is a library, this will prevent users of that
library from using dynamic types, which is unfortunate. If the users
provide a defau
Thanks Kenton,
I was using getRequestPrototype, but I need an actual instance of
Service to call that method that created additional extra dependency
in my code that why I started to look for alternatives. I know my
method name and currently I'm just parsing response (byte array) this
way (in Scal
10 matches
Mail list logo
