[protobuf] Re: Message.getField(FieldDescriptor) and enum values.
If that's all you're trying to do, you don't really need the java enum
value...
The EnumValueDescriptor is what you use for the value when calling
setField(FieldDescriptor field, Object value) for an Enum Field
On May 23, 5:09 pm, Jim Mayer wrote:
> That's exactly the problem. We don't. This issue first came up for us when
> writing code to copy data from one subtree to another of a protocol buffer.
> By passing in a field descriptor we were able to eliminate a LOT of
> duplicated code. In that case, we only needed the field access to write and
> so were able to get the descriptor. We anticipate the same issue coming up
> for reading, however.
>
> We could define an interface with a 'get' and a 'set' method and avoid using
> getField/setField at all, but it seems unfortunate that the capability isn't
> in the API. The data appears to all be there; in fact, it appears that
> GeneratedMessage.SingularEnumFieldAccessor adds extra code to get the
> current behavior.
>
> -- Jim
>
>
>
>
>
>
>
> On Mon, May 23, 2011 at 4:37 PM, Ben Wright wrote:
> > Assuming you know the Java Enum Type for which the EnumValueDescriptor
> > is describing a type of...
>
> > MyJavaEnum.valueOf((EnumValueDescriptor)value)
>
> > will return the appropriate java enum value.
>
> > On May 23, 1:42 pm, Jim Mayer wrote:
> > > In the Java protocol buffer binding, is there a way to get the Java
> > > enum value using protocol buffer reflection? Specifically, I'd like
> > > to be able to write something like the following:
>
> > > Object getFieldValue(MessageOrBuilder source, FieldDescriptor field)
> > > {
> > > Object value = source.getField(field);
> > > if (value instanceof EnumValueDescriptor) {
> > > return ;
> > > } else {
> > > return value;
> > > }
> > > }
>
> > > As far as I can tell, this isn't possible as the methods that return
> > > enums from the descriptors are all static on the enum class. Since
> > > they are static, there is no way (short of reflection games) to invoke
> > > them unless one has the class in hand. I would enjoy being proved
> > > wrong :-)
>
> > > What we'd really like to see is an easy mechanism that would give us
> > > the following:
>
> > > Something explicitValue = message.getXXX();
> > > Object reflectionValue =
> > > message.getTheJavaValueFromAFieldDescriptor( > > XXX>);
> > > assert explictValue == reflectionValue;
>
> > > Similarly, we'd like to be able do the same thing for 'setXXX' methods
> > > for builders, however in this case it's easy to go from an enum value
> > > to its descriptor so we can get by with the 'setField' method.
>
> > > Thanks!
>
> > > -- Jim
>
> > --
> > 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
> > protobuf+unsubscr...@googlegroups.com.
> > For more options, visit this group at
> >http://groups.google.com/group/protobuf?hl=en.
--
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
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.
Re: [protobuf] Re: Message.getField(FieldDescriptor) and enum values.
That's exactly the problem. We don't. This issue first came up for us when
writing code to copy data from one subtree to another of a protocol buffer.
By passing in a field descriptor we were able to eliminate a LOT of
duplicated code. In that case, we only needed the field access to write and
so were able to get the descriptor. We anticipate the same issue coming up
for reading, however.
We could define an interface with a 'get' and a 'set' method and avoid using
getField/setField at all, but it seems unfortunate that the capability isn't
in the API. The data appears to all be there; in fact, it appears that
GeneratedMessage.SingularEnumFieldAccessor adds extra code to get the
current behavior.
-- Jim
On Mon, May 23, 2011 at 4:37 PM, Ben Wright wrote:
> Assuming you know the Java Enum Type for which the EnumValueDescriptor
> is describing a type of...
>
> MyJavaEnum.valueOf((EnumValueDescriptor)value)
>
> will return the appropriate java enum value.
>
> On May 23, 1:42 pm, Jim Mayer wrote:
> > In the Java protocol buffer binding, is there a way to get the Java
> > enum value using protocol buffer reflection? Specifically, I'd like
> > to be able to write something like the following:
> >
> > Object getFieldValue(MessageOrBuilder source, FieldDescriptor field)
> > {
> > Object value = source.getField(field);
> > if (value instanceof EnumValueDescriptor) {
> >return ;
> > } else {
> > return value;
> > }
> > }
> >
> > As far as I can tell, this isn't possible as the methods that return
> > enums from the descriptors are all static on the enum class. Since
> > they are static, there is no way (short of reflection games) to invoke
> > them unless one has the class in hand. I would enjoy being proved
> > wrong :-)
> >
> > What we'd really like to see is an easy mechanism that would give us
> > the following:
> >
> >Something explicitValue = message.getXXX();
> >Object reflectionValue =
> > message.getTheJavaValueFromAFieldDescriptor( > XXX>);
> >assert explictValue == reflectionValue;
> >
> > Similarly, we'd like to be able do the same thing for 'setXXX' methods
> > for builders, however in this case it's easy to go from an enum value
> > to its descriptor so we can get by with the 'setField' method.
> >
> > Thanks!
> >
> > -- Jim
>
> --
> 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
> protobuf+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/protobuf?hl=en.
>
>
--
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
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.
[protobuf] Re: Message.getField(FieldDescriptor) and enum values.
Assuming you know the Java Enum Type for which the EnumValueDescriptor
is describing a type of...
MyJavaEnum.valueOf((EnumValueDescriptor)value)
will return the appropriate java enum value.
On May 23, 1:42 pm, Jim Mayer wrote:
> In the Java protocol buffer binding, is there a way to get the Java
> enum value using protocol buffer reflection? Specifically, I'd like
> to be able to write something like the following:
>
> Object getFieldValue(MessageOrBuilder source, FieldDescriptor field)
> {
> Object value = source.getField(field);
> if (value instanceof EnumValueDescriptor) {
> return ;
> } else {
> return value;
> }
> }
>
> As far as I can tell, this isn't possible as the methods that return
> enums from the descriptors are all static on the enum class. Since
> they are static, there is no way (short of reflection games) to invoke
> them unless one has the class in hand. I would enjoy being proved
> wrong :-)
>
> What we'd really like to see is an easy mechanism that would give us
> the following:
>
> Something explicitValue = message.getXXX();
> Object reflectionValue =
> message.getTheJavaValueFromAFieldDescriptor( XXX>);
> assert explictValue == reflectionValue;
>
> Similarly, we'd like to be able do the same thing for 'setXXX' methods
> for builders, however in this case it's easy to go from an enum value
> to its descriptor so we can get by with the 'setField' method.
>
> Thanks!
>
> -- Jim
--
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
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.
[protobuf] Message.getField(FieldDescriptor) and enum values.
In the Java protocol buffer binding, is there a way to get the Java
enum value using protocol buffer reflection? Specifically, I'd like
to be able to write something like the following:
Object getFieldValue(MessageOrBuilder source, FieldDescriptor field)
{
Object value = source.getField(field);
if (value instanceof EnumValueDescriptor) {
return ;
} else {
return value;
}
}
As far as I can tell, this isn't possible as the methods that return
enums from the descriptors are all static on the enum class. Since
they are static, there is no way (short of reflection games) to invoke
them unless one has the class in hand. I would enjoy being proved
wrong :-)
What we'd really like to see is an easy mechanism that would give us
the following:
Something explicitValue = message.getXXX();
Object reflectionValue =
message.getTheJavaValueFromAFieldDescriptor();
assert explictValue == reflectionValue;
Similarly, we'd like to be able do the same thing for 'setXXX' methods
for builders, however in this case it's easy to go from an enum value
to its descriptor so we can get by with the 'setField' method.
Thanks!
-- Jim
--
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
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.
[protobuf] protobuf-2.4.1 (java) build problems
Hello I'm trying to create generated-sources and generated-test-sources files for protobuf-2.4.1 (java), but getting an error message: [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure Failure executing javac, but could not parse the error: The system is out of resources. Consult the following stack trace for details. java.lang.OutOfMemoryError: Java heap space at com.sun.tools.javac.util.Position$LineMapImpl.build(Position.java: 139) at com.sun.tools.javac.util.Position.makeLineMap(Position.java:63) at com.sun.tools.javac.parser.Scanner.getLineMap(Scanner.java:1105) at com.sun.tools.javac.main.JavaCompiler.parse(JavaCompiler.java:512) at com.sun.tools.javac.main.JavaCompiler.parse(JavaCompiler.java:550) at com.sun.tools.javac.main.JavaCompiler.parseFiles(JavaCompiler.java: 801) at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java: 727) at com.sun.tools.javac.main.Main.compile(Main.java:353) at com.sun.tools.javac.main.Main.compile(Main.java:279) at com.sun.tools.javac.main.Main.compile(Main.java:270) at com.sun.tools.javac.Main.compile(Main.java:87) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java: 39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java: 25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.plexus.compiler.javac.JavacCompiler.compileInProcess(JavacCompiler.java: 420) at org.codehaus.plexus.compiler.javac.JavacCompiler.compile(JavacCompiler.java: 141) at org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.java: 493) at org.apache.maven.plugin.TestCompilerMojo.execute(TestCompilerMojo.java: 102) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java: 443) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java: 539) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java: 480) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java: 459) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java: 311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java: 278) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java: 143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) at org.apache.maven.cli.MavenCli.main(MavenCli.java:280) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java: 39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java: 25) with protobuf-2.3.0 everything was ok. Please, can anybody help me to resolve this problem. -- 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 protobuf+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
[protobuf] FindFileByName fails
Hi all,
I have an application that was originally doing all of the Protocol
Buffer access in Python but I'm in the process of moving a performance
critical part to C++. Most of the Protocol Buffer access code remains
in Python with just one part in C++ right now. Most of the time
everything works fine but periodically the application terminates with
this message:
libprotobuf FATAL src/proto/user.pb.cc:51] CHECK failed: file !=
NULL:
terminate called after throwing an instance of
'google::protobuf::FatalException'
what(): CHECK failed: file != NULL:
and the relevant part of the source file is:
void protobuf_AssignDesc_user_2eproto() {
protobuf_AddDesc_user_2eproto();
const ::google::protobuf::FileDescriptor* file =
::google::protobuf::DescriptorPool::generated_pool()-
>FindFileByName(
"user.proto");
I'm a little confused about why the C++ code needs to access the
original descriptor at runtime and why it seems to be intermittent as
to when it needs to do so. The proto file in question does not import
any other packages and of course the C++ source file already contains
the file descriptor that describes the whole proto file anyway. Does
this simple use case require me to delve into descriptor databases and
pools? I'm using version 2.4.1 with the C++ backend for Python via
the PROTOCOL_BUFFERS_PYTHON_IMPLEMENTATION=cpp environment variable.
Thanks,
Patrick
--
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
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.
[protobuf] Re: Issue 293 in protobuf: About Objective-C
Comment #1 on issue 293 by jens.knu...@gmail.com: About Objective-C http://code.google.com/p/protobuf/issues/detail?id=293 FWIW, there's another implementation that's actively maintained here: https://github.com/booyah/protobuf-objc I've tried it and I like it so far -- HTH. -- 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 protobuf+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
[protobuf] Re: Issue 296 in protobuf: Deploy protobuf-java 2.4.1 JAR to Maven Repository
Comment #1 on issue 296 by bimsc...@googlemail.com: Deploy protobuf-java 2.4.1 JAR to Maven Repository http://code.google.com/p/protobuf/issues/detail?id=296 Sorry, I've hit enter before filling out the text... Currently the 2.4.1 JAR is missing on both Maven Central and the deprecated Google Maven repository. -- 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 protobuf+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
[protobuf] Issue 296 in protobuf: Deploy protobuf-java 2.4.1 JAR to Maven Repository
Status: New Owner: liuj...@google.com Labels: Type-Defect Priority-Medium New issue 296 by bimsc...@googlemail.com: Deploy protobuf-java 2.4.1 JAR to Maven Repository http://code.google.com/p/protobuf/issues/detail?id=296 What steps will reproduce the problem? 1. 2. 3. What is the expected output? What do you see instead? What version of the product are you using? On what operating system? Please provide any additional information below. -- 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 protobuf+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
[protobuf] Re: How to control the output size of GzipOutputStream?
There is another problem. If I use FileOutputStream, the message would not be flush whether Flush() is be used or not. It would be flush until the file descriptor is closed. It is still the EOF's problem? if yes, it looks not suitable for socket programing. I have seem the same problem on SerializeToFileDescriptor. Thanks > On 5月20日, 下午11時19分, Jason Hsueh wrote: > Haven't used stringbuf before, but it looks like that just sets the internal > buffer for the stringbuf. You are going through a few layers of buffering > here; you probably want to just directly use a ZeroCopyOutputStream > implementation that writes to the socket, like FileOutputStream, which > allows you to control the buffer size. Then just have GzipOutputStream wap > that instead of an OstreamOutputStream. > > > > > > > > On Fri, May 20, 2011 at 3:29 AM, Shin wrote: > > I attempt to use compressed data for my socket programing. > > The problem is the fixed output buffer size. > > > Message *request; > > char buf[512]; > > stringbuf sbuf; > > sbuf.pubsetbuf((char*)buf, sizeof(buf)); > > ostream os(&sbuf); > > OstreamOutputStream *oos = new OstreamOutputStream(&os); > > GzipOutputStream *gzout = new GzipOutputStream(oos); > > request->SerializeToZeroCopyStream(gzout); > > > write(sd, buf, sizeof(buf)); > > > I wanna use a loop to send the data. > > But I don't know how to control the stream to output fixed-size data. > > > Thanks. > > > -- > > 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 > > protobuf+unsubscr...@googlegroups.com. > > For more options, visit this group at > >http://groups.google.com/group/protobuf?hl=en. -- 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 protobuf+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
