You are viewing a plain text version of this content. The canonical link for it is here.
Posted to woden-dev@ws.apache.org by Jeff MAURY <je...@jeffmaury.com> on 2008/06/12 13:20:57 UTC
Questions about tests
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
Re: Questions about tests
Posted by Jeff MAURY <je...@jeffmaury.com>.
On Fri, Jun 13, 2008 at 3:40 PM, Lawrence Mandel <lm...@ca.ibm.com> wrote:
> Jeff and Jeremy,
>
> Thanks for the good discussion about equals. Would one of you care to open
> a Jira to capture your conversation?
Done.
Jeff
>
>
> Lawrence
>
>
>
>
>
> "Jeff MAURY" <je...@jeffmaury.com>
> Sent by: jeffmaury@gmail.com
> 06/13/2008 06:50 AM
> Please respond to
> woden-dev@ws.apache.org
>
>
> To
> woden-dev@ws.apache.org
> 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 <hu...@apache.org>
> wrote:
> 2008/6/12 Jeff MAURY <je...@jeffmaury.com>:
> > 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 <hu...@apache.org> 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 <je...@jeffmaury.com>:
> >> > 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: woden-dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: woden-dev-help@ws.apache.org
> >>
> >
> >
> >
> > --
> > 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: woden-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: woden-dev-help@ws.apache.org
>
>
>
>
> --
> 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: woden-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: woden-dev-help@ws.apache.org
>
>
--
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
Re: Questions about tests
Posted by Lawrence Mandel <lm...@ca.ibm.com>.
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" <je...@jeffmaury.com>
Sent by: jeffmaury@gmail.com
06/13/2008 06:50 AM
Please respond to
woden-dev@ws.apache.org
To
woden-dev@ws.apache.org
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 <hu...@apache.org>
wrote:
2008/6/12 Jeff MAURY <je...@jeffmaury.com>:
> 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 <hu...@apache.org> 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 <je...@jeffmaury.com>:
>> > 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: woden-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: woden-dev-help@ws.apache.org
>>
>
>
>
> --
> 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: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
--
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: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
Re: Questions about tests
Posted by Arthur Ryman <ry...@ca.ibm.com>.
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)" <ja...@gmail.com>
06/23/2008 10:56 AM
Please respond to
woden-dev@ws.apache.org
To
woden-dev@ws.apache.org
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 <hu...@apache.org>
wrote:
2008/6/13 Jeff MAURY <je...@jeffmaury.com>:
> 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: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
Re: Questions about tests
Posted by "John Kaputin (gmail)" <ja...@gmail.com>.
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 <hu...@apache.org> wrote:
> 2008/6/13 Jeff MAURY <je...@jeffmaury.com>:
> > 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: woden-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: woden-dev-help@ws.apache.org
>
>
Re: Questions about tests
Posted by Jeremy Hughes <hu...@apache.org>.
2008/6/13 Jeff MAURY <je...@jeffmaury.com>:
> 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: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
Re: Questions about tests
Posted by Jeff MAURY <je...@jeffmaury.com>.
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 <hu...@apache.org> wrote:
> 2008/6/12 Jeff MAURY <je...@jeffmaury.com>:
> > 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 <hu...@apache.org> 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 <je...@jeffmaury.com>:
> >> > 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: woden-dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: woden-dev-help@ws.apache.org
> >>
> >
> >
> >
> > --
> > 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: woden-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: woden-dev-help@ws.apache.org
>
>
--
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
Re: Questions about tests
Posted by Jeremy Hughes <hu...@apache.org>.
2008/6/12 Jeff MAURY <je...@jeffmaury.com>:
> 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 <hu...@apache.org> 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 <je...@jeffmaury.com>:
>> > 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: woden-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: woden-dev-help@ws.apache.org
>>
>
>
>
> --
> 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: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
Re: Questions about tests
Posted by Jeff MAURY <je...@jeffmaury.com>.
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. 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.
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.
Regards
Jeff MAURY
On 6/12/08, Jeremy Hughes <hu...@apache.org> 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 <je...@jeffmaury.com>:
> > 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: woden-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: woden-dev-help@ws.apache.org
>
>
--
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
Re: Questions about tests
Posted by Jeremy Hughes <hu...@apache.org>.
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 <je...@jeffmaury.com>:
> 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: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
Re: Questions about tests
Posted by Lawrence Mandel <lm...@ca.ibm.com>.
Hi Jeff,
John should know if the equals method will work in this case. However...
I'd like to suggest an alternate approach and the justification for using
the approach. I like to test generated documents against expected
documents by comparing the two documents themselves (line for line). I'm
not a fan of transforming the results of the generation before testing as
there is no guarantee the documents will then be the same. For example,
Woden may discard or default certain elements/attributes (correctly or
incorrectly) that will result in the test passing even though the
documents are actually different.
Lawrence
"Jeff MAURY" <je...@jeffmaury.com>
Sent by: jeffmaury@gmail.com
06/12/2008 07:20 AM
Please respond to
woden-dev@ws.apache.org
To
woden-dev@ws.apache.org
cc
Subject
Questions about tests
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: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org