The hascode and equals methods are just convience functions. They are not there to specifically support representing graphs. If someone wants to send a patch so the multiref code doesn't use these methods, that would be fine with me. I will note that I didn't implement either the hashcode or the multref code, nor have a look at how the multiref code is determining two objects are the same.
As far as equals is concerned, two WSDL2Java emitted JavaBeans are equal if their member elements are equal. This is a very useful function to have, so we emit it. So, sounds like there is some sort of bug and a fix in the form of a patch/diff are always welcome, but it sounds like a bugzilla bug should be opened at a minimum. -- Tom Jordahl Macromedia -----Original Message----- From: John Gregg To: [EMAIL PROTECTED] Sent: 7/2/2002 11:08 AM Subject: RE: Is this a bug in serialization? Tom, If the example Naresh gave is producing one "object" in the xml output, this is a bug, not a feature. I haven't looked at the Axis code in this area, but I'm familiar with the general problem. My suggestion is to use System.identityHashCode(), not the overridden Object.hashCode(). The implementation of Object.hashCode() simply calls System.identityHashCode(). I know someone a few days ago asked about why there are generated equals() and hashCode() methods. I don't know the answer but if this is the reason for their use, you could just eliminate them. Overriding those two methods isn't something to be done lightly. They're tricky to do right and there are a number of different possible implementations for equals(). For example, are 2 objects equal if their members are equal? This is the usual definition. Are they equal if they conceptually occupy the same spot in a graph of instances? Are they equal if their persistent ids are the same? john [John Gregg] -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Tom Jordahl Sent: Tuesday, July 02, 2002 11:05 AM To: '[EMAIL PROTECTED]' Subject: RE: Is this a bug in serialization? This is a feature of soap encoding. You only get a single copy of your object transmitted in the XML so the other side knows that the two references are the same thing. It sounds like we may need to change the hashcode function emitted by WSDL2Java (or you can edit it by hand). -- Tom Jordahl Macromedia -----Original Message----- From: Naresh Bhatia [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 02, 2002 12:00 PM To: '[EMAIL PROTECTED]' Subject: Is this a bug in serialization? I had sent the following message to the user list, but got no response. Perhaps it is more appropriate for the developer list because it brings up an issue with Axis serialization. I would really appreciate a response from the group. Thanks. Naresh Bhatia -----Original Message----- From: Naresh Bhatia [mailto:[EMAIL PROTECTED]] Sent: Saturday, June 29, 2002 1:17 PM To: '[EMAIL PROTECTED]' Subject: Is this a bug in serialization? I am trying to serialize two different objects, both of which happen to have the same value. Unfortunately the generated SOAP message contains only one value for the object and two references pointing to it. Is this a bug or am I missing something? Here's how I create the two objects in Java: Message msg1 = new Message("Error"); Message msg2 = new Message("Error"); When the serialization framework encounters the second object, it thinks that it is the same as the first one (because the hashcode function returns the same value) and hence creates a reference to the first object: <msg1 href="#id8"/> <msg2 href="#id8"/> <multiRef id="id8" SOAP-ENC:root="0" soapenv:encodingStyle= http://schemas.xmlsoap.org/soap/encoding/ <http://schemas.xmlsoap.org/soap/encoding/> xsi:type="ns14:Message" xmlns:ns14=" http://test <http://test> "> <text xsi:type="xsd:string">Error</text> </multiRef> I have created the Message object using WSDL2Java and it contains the equals() and hashcode() methods. Please help! Naresh Bhatia
