Hi, >>>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 java.io.tempdir. >>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 >circumstances. > 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 InputSource. >>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 think). The only "trouble" is writing, and maintaining the testcases takes a bit time... bye bernhard --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
