You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Richard Lewis-Shell <rl...@mac.com> on 2003/12/08 10:48:58 UTC
TestPropertySpecification.xml is also failing (with JDK 1.3)
OK - the other failing test is c9.Eight. For my poor old antiquated JDK it
gives the following
junit.framework.AssertionFailedError: Request #12/Message: Response does not
contain string 'Method 'public abstract long
org.apache.tapestry.junit.mock.c9.Eight.getEnhancedProperty()' (declared in
class org.apache.tapestry.junit.mock.c9.Eight) has no implementation in
class org.apache.tapestry.junit.mock.c9.Eight (or enhanced subclass
org.apache.tapestry.junit.mock.c9.Eight$'.
at
org.apache.tapestry.junit.mock.MockTester.matchSubstring(MockTester.java:659
)
at
org.apache.tapestry.junit.mock.MockTester.executeOutputAssertions(MockTester
.java:558)
...
The test script is expecting an exception for the getter, but under JDK 1.3
Tapestry is actually failing with the setter. Seems the test has two
problems:
1) the name of the property does not match the name of the getter/setter
("enhancedProperty" vs "enhanced")
2) the setter returns long instead of void.
I think the first is a mistake - though please correct me if I'm wrong. The
second appears to be the error that is actually being tested for (based on
the comment accompanying the setter in Eight.java). Actually, it could be
both are deliberate but in that case I don't think both could be tested. So
my best guess at this failure is that the order that abstract methods are
checked has changed between 1.3 and 1.4.
Any other suggestions?
If not, I will rename the property in the page file to match the abstract
get/set method. This leaves the test failing on the set method for 1.3, but
I don't know how 1.4 will react - I suspect that 1.4 will still fail on the
get method, so in all liklihood removing the get method from Eight.java will
be the safest way to guarantee the order the methods are checked. If this
defeats the point of the test, let me know.
R
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
JDK 1.3 test failures
Posted by Richard Lewis-Shell <rl...@mac.com>.
Right. It's fixed. Almost. I hope.
It seems that the flaky JDK is the IBM 1.3.1 JDK (as ships with WSAD 5.1).
The latest Sun 1.3.1 and 1.4.2 JDKs are fine.
I've fixed the c9.Eight test as mentioned earlier, which means that only
TestEnhancedClassFactory.testCreateFailure() fails on the IBM JDK. All the
other tests are passing for me with Sun's latest JDKs. Given this, I see no
reason to remove the test (as I earlier suggested).
R
----- Original Message -----
From: "Richard Lewis-Shell" <rl...@mac.com>
To: "Tapestry development" <ta...@jakarta.apache.org>
Sent: Tuesday, December 09, 2003 10:06 AM
Subject: Re: TestPropertySpecification.xml is also failing (with JDK 1.3)
> > This is interesting, since the unit tests work (sans the one that was
> > modified) work for me ok with JDK 1.3.1 :)
>
> Hmm, exactly which 1.3 JDK version are you using that sees all the tests
> pass?
>
> I have now grabbed the latest 1.3.1 (_09), which gives me different
results
> for the two tests in question:
> Sun's 1.3.1_09 JDK: testCreateFailure() passes,
> TestPropertySpecification.xml fails
> IBM's 1.3.1 JDK: testCreateFailure() fails, TestPropertySpecification.xml
> passes
>
> Arrgggghhhhh.
>
> If I modify Eight.page's property to be named "enhancedProperty", I can
get
> TestPropertySpecification to pass with both.
>
> So that will just leave testCreateFailure() failing with IBM's 1.3.1 JDK.
>
> R
>
> > That said, I think your point is quite correct -- the aim of the test
does
> > appear to be testing for (2) rather than (1). Perhaps it does need to be
> > modified?
> >
> >
> > ----- Original Message -----
> > From: "Richard Lewis-Shell" <rl...@mac.com>
> > To: <ta...@jakarta.apache.org>
> > Sent: Monday, December 08, 2003 11:48 AM
> > Subject: TestPropertySpecification.xml is also failing (with JDK 1.3)
> >
> >
> > > OK - the other failing test is c9.Eight. For my poor old antiquated
JDK
> > it
> > > gives the following
> > >
> > > junit.framework.AssertionFailedError: Request #12/Message: Response
does
> > not
> > > contain string 'Method 'public abstract long
> > > org.apache.tapestry.junit.mock.c9.Eight.getEnhancedProperty()'
(declared
> > in
> > > class org.apache.tapestry.junit.mock.c9.Eight) has no implementation
in
> > > class org.apache.tapestry.junit.mock.c9.Eight (or enhanced subclass
> > > org.apache.tapestry.junit.mock.c9.Eight$'.
> > > at
> > >
> >
>
org.apache.tapestry.junit.mock.MockTester.matchSubstring(MockTester.java:659
> > > )
> > > at
> > >
> >
>
org.apache.tapestry.junit.mock.MockTester.executeOutputAssertions(MockTester
> > > .java:558)
> > > ...
> > >
> > > The test script is expecting an exception for the getter, but under
JDK
> > 1.3
> > > Tapestry is actually failing with the setter. Seems the test has two
> > > problems:
> > > 1) the name of the property does not match the name of the
getter/setter
> > > ("enhancedProperty" vs "enhanced")
> > > 2) the setter returns long instead of void.
> > >
> > > I think the first is a mistake - though please correct me if I'm
wrong.
> > The
> > > second appears to be the error that is actually being tested for
(based
> on
> > > the comment accompanying the setter in Eight.java). Actually, it
could
> be
> > > both are deliberate but in that case I don't think both could be
tested.
> > So
> > > my best guess at this failure is that the order that abstract methods
> are
> > > checked has changed between 1.3 and 1.4.
> > >
> > > Any other suggestions?
> > >
> > > If not, I will rename the property in the page file to match the
> abstract
> > > get/set method. This leaves the test failing on the set method for
1.3,
> > but
> > > I don't know how 1.4 will react - I suspect that 1.4 will still fail
on
> > the
> > > get method, so in all liklihood removing the get method from
Eight.java
> > will
> > > be the safest way to guarantee the order the methods are checked. If
> this
> > > defeats the point of the test, let me know.
> > >
> > > R
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: TestPropertySpecification.xml is also failing (with JDK 1.3)
Posted by Richard Lewis-Shell <rl...@mac.com>.
> This is interesting, since the unit tests work (sans the one that was
> modified) work for me ok with JDK 1.3.1 :)
Hmm, exactly which 1.3 JDK version are you using that sees all the tests
pass?
I have now grabbed the latest 1.3.1 (_09), which gives me different results
for the two tests in question:
Sun's 1.3.1_09 JDK: testCreateFailure() passes,
TestPropertySpecification.xml fails
IBM's 1.3.1 JDK: testCreateFailure() fails, TestPropertySpecification.xml
passes
Arrgggghhhhh.
If I modify Eight.page's property to be named "enhancedProperty", I can get
TestPropertySpecification to pass with both.
So that will just leave testCreateFailure() failing with IBM's 1.3.1 JDK.
R
> That said, I think your point is quite correct -- the aim of the test does
> appear to be testing for (2) rather than (1). Perhaps it does need to be
> modified?
>
>
> ----- Original Message -----
> From: "Richard Lewis-Shell" <rl...@mac.com>
> To: <ta...@jakarta.apache.org>
> Sent: Monday, December 08, 2003 11:48 AM
> Subject: TestPropertySpecification.xml is also failing (with JDK 1.3)
>
>
> > OK - the other failing test is c9.Eight. For my poor old antiquated JDK
> it
> > gives the following
> >
> > junit.framework.AssertionFailedError: Request #12/Message: Response does
> not
> > contain string 'Method 'public abstract long
> > org.apache.tapestry.junit.mock.c9.Eight.getEnhancedProperty()' (declared
> in
> > class org.apache.tapestry.junit.mock.c9.Eight) has no implementation in
> > class org.apache.tapestry.junit.mock.c9.Eight (or enhanced subclass
> > org.apache.tapestry.junit.mock.c9.Eight$'.
> > at
> >
>
org.apache.tapestry.junit.mock.MockTester.matchSubstring(MockTester.java:659
> > )
> > at
> >
>
org.apache.tapestry.junit.mock.MockTester.executeOutputAssertions(MockTester
> > .java:558)
> > ...
> >
> > The test script is expecting an exception for the getter, but under JDK
> 1.3
> > Tapestry is actually failing with the setter. Seems the test has two
> > problems:
> > 1) the name of the property does not match the name of the getter/setter
> > ("enhancedProperty" vs "enhanced")
> > 2) the setter returns long instead of void.
> >
> > I think the first is a mistake - though please correct me if I'm wrong.
> The
> > second appears to be the error that is actually being tested for (based
on
> > the comment accompanying the setter in Eight.java). Actually, it could
be
> > both are deliberate but in that case I don't think both could be tested.
> So
> > my best guess at this failure is that the order that abstract methods
are
> > checked has changed between 1.3 and 1.4.
> >
> > Any other suggestions?
> >
> > If not, I will rename the property in the page file to match the
abstract
> > get/set method. This leaves the test failing on the set method for 1.3,
> but
> > I don't know how 1.4 will react - I suspect that 1.4 will still fail on
> the
> > get method, so in all liklihood removing the get method from Eight.java
> will
> > be the safest way to guarantee the order the methods are checked. If
this
> > defeats the point of the test, let me know.
> >
> > R
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: TestPropertySpecification.xml is also failing (with JDK 1.3)
Posted by Mindbridge <mi...@yahoo.com>.
This is interesting, since the unit tests work (sans the one that was
modified) work for me ok with JDK 1.3.1 :)
That said, I think your point is quite correct -- the aim of the test does
appear to be testing for (2) rather than (1). Perhaps it does need to be
modified?
----- Original Message -----
From: "Richard Lewis-Shell" <rl...@mac.com>
To: <ta...@jakarta.apache.org>
Sent: Monday, December 08, 2003 11:48 AM
Subject: TestPropertySpecification.xml is also failing (with JDK 1.3)
> OK - the other failing test is c9.Eight. For my poor old antiquated JDK
it
> gives the following
>
> junit.framework.AssertionFailedError: Request #12/Message: Response does
not
> contain string 'Method 'public abstract long
> org.apache.tapestry.junit.mock.c9.Eight.getEnhancedProperty()' (declared
in
> class org.apache.tapestry.junit.mock.c9.Eight) has no implementation in
> class org.apache.tapestry.junit.mock.c9.Eight (or enhanced subclass
> org.apache.tapestry.junit.mock.c9.Eight$'.
> at
>
org.apache.tapestry.junit.mock.MockTester.matchSubstring(MockTester.java:659
> )
> at
>
org.apache.tapestry.junit.mock.MockTester.executeOutputAssertions(MockTester
> .java:558)
> ...
>
> The test script is expecting an exception for the getter, but under JDK
1.3
> Tapestry is actually failing with the setter. Seems the test has two
> problems:
> 1) the name of the property does not match the name of the getter/setter
> ("enhancedProperty" vs "enhanced")
> 2) the setter returns long instead of void.
>
> I think the first is a mistake - though please correct me if I'm wrong.
The
> second appears to be the error that is actually being tested for (based on
> the comment accompanying the setter in Eight.java). Actually, it could be
> both are deliberate but in that case I don't think both could be tested.
So
> my best guess at this failure is that the order that abstract methods are
> checked has changed between 1.3 and 1.4.
>
> Any other suggestions?
>
> If not, I will rename the property in the page file to match the abstract
> get/set method. This leaves the test failing on the set method for 1.3,
but
> I don't know how 1.4 will react - I suspect that 1.4 will still fail on
the
> get method, so in all liklihood removing the get method from Eight.java
will
> be the safest way to guarantee the order the methods are checked. If this
> defeats the point of the test, let me know.
>
> R
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org