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];
    optional bool isEmail = 2 [default = false];
    optional bool isIpAddress = 3 [default = false];

extend google.protobuf.FieldOptions {
    optional LiOptions li_opts = 50101;

Then I compile this .proto into a .java and can use it. When a message uses 
this extension, I can figure out which fields use my options, I use the 
following code:

        Descriptors.FileDescriptor fieldOptionsDesc = 
        Descriptors.FileDescriptor extensionsDesc = 
        Descriptors.FileDescriptor[] files = new 
Descriptors.FileDescriptor[]{fieldOptionsDesc, extensionsDesc};

        DescriptorProtos.FileDescriptorSet set = 
        DescriptorProtos.FileDescriptorProto messages = set.getFile(0);
        Descriptors.FileDescriptor fileDesc = 
Descriptors.FileDescriptor.buildFrom(messages, files);
        Descriptors.Descriptor md = 

        Set<Descriptors.FieldDescriptor> piiFields = Sets.newHashSet();
        for (Descriptors.FieldDescriptor fieldDescriptor : md.getFields()) {
            DescriptorProtos.FieldOptions options = 
            UnknownFieldSet.Field field = 
            if (field != null) {
                Extensions.LiOptions liOptions = 
                if (liOptions.getIsEmail() || liOptions.getIsIpAddress() || 
liOptions.getIsPii()) {

On Saturday, November 1, 2014 4:26:35 AM UTC-7, Oliver wrote:

On 1 November 2014 02:24, Pradeep Gollakota <prade...@gmail.com 
> <javascript:>> 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 DynamicMessage API. The isPii extension has been 
> refactored 
> > into a separate proto that is precompiled into my codebase. I.E. the 
> > descriptor for MessagePublish should be loaded dynamically and the 
> > descriptor for the FieldOption I'm defining won't be loaded dynamically. 
> As 
> > far as I can tell, there shouldn't be any mixing of the descriptor 
> pools, 
> > though I may be wrong. 
> This is exactly where the problem is, though - you have: 
> MessagePublish descriptor D1 (from encoded descriptorset) references 
> extension field F1 (from encoded descriptorset) 
> Message descriptor D2 (from pregenerated code) references extension 
> field F2 (from pregenerated code) 
> So if you have a message built from D1 then it thinks it has a field 
> F1; when you ask if it has extension F2 it says "no!" even though 
> they're really the same thing. 
> > Any thoughts on how I can proceed with this project? 
> It seems like a flaw in the API .. In the case I ran into, I could 
> work around it as the processing code only wanted to work with 
> non-option extensions when it had the precompiled code for the 
> extension, so for those well-known message types I'd just look up the 
> descriptor to use from the precompiled set rather than using the 
> in-stream descriptor set (the message format included the descriptors 
> inline). That doesn't really work here though. 
> Can you inspect the options using field descriptors from the encoded 
> descriptorset, rather than using Messages.pii from the pregenerated 
> code? 
> Oliver 

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 http://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

Reply via email to