John, Maybe using equals() is too confusing. Why not add an isEquivalentTo() method to the Interface instead?
Arthur Ryman, Technical Executive (IBM DE) Project and Program Management, Rational Division phone: +1-905-413-3077, TL 313-3077 assistant: +1-905-413-3831, TL 313-3831 fax: +1-905-413-4920, TL 313-4920 mobile: +1-416-939-5063 "John Kaputin (gmail)" <[EMAIL PROTECTED]> 06/23/2008 10:56 AM Please respond to [email protected] To [email protected] cc Subject Re: Questions about tests The WSDL 2 spec talks about equivalence between components. This is to do with collapsing equivalent components derived from different parts of the XML infoset into a single component in the Component model. I think there are some assertions about it too. If I remember correctly, that was the requirement behind having an equals() implementation that tested for the logical equivalence of components and the equals(WSDLComponent) method resulted because of the problem with implementing equals(Object) in an Impl class that implements both the Component and Element interfaces. For example, we wanted to override equals(Object) in DescriptionImpl, but this implements both the Description component and the DescriptionElement interfaces. The equivalence checking behavioiur for a Description component and a DescriptionElement are different, but at the DescriptionImpl level we can't tell which 'view' of the object the caller is seeing (component or element). We do need some form of equivalence checking to satisfy the spec and while implementing equals(WSDLComponent) across Woden might achieve this, it will break the transitivity of the Object equals() method as Jeremy says, which will limit the ability to make use of some aspects of Java (e.g. in the collection classes). Don't forget the issue still pending on the Woden wiki [1] about merging the Component and Element APIs into one API. This might simplify implementing the equals(Object) method, but we will still need to test for Component equivalence to satisfy the spec. [1] http://wiki.apache.org/ws/FrontPage/Woden/APIReview/OneWsdlApi regards, John. On Fri, Jun 13, 2008 at 11:39 PM, Jeremy Hughes <[EMAIL PROTECTED]> wrote: 2008/6/13 Jeff MAURY <[EMAIL PROTECTED]>: > Just to finish the discussion: > > 1) I agree that XMLUnint will solve the problem > 2) I think the equals method should work on the component level because > Description is the component representation of the WSDL > 3) If the user wants to test equality at the element level, he should use > the toElement methods and use equals on the results. That sounds like a nice idea, but both toElement() and toComponent() methods return 'this' ... so myDescription.toElement().equals(foo) will call the same equals() method on the same object as: myDescription.toComponent().equals(foo) but I can see your sentiment that the toElement() method should produce an object that effectively *is* the element model of the WSDL and so equals() method would test for equality at the element model level. I did have thoughts around the terminology we use - our meaning of the term "model" isn't quite the same (IMHO) as the meaning of the word "model" in the MVC pattern. I think if we starting thinking in terms of the MVC pattern then we would have a single model (in the MVC sense of the word) of the WSDL which would at least contain a representation of the XML (like DescriptionImpl does today) and optionally a calculated representation of WSDL in terms of what the spec calls *components*. This is pretty much what we have today in fact, except that we would just start saying we have *one* model. Then we would move to saying we have an "Element view" of the model and a "Component view" of the model. That way the equals() methods would be on the view and you would only ever compare an instance of one type of view of a WSDL with an instance of the same type of view of another WSDL. My only hesitation is that this is quite a significant change. Is it worth it just so that .equals() works? And we'd need hashCode() of course. It may provide further benefits - it would be easy enough to create other views on the model (if there was a use case for that). Regards, Jeremy --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
