Ok… I finally figured out the work around for this. I use a separate .proto
file that contains my custom options.
package com.lithum.pbnj;
import "google/protobuf/descriptor.proto";
option java_package = "com.lithium.pbnj";
message LiOptions {
optional bool isPii = 1 [default = false];
On 1 November 2014 02:24, Pradeep Gollakota wrote:
> Confirmed... When I replaced the "md" variable with the compiled Descriptor,
> it worked. I didn't think I was mixing the descriptors, e.g. the
> MessagePublish message is one that is produced via the compiled API and
> parsed using the DynamicM
Confirmed... When I replaced the "md" variable with the compiled
Descriptor, it worked. I didn't think I was mixing the descriptors, e.g.
the MessagePublish message is one that is produced via the compiled API and
parsed using the DynamicMessage API. The isPii extension has been
refactored into a s
You may be running into issues where the set of descriptors associated
with your parsed DynamicMessage (i.e. the ones you parsed at runtime)
do not match the set of descriptors from your pregenerated code (which
will be using their own descriptor pool). IIRC they're looked up by
identity, so even i
Not really... one of the use cases I'm trying to solve for is an
anonymization use case. We will have several app's writing protobuf records
and the data will pass through an anonymization layer. The anonymizer
inspects the schema's for all incoming data and will transform the pii
fields. Since
On Fri, Oct 31, 2014 at 6:18 PM, Pradeep Gollakota wrote:
> Boolean extension =
> fieldDescriptor.getOptions().getExtension(Messages.isPii);
Shouldn't this use some sort of API that doesn't use the Messages class at all?
-ilia
--
You received this message because you are subscribed to the Go
Ok… so I was finally able to parse a dynamic message and it looks good. It
looks like it was just a user error on my part… after a little bit of
digging around, I found the right APIs to call. Now my code looks like:
Descriptors.FileDescriptor fieldOptionsDesc =
DescriptorProtos.Field
At no point are you specifying that you want to use the
"MessagePublish" descriptor, so you must still be using the API
incorrectly...
On Fri, Oct 31, 2014 at 5:10 PM, Pradeep Gollakota wrote:
> Ok… awesome… I do have the .proto’s ahead of time, so I can have them
> compiled to the .desc files an
Ok… awesome… I do have the .proto’s ahead of time, so I can have them
compiled to the .desc files and store those.
Here’s my .proto file:
package com.lithum.pbnj;
import "google/protobuf/descriptor.proto";
option java_package = "com.lithium.pbnj";
extend google.protobuf.FieldOptions {
o
Basically, you can't do that in pure Java - the compiler is a C++
binary, there is no Java version.
Still, working with the output of --descriptor_set_out is probably the
way to go here. If you have the .proto file ahead of time, you can
pregenerate the descriptor output at build time and store it
Hi Oliver,
Thanks for the response! I guess my question wasn't quite clear. In my java
code I have a string which contains the content of a .proto file. Given
this string, how can I create an instance of a Descriptor class so I can do
DynamicMessage parsing.
Thanks!
- Pradeep
On Thursday, Oct
On 30 October 2014 02:53, Pradeep Gollakota wrote:
> I have a use case where I need to parse messages without having the
> corresponding precompiled classes in Java. So the DynamicMessage seems to be
> the correct fit, but I'm not sure how I can generate the DescriptorSet from
> the ".proto" defi
Hi Protobuf gurus,
I'm trying to parse a .proto file in Java to use with DynamicMessages. Is
this possible or does it have to be compiled to a "descriptor set" file
first before this can be done?
I have a use case where I need to parse messages without having the
corresponding precompiled clas
13 matches
Mail list logo