[protobuf] Re: Construct return message using Descriptors.ServiceDescriptor
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 avoid, or have a library of default messages, which is not very good solution too. I was trying to use type descriptors, but can't figure out if it's possible to create a message using type descriptor e.g.: serviceDescriptor.findMethodByName ( methodName ).getOutputType.toProto.newBuilderForType.mergeFrom this does not work the I'd hope it'd work... so now I'm using reflection, which works, but I'd like to use my knowledge of type as reflection is not fastest way of creating objects... On Feb 26, 7:53 am, "thatsnotri...@gmail.com" wrote: > > 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 work out well so far. > > Rob -- You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To post to this group, send email to proto...@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
[protobuf] Re: Construct return message using Descriptors.ServiceDescriptor
> 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 work out well so far. Rob -- You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To post to this group, send email to proto...@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
[protobuf] Re: Construct return message using Descriptors.ServiceDescriptor
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 functionality. Also transport (channel) should make sure that response matches request (as protocol is asynchronous). For that I have transaction id field in all my PB packets, therefore transport has to look into packets, so it needs to parse bytes into Message and depending on current method call name that Message has different types. On Feb 24, 10:32 am, Kenton Varda wrote: > 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" RpcChannel? Maybe you should define an > interface called RawRpcChannel instead, which takes ByteStrings instead of > Messages? > > > > > 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 > > depends on service. > > I have multiple channels (pool) I'm using to send/receive each packet. > > If I want to hide my implementation guts, I don't want user to create > > service and then call another method to link that service with channel > > (I don't have access to service from channel). > > This is in nutshell my egg-chicken dilemma. So I want to get rid of > > one of dependencies, and the one I thought about was replacing Service > > implementation with Descriptor... > > > On Feb 24, 12:40 pm, Kenton Varda wrote: > > > 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. > > > > ServiceDescriptor has descriptors of all types I possibly need, but > > > > unfortunately I looks like there is no way to construct message from > > > > byte array having MessageDescriptor (which I can get from > > > > ServiceDescriptor). > > > > > On Feb 23, 7:28 pm, Kenton Varda wrote: > > > > > (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 > > > > > > 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 default instance, then they can choose to provide either > > a > > > > > > compiled-in type or a dynamic type. > > > > > > > On Tue, Feb 23, 2010 at 1:55 PM, ph wrote: > > > > > > >> 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 Scala): > > > > > >> Class.forName ( String.format ( classNameFormat, methodName ) ) > > > > > >> .getDeclaredMethod ( "parseFrom", Array ( msg.getClass ) : > > _* ) > > > > > >> .invoke ( null, Array ( msg ) : _* ).asInstanceOf > > > > > >> [ com.google.protobuf.GeneratedMessage ] > > > > > >> This works fine. I will try to use a Default Message or > > > > > >> DynamicMessage, thanks for suggestion. From the top of your head, > > do > > > > > >> you think DynamicMessage will be faster or slower than my > > approach? > > > > > > >> On Feb 22, 6:10 pm, Kenton Varda wrote: > > > > > >> > Right, Descriptor.toProto() returns a DescriptorProto, which is > > > > itself a > > > > > >> > protobuf type. So, calling newBuilderForType() on that is going > > to > > > > > >> return a > > > > > >> > builder for DescriptorProto, not a builder for the type > > described. > > > > > > >> > What you want is com.google.protobuf.DynamicMessage. > > > > > > >> > Note that DynamicMessage is slower than th
Re: [protobuf] Re: Construct return message using Descriptors.ServiceDescriptor
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" RpcChannel? Maybe you should define an interface called RawRpcChannel instead, which takes ByteStrings instead of Messages? > 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 > depends on service. > I have multiple channels (pool) I'm using to send/receive each packet. > If I want to hide my implementation guts, I don't want user to create > service and then call another method to link that service with channel > (I don't have access to service from channel). > This is in nutshell my egg-chicken dilemma. So I want to get rid of > one of dependencies, and the one I thought about was replacing Service > implementation with Descriptor... > > On Feb 24, 12:40 pm, Kenton Varda wrote: > > 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. > > > ServiceDescriptor has descriptors of all types I possibly need, but > > > unfortunately I looks like there is no way to construct message from > > > byte array having MessageDescriptor (which I can get from > > > ServiceDescriptor). > > > > > On Feb 23, 7:28 pm, Kenton Varda wrote: > > > > (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 > > > > > 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 default instance, then they can choose to provide either > a > > > > > compiled-in type or a dynamic type. > > > > > > > On Tue, Feb 23, 2010 at 1:55 PM, ph wrote: > > > > > > >> 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 Scala): > > > > >> Class.forName ( String.format ( classNameFormat, methodName ) ) > > > > >>.getDeclaredMethod ( "parseFrom", Array ( msg.getClass ) : > _* ) > > > > >>.invoke ( null, Array ( msg ) : _* ).asInstanceOf > > > > >> [ com.google.protobuf.GeneratedMessage ] > > > > >> This works fine. I will try to use a Default Message or > > > > >> DynamicMessage, thanks for suggestion. From the top of your head, > do > > > > >> you think DynamicMessage will be faster or slower than my > approach? > > > > > > >> On Feb 22, 6:10 pm, Kenton Varda wrote: > > > > >> > Right, Descriptor.toProto() returns a DescriptorProto, which is > > > itself a > > > > >> > protobuf type. So, calling newBuilderForType() on that is going > to > > > > >> return a > > > > >> > builder for DescriptorProto, not a builder for the type > described. > > > > > > >> > What you want is com.google.protobuf.DynamicMessage. > > > > > > >> > Note that DynamicMessage is slower than the message classes > produced > > > by > > > > >> > protoc. So if the type in question is actually compiled in to > your > > > app, > > > > >> you > > > > >> > should use it instead. Typically what you'd do is pass around > the > > > > >> type's > > > > >> > default instance (MyMessageType.getDefaultInstance()) instead of > > > passing > > > > >> > around the descriptor. > > > > > > >> > Note that the Service interface also provides a method > > > > >> > getRequestPrototype(MethodDescriptor) which returns the default > > > instance > > > > >> for > > > > >> > the type, on which you can then call newBuilderForType(). > > > > > > >> > On Sat, Feb 20, 2010 at 12:54 PM, ph > wrote: > > > > >> > > I'm trying to build service return message using > > > > >> > > Descriptors.ServiceDescriptor. > > > > >> > >
[protobuf] Re: Construct return message using Descriptors.ServiceDescriptor
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 depends on service. I have multiple channels (pool) I'm using to send/receive each packet. If I want to hide my implementation guts, I don't want user to create service and then call another method to link that service with channel (I don't have access to service from channel). This is in nutshell my egg-chicken dilemma. So I want to get rid of one of dependencies, and the one I thought about was replacing Service implementation with Descriptor... On Feb 24, 12:40 pm, Kenton Varda wrote: > 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. > > ServiceDescriptor has descriptors of all types I possibly need, but > > unfortunately I looks like there is no way to construct message from > > byte array having MessageDescriptor (which I can get from > > ServiceDescriptor). > > > On Feb 23, 7:28 pm, Kenton Varda wrote: > > > (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 > > > > 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 default instance, then they can choose to provide either a > > > > compiled-in type or a dynamic type. > > > > > On Tue, Feb 23, 2010 at 1:55 PM, ph wrote: > > > > >> 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 Scala): > > > >> Class.forName ( String.format ( classNameFormat, methodName ) ) > > > >> .getDeclaredMethod ( "parseFrom", Array ( msg.getClass ) : _* ) > > > >> .invoke ( null, Array ( msg ) : _* ).asInstanceOf > > > >> [ com.google.protobuf.GeneratedMessage ] > > > >> This works fine. I will try to use a Default Message or > > > >> DynamicMessage, thanks for suggestion. From the top of your head, do > > > >> you think DynamicMessage will be faster or slower than my approach? > > > > >> On Feb 22, 6:10 pm, Kenton Varda wrote: > > > >> > Right, Descriptor.toProto() returns a DescriptorProto, which is > > itself a > > > >> > protobuf type. So, calling newBuilderForType() on that is going to > > > >> return a > > > >> > builder for DescriptorProto, not a builder for the type described. > > > > >> > What you want is com.google.protobuf.DynamicMessage. > > > > >> > Note that DynamicMessage is slower than the message classes produced > > by > > > >> > protoc. So if the type in question is actually compiled in to your > > app, > > > >> you > > > >> > should use it instead. Typically what you'd do is pass around the > > > >> type's > > > >> > default instance (MyMessageType.getDefaultInstance()) instead of > > passing > > > >> > around the descriptor. > > > > >> > Note that the Service interface also provides a method > > > >> > getRequestPrototype(MethodDescriptor) which returns the default > > instance > > > >> for > > > >> > the type, on which you can then call newBuilderForType(). > > > > >> > On Sat, Feb 20, 2010 at 12:54 PM, ph wrote: > > > >> > > I'm trying to build service return message using > > > >> > > Descriptors.ServiceDescriptor. > > > >> > > This does not work: > > > >> > > serviceDescriptor.findMethodByName > > > >> > > ( methodName ).getOutputType.toProto.newBuilderForType.mergeFrom > > > >> > > ( msg ).build > > > >> > > "msg" is byte array > > > >> > > It builds DesscriptorProtos.DescriptorProto instead of Message. > > > > >> > > Is there a way to build message from byte array using method > > > >> > > descriptor? > > > > >> > > -- > > > >> > > You received this message because you are subscribed to the Google > > > >> Groups > > > >> > > "Protocol Buffers" group.>> > > To post to this group, send email > >
Re: [protobuf] Re: Construct return message using Descriptors.ServiceDescriptor
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. > ServiceDescriptor has descriptors of all types I possibly need, but > unfortunately I looks like there is no way to construct message from > byte array having MessageDescriptor (which I can get from > ServiceDescriptor). > > > On Feb 23, 7:28 pm, Kenton Varda wrote: > > (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 > > > 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 default instance, then they can choose to provide either a > > > compiled-in type or a dynamic type. > > > > > On Tue, Feb 23, 2010 at 1:55 PM, ph wrote: > > > > >> 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 Scala): > > >> Class.forName ( String.format ( classNameFormat, methodName ) ) > > >>.getDeclaredMethod ( "parseFrom", Array ( msg.getClass ) : _* ) > > >>.invoke ( null, Array ( msg ) : _* ).asInstanceOf > > >> [ com.google.protobuf.GeneratedMessage ] > > >> This works fine. I will try to use a Default Message or > > >> DynamicMessage, thanks for suggestion. From the top of your head, do > > >> you think DynamicMessage will be faster or slower than my approach? > > > > >> On Feb 22, 6:10 pm, Kenton Varda wrote: > > >> > Right, Descriptor.toProto() returns a DescriptorProto, which is > itself a > > >> > protobuf type. So, calling newBuilderForType() on that is going to > > >> return a > > >> > builder for DescriptorProto, not a builder for the type described. > > > > >> > What you want is com.google.protobuf.DynamicMessage. > > > > >> > Note that DynamicMessage is slower than the message classes produced > by > > >> > protoc. So if the type in question is actually compiled in to your > app, > > >> you > > >> > should use it instead. Typically what you'd do is pass around the > > >> type's > > >> > default instance (MyMessageType.getDefaultInstance()) instead of > passing > > >> > around the descriptor. > > > > >> > Note that the Service interface also provides a method > > >> > getRequestPrototype(MethodDescriptor) which returns the default > instance > > >> for > > >> > the type, on which you can then call newBuilderForType(). > > > > >> > On Sat, Feb 20, 2010 at 12:54 PM, ph wrote: > > >> > > I'm trying to build service return message using > > >> > > Descriptors.ServiceDescriptor. > > >> > > This does not work: > > >> > > serviceDescriptor.findMethodByName > > >> > > ( methodName ).getOutputType.toProto.newBuilderForType.mergeFrom > > >> > > ( msg ).build > > >> > > "msg" is byte array > > >> > > It builds DesscriptorProtos.DescriptorProto instead of Message. > > > > >> > > Is there a way to build message from byte array using method > > >> > > descriptor? > > > > >> > > -- > > >> > > You received this message because you are subscribed to the Google > > >> Groups > > >> > > "Protocol Buffers" group.>> > > To post to this group, send email > toproto...@googlegroups.com. > > >> > > To unsubscribe from this group, send email to>> > > > protobuf+unsubscr...@googlegroups.com > > > > > >> > > >> > > . > > >> > > For more options, visit this group at > > >> > >http://groups.google.com/group/protobuf?hl=en. > > > > >> -- > > >> You received this message because you are subscribed to the Google > Groups > > >> "Protocol Buffers" group.>> To post to this group, send email > toproto...@googlegroups.com. > > >> To unsubscribe from this group, send email to>> > protobuf+unsubscr...@googlegroups.com > > > > > >> . > > >> For more options, visit this group at > > >>http://groups.google.com/group/protobuf?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "Protocol Buffers" group. > To post to this group, send email to proto...@googlegroups.com. > To unsubscribe from this group, send email to > protobuf+unsubscr.
[protobuf] Re: Construct return message using Descriptors.ServiceDescriptor
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. ServiceDescriptor has descriptors of all types I possibly need, but unfortunately I looks like there is no way to construct message from byte array having MessageDescriptor (which I can get from ServiceDescriptor). On Feb 23, 7:28 pm, Kenton Varda wrote: > (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 > > 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 default instance, then they can choose to provide either a > > compiled-in type or a dynamic type. > > > On Tue, Feb 23, 2010 at 1:55 PM, ph wrote: > > >> 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 Scala): > >> Class.forName ( String.format ( classNameFormat, methodName ) ) > >> .getDeclaredMethod ( "parseFrom", Array ( msg.getClass ) : _* ) > >> .invoke ( null, Array ( msg ) : _* ).asInstanceOf > >> [ com.google.protobuf.GeneratedMessage ] > >> This works fine. I will try to use a Default Message or > >> DynamicMessage, thanks for suggestion. From the top of your head, do > >> you think DynamicMessage will be faster or slower than my approach? > > >> On Feb 22, 6:10 pm, Kenton Varda wrote: > >> > Right, Descriptor.toProto() returns a DescriptorProto, which is itself a > >> > protobuf type. So, calling newBuilderForType() on that is going to > >> return a > >> > builder for DescriptorProto, not a builder for the type described. > > >> > What you want is com.google.protobuf.DynamicMessage. > > >> > Note that DynamicMessage is slower than the message classes produced by > >> > protoc. So if the type in question is actually compiled in to your app, > >> you > >> > should use it instead. Typically what you'd do is pass around the > >> type's > >> > default instance (MyMessageType.getDefaultInstance()) instead of passing > >> > around the descriptor. > > >> > Note that the Service interface also provides a method > >> > getRequestPrototype(MethodDescriptor) which returns the default instance > >> for > >> > the type, on which you can then call newBuilderForType(). > > >> > On Sat, Feb 20, 2010 at 12:54 PM, ph wrote: > >> > > I'm trying to build service return message using > >> > > Descriptors.ServiceDescriptor. > >> > > This does not work: > >> > > serviceDescriptor.findMethodByName > >> > > ( methodName ).getOutputType.toProto.newBuilderForType.mergeFrom > >> > > ( msg ).build > >> > > "msg" is byte array > >> > > It builds DesscriptorProtos.DescriptorProto instead of Message. > > >> > > Is there a way to build message from byte array using method > >> > > descriptor? > > >> > > -- > >> > > You received this message because you are subscribed to the Google > >> Groups > >> > > "Protocol Buffers" group.>> > > To post to this group, send email > >> > > toproto...@googlegroups.com. > >> > > To unsubscribe from this group, send email to>> > > >> > > >protobuf+unsubscr...@googlegroups.com > >> > >> > > . > >> > > For more options, visit this group at > >> > >http://groups.google.com/group/protobuf?hl=en. > > >> -- > >> You received this message because you are subscribed to the Google Groups > >> "Protocol Buffers" group.>> To post to this group, send email > >> toproto...@googlegroups.com. > >> To unsubscribe from this group, send email > >> to>>protobuf+unsubscr...@googlegroups.com > >> . > >> For more options, visit this group at > >>http://groups.google.com/group/protobuf?hl=en. -- You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To post to this group, send email to proto...@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
Re: [protobuf] Re: Construct return message using Descriptors.ServiceDescriptor
(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 > 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 default instance, then they can choose to provide either a > compiled-in type or a dynamic type. > > > On Tue, Feb 23, 2010 at 1:55 PM, ph wrote: > >> 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 Scala): >> Class.forName ( String.format ( classNameFormat, methodName ) ) >>.getDeclaredMethod ( "parseFrom", Array ( msg.getClass ) : _* ) >>.invoke ( null, Array ( msg ) : _* ).asInstanceOf >> [ com.google.protobuf.GeneratedMessage ] >> This works fine. I will try to use a Default Message or >> DynamicMessage, thanks for suggestion. From the top of your head, do >> you think DynamicMessage will be faster or slower than my approach? >> >> >> On Feb 22, 6:10 pm, Kenton Varda wrote: >> > Right, Descriptor.toProto() returns a DescriptorProto, which is itself a >> > protobuf type. So, calling newBuilderForType() on that is going to >> return a >> > builder for DescriptorProto, not a builder for the type described. >> > >> > What you want is com.google.protobuf.DynamicMessage. >> > >> > Note that DynamicMessage is slower than the message classes produced by >> > protoc. So if the type in question is actually compiled in to your app, >> you >> > should use it instead. Typically what you'd do is pass around the >> type's >> > default instance (MyMessageType.getDefaultInstance()) instead of passing >> > around the descriptor. >> > >> > Note that the Service interface also provides a method >> > getRequestPrototype(MethodDescriptor) which returns the default instance >> for >> > the type, on which you can then call newBuilderForType(). >> > >> > >> > >> > On Sat, Feb 20, 2010 at 12:54 PM, ph wrote: >> > > I'm trying to build service return message using >> > > Descriptors.ServiceDescriptor. >> > > This does not work: >> > > serviceDescriptor.findMethodByName >> > > ( methodName ).getOutputType.toProto.newBuilderForType.mergeFrom >> > > ( msg ).build >> > > "msg" is byte array >> > > It builds DesscriptorProtos.DescriptorProto instead of Message. >> > >> > > Is there a way to build message from byte array using method >> > > descriptor? >> > >> > > -- >> > > You received this message because you are subscribed to the Google >> Groups >> > > "Protocol Buffers" group. >> > > To post to this group, send email to proto...@googlegroups.com. >> > > To unsubscribe from this group, send email to >> > > protobuf+unsubscr...@googlegroups.com >> >> > > . >> > > For more options, visit this group at >> > >http://groups.google.com/group/protobuf?hl=en. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Protocol Buffers" group. >> To post to this group, send email to proto...@googlegroups.com. >> To unsubscribe from this group, send email to >> protobuf+unsubscr...@googlegroups.com >> . >> For more options, visit this group at >> http://groups.google.com/group/protobuf?hl=en. >> >> > -- You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To post to this group, send email to proto...@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
Re: [protobuf] Re: Construct return message using Descriptors.ServiceDescriptor
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 default instance, then they can choose to provide either a compiled-in type or a dynamic type. On Tue, Feb 23, 2010 at 1:55 PM, ph wrote: > 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 Scala): > Class.forName ( String.format ( classNameFormat, methodName ) ) >.getDeclaredMethod ( "parseFrom", Array ( msg.getClass ) : _* ) >.invoke ( null, Array ( msg ) : _* ).asInstanceOf > [ com.google.protobuf.GeneratedMessage ] > This works fine. I will try to use a Default Message or > DynamicMessage, thanks for suggestion. From the top of your head, do > you think DynamicMessage will be faster or slower than my approach? > > > On Feb 22, 6:10 pm, Kenton Varda wrote: > > Right, Descriptor.toProto() returns a DescriptorProto, which is itself a > > protobuf type. So, calling newBuilderForType() on that is going to > return a > > builder for DescriptorProto, not a builder for the type described. > > > > What you want is com.google.protobuf.DynamicMessage. > > > > Note that DynamicMessage is slower than the message classes produced by > > protoc. So if the type in question is actually compiled in to your app, > you > > should use it instead. Typically what you'd do is pass around the type's > > default instance (MyMessageType.getDefaultInstance()) instead of passing > > around the descriptor. > > > > Note that the Service interface also provides a method > > getRequestPrototype(MethodDescriptor) which returns the default instance > for > > the type, on which you can then call newBuilderForType(). > > > > > > > > On Sat, Feb 20, 2010 at 12:54 PM, ph wrote: > > > I'm trying to build service return message using > > > Descriptors.ServiceDescriptor. > > > This does not work: > > > serviceDescriptor.findMethodByName > > > ( methodName ).getOutputType.toProto.newBuilderForType.mergeFrom > > > ( msg ).build > > > "msg" is byte array > > > It builds DesscriptorProtos.DescriptorProto instead of Message. > > > > > Is there a way to build message from byte array using method > > > descriptor? > > > > > -- > > > You received this message because you are subscribed to the Google > Groups > > > "Protocol Buffers" group. > > > To post to this group, send email to proto...@googlegroups.com. > > > To unsubscribe from this group, send email to > > > protobuf+unsubscr...@googlegroups.com > > > > . > > > For more options, visit this group at > > >http://groups.google.com/group/protobuf?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "Protocol Buffers" group. > To post to this group, send email to proto...@googlegroups.com. > To unsubscribe from this group, send email to > protobuf+unsubscr...@googlegroups.com > . > For more options, visit this group at > http://groups.google.com/group/protobuf?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To post to this group, send email to proto...@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
[protobuf] Re: Construct return message using Descriptors.ServiceDescriptor
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 Scala): Class.forName ( String.format ( classNameFormat, methodName ) ) .getDeclaredMethod ( "parseFrom", Array ( msg.getClass ) : _* ) .invoke ( null, Array ( msg ) : _* ).asInstanceOf [ com.google.protobuf.GeneratedMessage ] This works fine. I will try to use a Default Message or DynamicMessage, thanks for suggestion. From the top of your head, do you think DynamicMessage will be faster or slower than my approach? On Feb 22, 6:10 pm, Kenton Varda wrote: > Right, Descriptor.toProto() returns a DescriptorProto, which is itself a > protobuf type. So, calling newBuilderForType() on that is going to return a > builder for DescriptorProto, not a builder for the type described. > > What you want is com.google.protobuf.DynamicMessage. > > Note that DynamicMessage is slower than the message classes produced by > protoc. So if the type in question is actually compiled in to your app, you > should use it instead. Typically what you'd do is pass around the type's > default instance (MyMessageType.getDefaultInstance()) instead of passing > around the descriptor. > > Note that the Service interface also provides a method > getRequestPrototype(MethodDescriptor) which returns the default instance for > the type, on which you can then call newBuilderForType(). > > > > On Sat, Feb 20, 2010 at 12:54 PM, ph wrote: > > I'm trying to build service return message using > > Descriptors.ServiceDescriptor. > > This does not work: > > serviceDescriptor.findMethodByName > > ( methodName ).getOutputType.toProto.newBuilderForType.mergeFrom > > ( msg ).build > > "msg" is byte array > > It builds DesscriptorProtos.DescriptorProto instead of Message. > > > Is there a way to build message from byte array using method > > descriptor? > > > -- > > You received this message because you are subscribed to the Google Groups > > "Protocol Buffers" group. > > To post to this group, send email to proto...@googlegroups.com. > > To unsubscribe from this group, send email to > > protobuf+unsubscr...@googlegroups.com > om> > > . > > For more options, visit this group at > >http://groups.google.com/group/protobuf?hl=en. -- You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To post to this group, send email to proto...@googlegroups.com. To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
