protoc plugin generator using Java

603 views
Skip to first unread message

Alex Antonov

unread,
Jul 19, 2011, 10:20:23 PM7/19/11
to Protocol Buffers
I've tried to use the experimental Java support for writing the protoc
plugins from http://codereview.appspot.com/912042/show
Everything got compiled correctly but when I started using it, got the
following error:

protoc --java_out=. --plugin=protoc-gen-my --my_out=. config.proto
--my_out: protoc-gen-my: Plugin output is unparseable.

Redirecting the output of 'protoc-gen-my' script to a file and then
trying to recreate the 'CodeGeneratorResponse' in code worked without
any issues.
However when using it with protoc, it refuses to parse it. :(

This is the content of my 'protoc-gen-my' script:

#!/bin/bash
#cd `dirname $0`

#java -Xdebug -
Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=5005 -jar
protobuf-java-codegen-0.1.jar
#java -jar protobuf-java-codegen-0.1.jar 1> data.pb
java -jar protobuf-java-codegen-0.1.jar

Any idea what I could be doing wrong?

Thanks,
Alex

Joseph Dean

unread,
May 10, 2016, 6:52:05 PM5/10/16
to Protocol Buffers
Found the issue: the encoded data contains the newline sequence, which when written to the console on windows is automatically replaced with \r\n instead of \n. The fix is to set the cout mode to binary so it doesn't do the replacement.

Example:

#include <io.h>
#include <fcntl.h>
#include <iostream>

int main( int argc, char * argv[] )
{
    _setmode( _fileno( stdout ),  _O_BINARY );
    std::cout << std::endl;
}
I hope somebody finds this useful. Also, an example C++ plugin-generator on the protobuf website would be key in highlighting this issue.

Joseph Dean

unread,
May 10, 2016, 6:52:05 PM5/10/16
to Protocol Buffers
Did you ever find a solution to this issue? I'm encountering the same problem. The parsing fails if I set the name on the file object in the response. If I don't set the name it parses correctly (and of course generation fails without the name set.) Either way I can serialize the CodeGeneratorResponse within my application and decode it properly myself...


On Tuesday, July 19, 2011 at 7:20:23 PM UTC-7, Alex Antonov wrote:
Reply all
Reply to author
Forward
0 new messages