cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bernhard Huber" <>
Subject Re: BUG 5060, CommandlineContext
Date Sun, 30 Dec 2001 14:39:54 GMT

>>>Thanks Bernhard, setting fork="yes" in build.xml was the trick.
>>>The test cases now run for me.
I update the build.xml having set fork="yes for the test target.

>I see now. I mistakenly thought that some subsequent changes
>would be needed to ResolverImpl. Yes, the key thing was to
>get a reliable absolute path from getResource() ... i think that
>you have probably squashed a bug that had wider implications
>than just CatalogResolver.
Maybe, but as "build docs" is the main usage of the CommandlineContext 
and it has worked before except of the Resolver, I think no more opened 
bugs are solved by this modification.
btw, how, and when should we close the BUG 5060?

>It does for me on Linux and i gather so too for you on Win.
Yes, of course for me on Win.

>>ResolverImpl is okay, you may discuss adding in dispose() releasing the 
>>CatalogResolver, but that should happen anyway.
>>For short I was thinking files like ISOnum.pen are not released, as I 
>>was unable to delete the temporarily test file ISOnum.pen which is 
>>created in directory specified by
>>But closing the InputStream, respectivly Reader in the testX() method, 
>>solved that.
>This is interesting. I just assumed that the parser was taking
>care of that. The parser called the resolveEntity() method to
>get the alternative local InputSource. If that returned null, then
>it would need to open its own source as specified by the
>original systemIdentifier declared in the XML instance document.
>I expected that the parser would close the stream in both
I hope the xml-parser is taking care of that.
But in the test-case there is no parser reading the resolved entitiy. 
The testcase asks ResolverImpl directly to resolve the entity 
"ISOnum.pen". Hence the testcase has to close the streams of the 

>>I hope you enjoyed running the test, I "dream" adding more testcases. It 
>>should help to make Cocoon more stable, and help it to add more grazy 
>>features without loosing the wonderful features already available.
>>bye bernhard
>The test case method a was brilliant way to prove that your
>solution worked. I gather that we will leave these testcases
>in place and refine them to become a testing tool for the
>local site manager.
In principal I see several possibilities using the test-cases:
1) Help communicating between users, and developers. Sending the log of 
 a test case, will help to understand problems better, and understanding 
the technical reason of the problem.
(This way the problem of fork="yes" was resolved.)
2) Testcases should help to assert that Cocoon develops further in a 
stable way.
3) As a pre-deployment task, before a Cocoon version is deployed into 
its environment (Servlet, Commandline)
you can check, if this version is okay.
4) A limitation is perhaps that it should/may not require a certain 
environment. Thus running for example JSPGenerator test cases might be 
not possible without a servlet-environment. But perhaps anteater might 
help in that respect.
5) Adding a <junitreport> in the build.xml will even allow to see 
html-format test-results.
6) Currently I'm not 100% satisified that all the log information is 
displayed on System.out, this requires changing the ExcaliburTestCase (i 

The only "trouble" is writing, and maintaining  the testcases takes a 
bit time...

bye bernhard

To unsubscribe, e-mail:
For additional commands, email:

View raw message