You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Ralph Goers <Ra...@dslextreme.com> on 2006/07/10 08:26:08 UTC
Wildcard matcher causes StackOverflowErrors (was Re: StackOverflowError
in 2.1)
Well, I found the source of the problem. In the sitemap the matcher for
"*.html" was before the matcher for "menu/*". The matcher for "*.html"
calls the "composite" resource which in turn does a map:part for
"cocoon:/menu/{../1}.html". This is apparently matching *.html and
causing an infinite loop. Simply moving the *.html matcher after the
menu/* matcher causes the problem to go away.
In short, unless the new wildcard matcher is 100% compatible with the
old one it needs to be reverted in BRANCH_2_1_X.
Ralph
Ralph Goers wrote:
> I wanted to mess around with some of the input modules so I brought up
> the input module page in the sample site. However, it dies with a
> StackOverflowError. I then checked out the latest to another one of my
> computers (with Linux instead of Windows) and got the same error.
> Unfortunately, no stack trace is presented. I've tried going directly
> to some of the samples on that page and can't get anything to work.
>
> Ralph
Re: Wildcard matcher causes StackOverflowErrors (was Re: StackOverflowError
in 2.1)
Posted by Carsten Ziegeler <cz...@apache.org>.
Ralph Goers schrieb:
> Well, I found the source of the problem. In the sitemap the matcher for
> "*.html" was before the matcher for "menu/*". The matcher for "*.html"
> calls the "composite" resource which in turn does a map:part for
> "cocoon:/menu/{../1}.html". This is apparently matching *.html and
> causing an infinite loop. Simply moving the *.html matcher after the
> menu/* matcher causes the problem to go away.
>
Can you come up with a test case and add it to the test for the wildcard
matcher?
>
> In short, unless the new wildcard matcher is 100% compatible with the
> old one it needs to be reverted in BRANCH_2_1_X.
True. The old version is buggy and it seems that the new one has some
problems as well.
But in general I think that the new version is a much cleaner and better
implementation we should strive to get working 100%.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Wildcard matcher causes StackOverflowErrors (was Re: StackOverflowError
in 2.1)
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Mon, 10 Jul 2006, Carsten Ziegeler wrote:
> Date: Mon, 10 Jul 2006 09:26:25 +0200
> From: Carsten Ziegeler <cz...@apache.org>
> Reply-To: dev@cocoon.apache.org
> To: dev@cocoon.apache.org
> Subject: Re: Wildcard matcher causes StackOverflowErrors (was Re:
> StackOverflowError in 2.1)
>
> Ralph Goers schrieb:
>> Giacomo Pati wrote:
>>> You mean the new WildcardMatcher is not behaving correctly? Any
>>> TestCase to fix it? Is a match="menu/*" catching a uri="foo.html"?
>> No. match="*.html" is matching on "menu/index.html".
>>> I have to check that.
>>>
>>> Ciao
>>>
>>> Giacomo
>> Were there test cases for the old wildcard matcher? Since this matcher
>> is almost certainly used in every Cocoon deployment we must guarantee
>> that it is 100% compatible with the old matcher in BRANCH_2_1_X -
>> unless, of course, there was some specific bug that needed fixing.
>>
> There were only a few test cases for the old matcher; we have much more
> for the new one. And the old one had specific bugs that we needed to fix
> and as the old code is very ..ehm..historically grown...it is
> unmaintainable.
The "old MatcherTestCase" uses the ExcaliburTestCase (or such) to
establish a test environment whereas the "new MatcherTestCase" just a
plain JUnit TestCase as the base class. I've fixed the problem of the
"new Matcher" but will leave the exercise of what Sylvain explained to
others.
Ciao
- --
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (GNU/Linux)
iD8DBQFEsmzvLNdJvZjjVZARAlbGAJoCW0m2virHu5A3RpWcHOwEzYra4ACdGxgU
mEjJLwhUH8JsnNlrIx4ArQU=
=quYR
-----END PGP SIGNATURE-----
Re: Wildcard matcher causes StackOverflowErrors (was Re: StackOverflowError
in 2.1)
Posted by Sylvain Wallez <sy...@apache.org>.
Ralph Goers wrote:
> Carsten Ziegeler wrote:
>> Ralph Goers schrieb:
>>
>>> Were there test cases for the old wildcard matcher? Since this
>>> matcher is almost certainly used in every Cocoon deployment we must
>>> guarantee that it is 100% compatible with the old matcher in
>>> BRANCH_2_1_X - unless, of course, there was some specific bug that
>>> needed fixing.
>> There were only a few test cases for the old matcher; we have much more
>> for the new one. And the old one had specific bugs that we needed to fix
>> and as the old code is very ..ehm..historically grown...it is
>> unmaintainable.
>>
>> Carsten
>>
> OK. But my question is really that if the old code didn't have unit
> tests how do we know that the new unit tests are compatible with the
> old matcher (i.e - that they get the same results)?
The best solution to ensure non-regression IMO is to have the same test
case operating on both implementations of the matcher, just differing
for the tests we know to fail in the old implementation (and that
justified the refactoring).
abstract class AbstractWildcardTest extends TestCase {
AbstractWildcardTest(Matcher matcher)...
public testSomethingOkInBothImplementations()...
public testBugInOldImplementation()...
}
public OldWildcardMatcherTestCase extends AbstractWildcardTest {
public OldWildcardMatcherTestCase() {
super(new OldWildcardMatcher()); // old code is kept in the test
source tree
}
public testBugInOldImplementation {
try {
super.testBugInOldImplementation();
} catch(Exception) {
return; // expected
}
fail("Should fail with old implementation");
}
public WildcardMatcherTestCase extends AbstractWildcardTest {
public WildcardMatcherTestCase() {
super(new WildcardMatcher()); // new implementation
}
}
Sylvain
--
Sylvain Wallez - http://bluxte.net
Re: Wildcard matcher causes StackOverflowErrors (was Re: StackOverflowError
in 2.1)
Posted by Carsten Ziegeler <cz...@apache.org>.
Ralph Goers wrote:
>>
> OK. But my question is really that if the old code didn't have unit
> tests how do we know that the new unit tests are compatible with the old
> matcher (i.e - that they get the same results)?
:) We added the old tests to the new test case and we added many test
cases which should cover most day to day patterns. Apparently we haven't
covered everything yet. Apart from that, clicking through the samples
and seeing if everything works is another test and as soon as something
fails, we can add that as a new test case.
> I'm not sure what the
> bugs that needed fixing were, but I would hate to have someone upgrade
> to 2.1.10 and have them experience a StackOverflowError due to a similar
> problem.
:) The old code did not throw a StackOverflowError but simply did not
match even when it should. One example is: "*.xml" did not match
"hello.xml.xml" which it obviously should. There were a few more if
these cases.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Wildcard matcher causes StackOverflowErrors (was Re: StackOverflowError
in 2.1)
Posted by Ralph Goers <Ra...@dslextreme.com>.
Carsten Ziegeler wrote:
> Ralph Goers schrieb:
>
>> Were there test cases for the old wildcard matcher? Since this matcher
>> is almost certainly used in every Cocoon deployment we must guarantee
>> that it is 100% compatible with the old matcher in BRANCH_2_1_X -
>> unless, of course, there was some specific bug that needed fixing.
>>
>>
> There were only a few test cases for the old matcher; we have much more
> for the new one. And the old one had specific bugs that we needed to fix
> and as the old code is very ..ehm..historically grown...it is
> unmaintainable.
>
> Carsten
>
OK. But my question is really that if the old code didn't have unit
tests how do we know that the new unit tests are compatible with the old
matcher (i.e - that they get the same results)? I'm not sure what the
bugs that needed fixing were, but I would hate to have someone upgrade
to 2.1.10 and have them experience a StackOverflowError due to a similar
problem.
Ralph
Re: Wildcard matcher causes StackOverflowErrors (was Re: StackOverflowError
in 2.1)
Posted by Carsten Ziegeler <cz...@apache.org>.
Ralph Goers schrieb:
> Giacomo Pati wrote:
>> You mean the new WildcardMatcher is not behaving correctly? Any
>> TestCase to fix it? Is a match="menu/*" catching a uri="foo.html"?
> No. match="*.html" is matching on "menu/index.html".
>> I have to check that.
>>
>> Ciao
>>
>> Giacomo
> Were there test cases for the old wildcard matcher? Since this matcher
> is almost certainly used in every Cocoon deployment we must guarantee
> that it is 100% compatible with the old matcher in BRANCH_2_1_X -
> unless, of course, there was some specific bug that needed fixing.
>
There were only a few test cases for the old matcher; we have much more
for the new one. And the old one had specific bugs that we needed to fix
and as the old code is very ..ehm..historically grown...it is
unmaintainable.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Wildcard matcher causes StackOverflowErrors (was Re: StackOverflowError
in 2.1)
Posted by Ralph Goers <Ra...@dslextreme.com>.
Giacomo Pati wrote:
>
> You mean the new WildcardMatcher is not behaving correctly? Any
> TestCase to fix it? Is a match="menu/*" catching a uri="foo.html"?
No. match="*.html" is matching on "menu/index.html".
>
> I have to check that.
>
> Ciao
>
> Giacomo
Were there test cases for the old wildcard matcher? Since this matcher
is almost certainly used in every Cocoon deployment we must guarantee
that it is 100% compatible with the old matcher in BRANCH_2_1_X -
unless, of course, there was some specific bug that needed fixing.
Ralph
Re: Wildcard matcher causes StackOverflowErrors (was Re: StackOverflowError
in 2.1)
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sun, 9 Jul 2006, Ralph Goers wrote:
> Date: Sun, 09 Jul 2006 23:26:08 -0700
> From: Ralph Goers <Ra...@dslextreme.com>
> Reply-To: dev@cocoon.apache.org, rgoers@apache.org
> To: dev@cocoon.apache.org
> Subject: Wildcard matcher causes StackOverflowErrors (was Re:
> StackOverflowError in 2.1)
>
> Well, I found the source of the problem. In the sitemap the matcher for
> "*.html" was before the matcher for "menu/*". The matcher for "*.html" calls
> the "composite" resource which in turn does a map:part for
> "cocoon:/menu/{../1}.html". This is apparently matching *.html and causing
> an infinite loop. Simply moving the *.html matcher after the menu/* matcher
> causes the problem to go away.
>
> In short, unless the new wildcard matcher is 100% compatible with the old one
> it needs to be reverted in BRANCH_2_1_X.
You mean the new WildcardMatcher is not behaving correctly? Any TestCase
to fix it? Is a match="menu/*" catching a uri="foo.html"?
I have to check that.
Ciao
Giacomo
>
> Ralph
>
> Ralph Goers wrote:
>> I wanted to mess around with some of the input modules so I brought up the
>> input module page in the sample site. However, it dies with a
>> StackOverflowError. I then checked out the latest to another one of my
>> computers (with Linux instead of Windows) and got the same error.
>> Unfortunately, no stack trace is presented. I've tried going directly to
>> some of the samples on that page and can't get anything to work.
>>
>> Ralph
>
>
>
- --
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (GNU/Linux)
iD8DBQFEsfzdLNdJvZjjVZARAtj7AJ4k7VoVDr0WFsBnLnXTujWG3y8lMACglX40
Ec0R5r1YCjaOIDTjPstZmQg=
=cUAq
-----END PGP SIGNATURE-----