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 <pkirsa...@gmail.com> 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 <ken...@google.com> 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 <ken...@google.com> 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 <pkirsa...@gmail.com> 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 <ken...@google.com> 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 <pkirsa...@gmail.com> 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<protobuf%2bunsubscr...@googlegroups.com> > <protobuf%2bunsubscr...@googlegroups.com<protobuf%252bunsubscr...@googlegroups.com> > > > > >> <protobuf%2bunsubscr...@googlegroups.c 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 > toproto...@googlegroups.com. > > >> To unsubscribe from this group, send email to>> > protobuf+unsubscr...@googlegroups.com<protobuf%2bunsubscr...@googlegroups.com> > <protobuf%2bunsubscr...@googlegroups.com<protobuf%252bunsubscr...@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<protobuf%2bunsubscr...@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.
