Re: [protobuf] NoClassDefFoundError Android
Hi Jason thanks for your answer. I just pasted the relevant lines from the proto file, sorry for not being more explicit about that. Here is a paste of the whole file: http://pastebin.com/uCKCsviG the file is called doorProtocol and hence since I have/had not specified the outer class name the java file is named DoorProtocol which for me is fine. It is also placed in the right package, no problems. The problem is that the $request class is not available at runtime. Best Kasper Den tirsdag den 8. maj 2012 18.18.21 UTC+2 skrev Jason Hsueh: Your proto file in the link looks incomplete. Have you checked the outer class name option? https://developers.google.com/protocol-buffers/docs/reference/java-generated#invocation On Tue, May 8, 2012 at 12:25 AM, Kasper Revsbech krevsb...@gmail.comwrote: Hi all I have a mind wrapping problem using protocol Buffers on Android. I among other commands defined a request in my .proto file: http://pastebin.com/B4htQeRm In my communication I do as follows: Protocol.request.Builder r = Protocol.request.newBuilder(); However on run time I get the error: java.lang.NoClassDefFoundError dk.revsbech.client.Protocol$request I have now trie with at bunch of jar files both pre compiled and manually compiled both with and withouut Maven, both with and without the LITE_RUNTIME optimization. However I keep getting the runtime error. Tanks in advance -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To view this discussion on the web visit https://groups.google.com/d/msg/protobuf/-/MAzfYhJy8PMJ. 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 view this discussion on the web visit https://groups.google.com/d/msg/protobuf/-/4Yvjb6GxPWsJ. 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: NoClassDefFoundError Android
SOLVED! The problem was not a protocol buffers problem, however a more general problem in ADT after updating. The jars was not copied to the device. For people experincing the same, have a look at: http://stackoverflow.com/questions/1334802/how-can-i-use-external-jars-in-an-android-project http://stackoverflow.com/questions/2247998/noclassdeffounderror-eclipse-and-android Best and thanks Kasper Revsbech Den tirsdag den 8. maj 2012 09.25.37 UTC+2 skrev Kasper Revsbech: Hi all I have a mind wrapping problem using protocol Buffers on Android. I among other commands defined a request in my .proto file: http://pastebin.com/B4htQeRm In my communication I do as follows: Protocol.request.Builder r = Protocol.request.newBuilder(); However on run time I get the error: java.lang.NoClassDefFoundError dk.revsbech.client.Protocol$request I have now trie with at bunch of jar files both pre compiled and manually compiled both with and withouut Maven, both with and without the LITE_RUNTIME optimization. However I keep getting the runtime error. Tanks in advance -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To view this discussion on the web visit https://groups.google.com/d/msg/protobuf/-/utubWuytGfcJ. 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] incompatible type changes philosophy
On Wed, May 9, 2012 at 12:42 AM, Jeremy Stribling st...@nicira.com wrote: I'm wondering if anyone has experience with a scenario like this, and if there's a more elegant way to solve it. We do something a bit similar by advertising capabilities during a handshake at the start of each connection. If we need an incompatible changes in a message, we retain both forms as separate fields in the protobuf definition and add a new capability that says I understand the new form as well as the old form. The sender ensures the right field is set based on the recipient's advertised capabilities and which forms the sender understands. This only works if you can do a handshake, though - it wouldn't be any good for persistent storage or multicast/datagram-like situations. (In practice, it's been rare to actually do incompatible changes - more commonly we use the capabilities to negotiate behavioural changes) Oliver -- 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] incompatible type changes philosophy
On May 8, 2012, at 21:26 , Jeremy Stribling wrote: Thanks for the response. As you say, this solution is painful because you can't enable the optimization until the old version of the program is completely deprecated. This is somewhat simple in the case that you yourself are deploying the software, but when you're shipping software to customers (as we are) and have to support many old versions, it will take a very long time (possibly years) before you can enable the optimization. Also, it breaks the downgrade path. Once you enable the optimization, you can never downgrade back to a version that did not know about the new field. I think I now understand your problem. You want to add some additional stuff to your .proto file to indicate the incompatible change, then have the application code not need to know about it? Eg. you want to write the application code that only accesses new_my_data and never needs to check for deprecated_my_data, but in fact the underlying protocol buffer supports both fields, or something like that. It seems to me like this is starts to end up in the territory of too high level for the protocol buffer library itself since I can't imagine this working without handshaking like Oliver talked about (e.g. I understand everything up to version X). My personal experience has been more like what Daniel describes: you keep both versions of the field, and your code has if statements to check for both. I believe this can be made to work, even in your scenario, but it does require ugly code in your application to handle it. My impression is that you are trying to avoid that. Random brainstorming that may not be helpful in any way: I'm curious about how you end up choosing to solve this, but I think you are going to need to use some combination of custom field options (to specify the change in a way that protoc can parse?), and then hacks in the C++ code generator to call your custom upgrade / downgrade code. I think this can work somewhat seamlessly in the reading older messages case (eg. you just add code that says if we see the old field, upgrade it to the new field). However, this can't work in the writing a newer message for an older receiver case without making the Serialize* code aware of the version it should be *writing*. I think this is going to be pretty application specific? My other thought: I think you might be able to get away with writing a protoc plugin that adds two functions to the class scope (which already exists as an insertion point): static UpgradedMessage ParseAnyMessageVersion(…); string SerializeToVersion(int target_version); These functions can apply the appropriate upgrade/downgrading as needed. However, you then need to call the appropriate functions to read/write the messages. However, I would argue that since in the serializing case you are going to need to know the target_version anyway, this might actually work? Good luck, and again I'd be interested to know how you do end up solving this. Evan -- http://evanjones.ca/ -- 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 391 in protobuf: Patch for /trunk/src/google/protobuf/io/zero_copy_stream_impl_lite.cc
Status: New Owner: Labels: Type-Patch New issue 391 by constant...@gmail.com: Patch for /trunk/src/google/protobuf/io/zero_copy_stream_impl_lite.cc http://code.google.com/p/protobuf/issues/detail?id=391 No point in including zero_copy_stream_impl.h since it creates for the lite version the necessity for the file zero_copy_stream_impl.h to exist in lite version. In the lite version the zero_copy_stream_impl.cc is not compiled so the classes defined in the header have no implementation in the lite version and can not be used. Attachments: zero_copy_stream_impl_lite.cc.patch 461 bytes -- 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 391 in protobuf: Patch for /trunk/src/google/protobuf/io/zero_copy_stream_impl_lite.cc
Comment #1 on issue 391 by constant...@gmail.com: Patch for /trunk/src/google/protobuf/io/zero_copy_stream_impl_lite.cc http://code.google.com/p/protobuf/issues/detail?id=391 Same thing applies to wire_format_lite.cc and message_lite.cc -- 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] incompatible type changes philosophy
On 05/09/2012 04:41 AM, Evan Jones wrote: On May 8, 2012, at 21:26 , Jeremy Stribling wrote: Thanks for the response. As you say, this solution is painful because you can't enable the optimization until the old version of the program is completely deprecated. This is somewhat simple in the case that you yourself are deploying the software, but when you're shipping software to customers (as we are) and have to support many old versions, it will take a very long time (possibly years) before you can enable the optimization. Also, it breaks the downgrade path. Once you enable the optimization, you can never downgrade back to a version that did not know about the new field. I think I now understand your problem. You want to add some additional stuff to your .proto file to indicate the incompatible change, then have the application code not need to know about it? Eg. you want to write the application code that only accesses new_my_data and never needs to check for deprecated_my_data, but in fact the underlying protocol buffer supports both fields, or something like that. Hey Evan, thanks for the response. That is one way to look at it. Ideally, the application code would only access my_data(), and it would magically appear as the new type in the new version of the app and the old type in the old version of the app. But renaming the field for the new version is fine too. The important points are twofold: 1) the data would only appear once on the wire and in storage, and translated if necessary by the receiver to the expected format, and 2) that this translation could work on the downgrade path as well, so that old applications could be able to interpret data written by new applications, even if the format of the fields have changes. Sameer Ajmani's ECOOP paper and thesis work discusses these types of scenarios (http://pmg.csail.mit.edu/~ajmani/papers/ecoop06-upgrades.pdf). It seems to me like this is starts to end up in the territory of too high level for the protocol buffer library itself since I can't imagine this working without handshaking like Oliver talked about (e.g. I understand everything up to version X). My personal experience has been more like what Daniel describes: you keep both versions of the field, and your code has if statements to check for both. I believe this can be made to work, even in your scenario, but it does require ugly code in your application to handle it. My impression is that you are trying to avoid that. I'm trying to avoid keeping both version of the data in the wire format, since in this scenario the whole reason for the change was optimization. I don't care if the new version of the protobuf has two separate fields; there just needs to be a way for the old version to still get at its old data. Involving the application in some way is totally reasonable and expected; I am just hoping to find a way to add a translator into the deserialization code, so that it can be upgraded independently on old instances of the program, to be able to interpret the new version of the protobof while still running the old version of the application code. Here's a specific example: * There are two nodes, 1 and 2, running version A of the software. * They exchange messages containing protobuf P, which contains a string field F. * We write a new version B of the software, which changes field F to an integer as an optimization. * We upgrade node 1, but node 2. * If node 1 sends a protobuf P to node 2, I want node 2 to be able to access field F as a string, even though the wire format sent by node 1 was an integer. Random brainstorming that may not be helpful in any way: I'm curious about how you end up choosing to solve this, but I think you are going to need to use some combination of custom field options (to specify the change in a way that protoc can parse?), and then hacks in the C++ code generator to call your custom upgrade / downgrade code. I think this can work somewhat seamlessly in the reading older messages case (eg. you just add code that says if we see the old field, upgrade it to the new field). However, this can't work in the writing a newer message for an older receiver case without making the Serialize* code aware of the version it should be *writing*. I think this is going to be pretty application specific? I think doing it on the deserialize is better, because then we can put the burden of translation on the receiver, and the sender can merrily send the same serialized message to multiple receivers (tagged with its own version) without having to keep track of the version capabilities of each receiver. This is especially important, as Oliver pointed out, when the data is not transferred over a live connection but through the persistent state. It will definitely be app-specific, which was why I was thinking an insertion point might be the way to go. My other thought: I think you might be able
[protobuf] issue with Add() in string
I have a crash in google protobuf .. Any ideas ? I won't be able to paste the complete trace. Thanks in advance Subhash (gdb) bt #0 0x003408e32885 in raise () from /lib64/libc.so.6 #1 0x003408e34065 in abort () from /lib64/libc.so.6 #2 0x7f1096a024d7 in os::abort(bool) () from /usr/java/jdk1.6.0_25/jre/lib/amd64/server/libjvm.so #3 0x7f1096b55b88 in VMError::report_and_die() () from /usr/java/jdk1.6.0_25/jre/lib/amd64/server/libjvm.so #4 0x7f1096b56701 in crash_handler(int, siginfo*, void*) () from /usr/java/jdk1.6.0_25/jre/lib/amd64/server/libjvm.so #5 signal handler called #6 0x7f10969cb8a1 in methodOopDesc::name_and_sig_as_C_string(char*, int) () from /usr/java/jdk1.6.0_25/jre/lib/amd64/server/libjvm.so #7 0x7f1096736411 in frame::print_on_error(outputStream*, char*, int, bool) const () from /usr/java/jdk1.6.0_25/jre/lib/amd64/server/libjvm.so #8 0x7f1096b54488 in VMError::print_stack_trace(outputStream*, JavaThread*, char*, int, bool) () from /usr/java/jdk1.6.0_25/jre/lib/amd64/server/libjvm.so #9 0x7f1096b550d9 in VMError::report(outputStream*) () from /usr/java/jdk1.6.0_25/jre/lib/amd64/server/libjvm.so #10 0x7f1096b55a65 in VMError::report_and_die() () from /usr/java/jdk1.6.0_25/jre/lib/amd64/server/libjvm.so #11 0x7f1096a08e75 in JVM_handle_linux_signal () from /usr/java/jdk1.6.0_25/jre/lib/amd64/server/libjvm.so #12 0x7f1096a0519e in signalHandler(int, siginfo*, void*) () from /usr/java/jdk1.6.0_25/jre/lib/amd64/server/libjvm.so #13 signal handler called #14 0x00340da0f807 in ?? () from /lib64/libgcc_s.so.1 #15 0x00340da10646 in _Unwind_RaiseException () from /lib64/libgcc_s.so.1 #16 0x00340e6bcd21 in __cxa_throw () from /usr/lib64/libstdc++.so.6 #17 0x00340e6bd11d in operator new(unsigned long) () from /usr/lib64/libstdc++.so.6 #18 0x00340e6bd1d9 in operator new[](unsigned long) () from /usr/lib64/libstdc++.so.6 #19 0x7f1086cf6f15 in google::protobuf::internal::RepeatedPtrFieldBase::Reserve (this=0x7f10962f4780, new_size=value optimized out) at google/protobuf/repeated_field.cc:50 #20 0x7f1086a9180b in Addgoogle::protobuf::RepeatedPtrFieldstd::basic_stringchar, std::char_traitschar, std::allocatorchar ::TypeHandler (path=value optimized out, req=0x7f10962f4770) at /usr/local/protobuf-2.4.1//include/google/protobuf/repeated_field.h:675 #21 Add (path=value optimized out, req=0x7f10962f4770) at /usr/local/protobuf-2.4.1//include/google/protobuf/repeated_field.h:870 -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To view this discussion on the web visit https://groups.google.com/d/msg/protobuf/-/m8p19gVpkt4J. 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] Getting fields from a generated Dynamic Message
Hey, I have generated DynamicMessage from available FileDescriptorSet, now I want to be able to get fields from this message. Based on the typename I know what kind of message this is, but I don't know how to get the value of any particular field. Available getter functions available in java library like getField(Descriptors.FieldDescriptor field) need a FieldDescriptor for the field, which I don't know how to generate. In C++ library there is a func called FindFieldByName(String) which returns the corresponding FieldDescriptor but I couldn't find a similar function for java library. Please help -- 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.
