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 <ken...@google.com> 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 <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.c > > om> > > <protobuf%2bunsubscr...@googlegroups.com<protobuf%252bunsubscr...@googlegro > > ups.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.c > > om> > > <protobuf%2bunsubscr...@googlegroups.com<protobuf%252bunsubscr...@googlegro > > ups.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.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 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.
