Jeff and Jeremy, Thanks for the good discussion about equals. Would one of you care to open a Jira to capture your conversation?
Lawrence "Jeff MAURY" <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 06/13/2008 06:50 AM Please respond to [email protected] To [email protected] cc Subject Re: Questions about tests 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. Regards Jeff MAURY On Fri, Jun 13, 2008 at 11:42 AM, Jeremy Hughes <[EMAIL PROTECTED]> wrote: 2008/6/12 Jeff MAURY <[EMAIL PROTECTED]>: > Jeremy, > > I will have a look at XMLUnit for my tests. > However, I don't see your point regarding the equals method. The equals > method is not related to interface inheritance but rather to content. I agree. But the DescriptionImpl represents both component model and element model, so if you want to compare two WSDLs at the element model level (i.e. that the XML is the same) then you could implement the DescriptionImpl.equals() to do that. But if the use case is to compare two WSDLs at the component model level then the DescriptionImpl.equals() method would need to be implemented to do that instead. Two WSDLs can be equal at the component model level and not equal at the element model - e.g. say the only difference between the two WSDLs is that one uses an import for some of its contents while the other doesn't in which case at the component model they are equal but at the element model they are different. > That > means that if a class C implements two interfaces A and B, then the equals > method must compare the content of C, regardless it is an implementation of > A or B. > By the way, I don't agree with your note 2, in that case, it will case > WSDLComponentImpl.equals, this is the definition of polymorphism. Yeah, you're totally right. Sorry. This is off topic and probably not something you wanted to get, but here goes in case you're interesting. It's something I had been thinking about a while ago (the example I really wanted to write is below, where the 'wrong' equals() method is called.) At the moment, the equals() method is on the WSDLComponentImpl base class which isn't implemented anyway. So when we get to implementing it we should consider being able to test equality at the component model and at the element model levels. The signature of the WSDLComponentImpl.equals() method is public boolean equals(WSDLComponent comp) But overloading equals() to cater for testing at the component model level and presumably another equals() method for element model level isn't the answer. Overloading equals() isn't good because in some cases it is possible for the Object.equals() method to be called instead. I got my example wrong - sorry for any confusion - you're right polymorphism rules in that case and the right equals() method is called. An expectation of using equals() is that it doesn't matter what objects are passed into equals(), the correct implementation of equals() is called. It has to be an *overriden* implemenetion rather than an *overloaded*. This example shows an example of when the Object.equals() method is called when you really wanted a differing implementation of equals(): public class EqualsTest{ public final static void main (String args[]){ // Check that BaseClass.equals(BaseClass o) works BaseClass foo = new BaseClass(); BaseClass bar = new BaseClass(); System.out.println(foo.equals(bar)); // equals method of BaseClass when iterating through an Object array BaseClass b = new BaseClass(); Object[] oa = new Object[] { new BaseClass(), new BaseClass() }; for (int i = 0; i < oa.length; i++) { // This calls the Object.equals(Object o) method and returns false System.out.println(b.equals(oa[i])); // This calls the Object.equals(Object o) method and returns false System.out.println(oa[i].equals(b)); } } public static class BaseClass { public boolean equals(BaseClass o) { System.out.println("BaseClass.equals(BaseClass o) called"); if (this==o) return true; if (!(o instanceof BaseClass)) return false; // All BaseClass objects are created equal return true; } } } So on the one hand we have a single implemention class for both component and element models <description> and we can only have one implementation of equals() on that Description class. That equals() method doesn't know whether we want to compare at the component model level or the element model level. > I don"t want to compare the WSDLs line per line as Lawrence suggests, > because it I changed for any reasons the layout of the generated WSDL > (indentation, line feeds), then the tests will break. OK, so XMLUnit should do the job as it is able to detect when documents are 'similar' ... i.e the same at the XML level but not at the bytes level. > > > Regards > Jeff MAURY > > > On 6/12/08, Jeremy Hughes <[EMAIL PROTECTED]> wrote: >> >> Jeff, the equals() method isn't implemented. The best way to achieve >> what you want is to use something like XMLUnit. Today two Woden >> objects are equal if they are the same object ... Object.equals() is >> called under the covers. >> >> There's a problem with the equals() method as we have it on Woden >> classes. The place to implement equals() is on the DescriptionImpl, >> InterfaceImpl etc classes. However, DescriptionImpl is the >> implementation of both the Description and DescriptionElement >> interfaces, so the question is what should the method compare? Should >> it compare at the Description (component model level) or the >> DescriptionElement (element model level). It's not correct to >> implement two equals() methods with different signatures as this will >> break the equals() method contract for transitivity. That is: >> >> Object obj; >> Description desc1; >> Description desc2; >> >> desc1.equals(desc2); // see note 1 >> >> obj=desc1; >> obj.equals(desc2); // see note 2 >> desc2.equals(obj); // see note 3 >> >> Note 1: as it is today will call the baseclass >> WSDLComponentImpl.equals(WSDLComponent comp) method which actually >> defers to the Object.equals() method as I mentioned, but this isn't >> very useful >> Note 2: this will call the Object.equals() method >> Note 3: this will call WSDLComponentImpl.equals(WSDLComponent comp) >> which while today this defers to Object.equals(), if we wanted >> something useful - ie compare each individual Component model object >> inside the Description objects - then we don't have transitivity. >> >> We need transitivity if the objects can be put into hashmaps etc. We >> also need a hashCode implementation but that is another (related) >> discussion. >> >> If you have any ideas on fixing this, then that would be welcome as I >> think component model and element model comparison would be useful for >> a well formed programming model. However, all thoughts I've had about >> this up to now haven't fitted well with the current design. >> >> Oh yes, back on-topic :-) ... XML file comparison / XMLUnit is more >> likely to solve your problem of testing the converter in the short >> term. >> >> Thanks, >> Jeremy >> >> 2008/6/12 Jeff MAURY <[EMAIL PROTECTED]>: >> > Hello, >> > >> > as I am working on the converter, I have a little question. >> > In order to non regress the converter, I want to build tests that checks >> > the >> > output. >> > The fastest and easiest way to do it is to compare the generated WSDL2.0 >> > with the expected WSDL2.0. In order to do that, my idea was to load both >> > documents using the Woden API and to use the equals method on the >> > resulting >> > objects in order to check the equality. Can I do that ? >> > >> > Thanks >> > Jeff MAURY >> > >> > >> > -- >> > La mélancolie c'est communiste >> > Tout le monde y a droit de temps en temps >> > La mélancolie n'est pas capitaliste >> > C'est même gratuit pour les perdants >> > La mélancolie c'est pacifiste >> > On ne lui rentre jamais dedans >> > La mélancolie oh tu sais ça existe >> > Elle se prend même avec des gants >> > La mélancolie c'est pour les syndicalistes >> > Il faut juste sa carte de permanent >> > >> > Miossec (2006) >> > >> > http://www.jeffmaury.com >> > http://riadiscuss.jeffmaury.com >> > http://www.lastfm.fr/listen/user/jeffmaury/personal >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> > > > > -- > La mélancolie c'est communiste > Tout le monde y a droit de temps en temps > La mélancolie n'est pas capitaliste > C'est même gratuit pour les perdants > La mélancolie c'est pacifiste > On ne lui rentre jamais dedans > La mélancolie oh tu sais ça existe > Elle se prend même avec des gants > La mélancolie c'est pour les syndicalistes > Il faut juste sa carte de permanent > > Miossec (2006) > > http://www.jeffmaury.com > http://riadiscuss.jeffmaury.com > http://www.lastfm.fr/listen/user/jeffmaury/personal --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- La mélancolie c'est communiste Tout le monde y a droit de temps en temps La mélancolie n'est pas capitaliste C'est même gratuit pour les perdants La mélancolie c'est pacifiste On ne lui rentre jamais dedans La mélancolie oh tu sais ça existe Elle se prend même avec des gants La mélancolie c'est pour les syndicalistes Il faut juste sa carte de permanent Miossec (2006) http://www.jeffmaury.com http://riadiscuss.jeffmaury.com http://www.lastfm.fr/listen/user/jeffmaury/personal --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
