[protobuf] UnmodifiableLazyStringList is not Serializable
Hi! Passing a buffer with a repeated String from one EJB to another, I get: javax.ejb.EJBException: java.rmi.MarshalException: CORBA BAD_PARAM 1398079494 Maybe; nested exception is: java.io.NotSerializableException: WARNING: IOP0016: Class com.google.protobuf.UnmodifiableLazyStringList is not Serializable Is it a problem to make UnmodifiableLazyStringList Serializable? The buffer itself is a already Serializable. Thanke juergen -- 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] UnmodifiableLazyStringList is not Serializable
On Wed, Apr 13, 2011 at 06:45, J.S. goo...@juergenschmied.de wrote: Hi! Passing a buffer with a repeated String from one EJB to another, I get: javax.ejb.EJBException: java.rmi.MarshalException: CORBA BAD_PARAM 1398079494 Maybe; nested exception is: java.io.NotSerializableException: WARNING: IOP0016: Class com.google.protobuf.UnmodifiableLazyStringList is not Serializable Protocol buffers are objects to serialize things, but it doesn't really make sense to use Java serialization to serialize their holder objects. What you actually want to do is to use the ProtocolBuffer functionality to serialize it to an byte array and use that to transfer. If you would try to Java serialize the protocol buffer objects, you would loose all the functionality you were probably considering using Protocol buffers in the first place: version independent, fast and platform independent serialization. The object layout might change between each protocol buffer library version or you might just change the proto definition - all of which will create trouble if you use Java serialization; the protocol buffer binary format, however, is stable (and compact, and fast, and platform independent ...) So in this case it was actually good that the UnmodifiableLazyStringList was not Java serializable - it helped you find an improper use. I am not sure what the maintainers think, but I wouldn't add Java 'Serializable' to all classes used within the generated objects - because then these accidental wrong uses would just go unnoticed. Henner -- 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: UnmodifiableLazyStringList is not Serializable
Hi! Protocol buffers are objects to serialize things, but it doesn't really make sense to use Java serialization to serialize their holder objects. I'd like to pass Java objects from a unserialized protocol buffer between Beans inside a application server. This makes sense to me. If you would try to Java serialize the protocol buffer objects, you would loose all the functionality you were probably considering using Protocol buffers in the first place: version independent, fast and platform independent serialization. The object layout might change between each protocol buffer library version or you might just change the proto definition - all of which will create trouble if you use Java serialization; the protocol buffer binary format, however, is stable (and compact, and fast, and platform independent ...) I think you got it wrong: I'm not going to store a protocol-buffer in a java-serialized from, I just need to pass it as an argument between beans. So in this case it was actually good that the UnmodifiableLazyStringList was not Java serializable - it helped you find an improper use. The deserialized protocol buffers are already implementing teh Serializable interface. Only if you have a repeated String field, it breaks. So I consider it as a bug. I am not sure what the maintainers think, but I wouldn't add Java 'Serializable' to all classes used within the generated objects - because then these accidental wrong uses would just go unnoticed. Sometimes it's just nessesary. And 98% of the buffers are already Serializable. So somebody has need it before me. yours juergen -- 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 210 in protobuf: Java code should detect incompatible runtime library version
Comment #18 on issue 210 by aant...@gmail.com: Java code should detect incompatible runtime library version http://code.google.com/p/protobuf/issues/detail?id=210 Kenton, I'm not sure I would entirely agree with you about Maven. It actually follows a common and well-accepted convention of major-minor-patch compatibility model. So in this particular case, it is actually the protobuf-java library that violates the versioning convention, because the java library version 2.3 is NOT backwards compatible to 2.0.3 (which, if we look at the versions is the common expectation). The problem in this case is that while the Product version of Protocol Buffers dictates the compatibility between .proto syntax format, meaning that a .proto file that was created for 2.0.3 compiler will be happily compiled using 2.3 compiler (protoc), the java library, just like its analogous C++ library follows not the definition compatibility scheme, but a runtime/source compile compatibility, which is totally different from 2.0.3 to 2.3, etc. So it is only natural to expect that java-protobuf library would be major-versioned every time there is a non-backwards compatible change made, just like you already do so with the C++ one by increasing the SONAME by a full version (4-5-6). -- 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: UnmodifiableLazyStringList is not Serializable
I agree with J.S. on this one - there are many situations in Java EE environments where Serializable is checked or java serialization used when it's not simple or feasible to leverage protobuf serialization. Most of these situations are invm / in memory transfers. Sometimes java serialization is used to clone objects or to safely pass them between ClassLoader scopes. I've run into this limitation with JBoss ESB and passing protocol buffer objects between services through the InVM message transport. -- 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: UnmodifiableLazyStringList is not Serializable
On Wed, Apr 13, 2011 at 16:01, Ben Wright compuware...@gmail.com wrote: I agree with J.S. on this one - there are many situations in Java EE environments where Serializable is checked or java serialization used when it's not simple or feasible to leverage protobuf serialization. Most of these situations are invm / in memory transfers. Sometimes java serialization is used to clone objects or to safely pass them between ClassLoader scopes. I've run into this limitation with JBoss ESB and passing protocol buffer objects between services through the InVM message transport. It is a couple of years that I've worked with Java, so my serialization fu might not be up-to-par. But would the problem be solved if the ProtocolBuffer object implements Externalizable ? That way it can be serialized via the Java VM, but it would use the protobuf specific serialization. -h -- 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: UnmodifiableLazyStringList is not Serializable
Also don't have enough Java-fu, but I'd thought this was basically how this was solved: the messages override some function that cause the JavaVM to serialize using protobuf serialization. I was under the impression that the message internals would then no longer needed to implement Serializable. (Specifically I think the magic is in http://code.google.com/apis/protocolbuffers/docs/reference/java/serialized-form.html#com.google.protobuf.GeneratedMessageLite ) On Wed, Apr 13, 2011 at 5:11 PM, Henner Zeller h.zel...@acm.org wrote: On Wed, Apr 13, 2011 at 16:01, Ben Wright compuware...@gmail.com wrote: I agree with J.S. on this one - there are many situations in Java EE environments where Serializable is checked or java serialization used when it's not simple or feasible to leverage protobuf serialization. Most of these situations are invm / in memory transfers. Sometimes java serialization is used to clone objects or to safely pass them between ClassLoader scopes. I've run into this limitation with JBoss ESB and passing protocol buffer objects between services through the InVM message transport. It is a couple of years that I've worked with Java, so my serialization fu might not be up-to-par. But would the problem be solved if the ProtocolBuffer object implements Externalizable ? That way it can be serialized via the Java VM, but it would use the protobuf specific serialization. -h -- 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.
