Thanks for your feedback, Kenton! You've answered all of my questions. Alex
On Wed, Sep 10, 2008 at 1:00 AM, Kenton Varda <[EMAIL PROTECTED]> wrote: > On Mon, Sep 8, 2008 at 10:52 PM, Alex Loddengaard < > [EMAIL PROTECTED]> wrote: > >> I should revise my problem slightly. I had said that I am given an >> instance of a Message class when deserializing. This is true, though >> sometimes that instance is null. In the cases when it's null, I'm not able >> to call newBuilderForType() on it. I'm not able to call >> getDefaultInstance(), either. This is now problematic, though there may be >> a work around. Also given to me is a Class instance of the Message. I'm >> using Reflection to instantiate a new Message instance, then >> getDefaultInstance() to get the default instance, and then I'm calling >> newBuilderForType(). Is this problematic? >> > > Hmm, I think the framework you are using is poorly designed -- it should > always give you a non-null default instance. Using Java reflection is ugly. > > getDefaultInstance() is actually a static method. So, you don't have to > instantiate a new message instance first -- just call the static method > without an instance. You can't actually instantiate the message class > directly anyway, since the constructors are private. > > >> >> >> Thanks again. Sorry for all the spam! >> >> Alex >> >> >> On Tue, Sep 9, 2008 at 12:11 PM, Alex Loddengaard < >> [EMAIL PROTECTED]> wrote: >> >>> I have a follow-up question: >>> >>> Will using * >>> messageInstance.newBuilderForType().mergeFrom(input).build();* work for >>> a stream that contains trailing binary information? >>> >>> I'm asking this question for the following reason: I'm using a very >>> simple example where my Message just contains a single String. When I print >>> the serialized message with a value of "my_string", I get >>> "<binary>my_string". Now, when I see the stream coming in on the >>> deserialization side, I get "<binary>my_string<binary>" The leading binary >>> is the same as the original, however the trailing binary is something new >>> entirely. The trailing binary is probably being created by Hadoop. >>> >>> Kenton, you have made it very clear that * >>> messageInstance.newBuilderForType().mergeFrom(input).build();* is the >>> correct approach. What could possibly be going wrong if the stream I'm >>> trying to deserialize from contains trailing binary data? >>> >>> Thanks ahead of time for your help. >>> >>> Alex >>> >>> >>> On Tue, Sep 9, 2008 at 10:47 AM, Alex Loddengaard < >>> [EMAIL PROTECTED]> wrote: >>> >>>> After taking my code out of Hadoop, it looks as though my deserializing >>>> mechanism is working fine. My problem lies with my integration with >>>> Hadoop. >>>> >>>> Thanks for resolving this issue, Kenton! >>>> >>>> Alex >>>> >>>> >>>> On Tue, Sep 9, 2008 at 9:42 AM, Alex Loddengaard < >>>> [EMAIL PROTECTED]> wrote: >>>> >>>>> On Tue, Sep 9, 2008 at 9:28 AM, Kenton Varda <[EMAIL PROTECTED]>wrote: >>>>> >>>>>> To clarify: In my original message I was saying that you should call >>>>>> isInitialized() on the builder returned by mergeFrom(), to make sure the >>>>>> parsed message is complete, before you call build(). >>>>>> >>>>> >>>>> Ah. Now isInitialized() is returning true, though I'm still having >>>>> problems deserializing. Now that I'm using OutputStream and InputStream, >>>>> I'm getting the following exception: >>>>> >>>>> com.google.protobuf.InvalidProtocolBufferException: Protocol message >>>>> tag had invalid wire type. >>>>> >>>>> I'm going to take my code out of Hadoop to see if Hadoop is causing >>>>> these issues. I'm still weary of that, though, because other >>>>> serialization >>>>> frameworks such as Facebook's Thrift seem to work in the framework that I >>>>> am >>>>> using. >>>>> >>>>> Thanks for your help, Kenton! I'll check back soon with my progress. >>>>> >>>> >>>> >>> >> > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To post to this group, send email to protobuf@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~----------~----~----~----~------~----~------~--~---
