[protobuf] Accessing repeated oneof fields in Java

[Steven Seeley]

3:05 PM (less than a minute ago)
Hi guys,

I've been trying to implement a means to compare two different protobuf 
messages using a mapping of their "json path", and I've mostly got it 
figured out, but one edge case is causing me a lot of frustration.

In my protobuf definition, I have something like

message Foo {
  repeated RepeatedField = 1;
}

message RepeatedField {
  oneof field_type {
FieldType1 field1 = 1;
FieldType2 field2 = 2;
FieldType3 field3 = 3;
  }

}


I would just like to know, if given the FieldDescriptor for RepeatedField, 
does the Java API provide an easy way to grab the first field in the list 
matches a desired field_type?

Thanks!
-Steve

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

[protobuf] Accessing repeated oneof fields in Java

[Steven Seeley]

Hi guys,

I've been trying to implement a means to compare two different protobuf 
messages using a mapping of their "json path", and I've mostly got it 
figured out, but one edge case is causing me a lot of frustration.

In my protobuf definition, I have something like
message Foo {
  repeated RepeatedField = 1;
}

message RepeatedField {
  oneof field_type {
FieldType1 field1 = 1;
FieldType2 field2 = 2;

  }

}


-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

Re: [protobuf] [golang] API provides no way to access unknown extensions

['Feng Xiao' via Protocol Buffers]

I'm not sure if the go team monitors this mailing group. You might get a
better chance to reach them by posting an issue to the golang/protobuf
github repo.

On Mon, Jun 26, 2017 at 7:49 PM, Josh Humphries 
wrote:

> For messages generates from syntax="proto2" files, there is a way to
> access unrecognized fields (as the stream of encoded bytes) via the
> XXX_unrecognized field. But there is no similar way to access unrecognized
> fields that happened to be in an extension range.
>
> If I were to add an issue to the github project to remedy this (and maybe
> even send a pull request), would it get serious consideration? Or is it
> intentional to keep such details completely inaccessible?
>
I know very little about Go, but in other languages like C++/Java, unknown
extensions are put in the same UnknownFieldSet as other fields. It probably
makes more sense to put unknown extensions in XXX_unrecognized?


>
>
> *More background:*
>
> I have a library, protoreflect
> , that supports
> runtime-dynamic messages, using descriptors to define the schemas. One
> thing I want to be able to do is to re-parse the descriptors using a custom
> registry of runtime-defined extensions (for custom options). But I don't
> seem to be able to dig these out of an already-parsed descriptor proto.
>
> *The use case*: I am building a dynamic GRPC stub that works by querying
> the server for its descriptors (using service reflection). I am providing a
> CLI that allows users to pass in JSON that gets parsed into the appropriate
> request message, serialized to the binary format, and sent in a GRPC
> request. Similar happens for de-serializing the responses and then dumping
> the message contents in a human-readable text form.
>
> In order to support custom options, I'd like to be able to efficiently
> extract the unrecognized extensions from descriptors and re-parse them
> using custom logic, that uses extension field descriptors that were also
> downloaded from the same server.
>
> For now, it looks like I need to marshal the options message to bytes, and
> then I could unmarshal it into a dynamic message (I already have support
> for unmarshalling with a custom registry of extensions). But I was hoping
> for something more efficient -- like being able to only do this for the
> unrecognized extensions. (I can already do this for other unrecognized
> fields thanks to the export XXX_unrecognized field that gets added to
> generated proto2 message structs).
>
> Thoughts?
>
> 
> *Josh Humphries*
> jh...@bluegosling.com
>
> --
> You received this message because you are subscribed to the Google Groups
> "Protocol Buffers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to protobuf+unsubscr...@googlegroups.com.
> To post to this group, send email to protobuf@googlegroups.com.
> Visit this group at https://groups.google.com/group/protobuf.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.