cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Crossley <cross...@indexgeo.com.au>
Subject Re: BUG 5060, CommandlineContext
Date Sun, 30 Dec 2001 13:44:13 GMT
Go you beauty! ... Bernhard and i corresponded offlist
over his JUnit tests for the Catalog Resolver. The tests
proved that his mods to CommandlineContext.java worked
and we can both now build docs.

So people on both Win* and *nix platforms should be
free of this blocker bug. You should be able to:
1) use the sample "Entity Catalogs" from the Welcome page
2) run "build docs" and get past "catalog-test.xml"
3) run "build test" and pass the Catalog Resolver tests.

Bernhard Huber wrote:
> David Crossley wrote:
> >Thanks Bernhard, setting fork="yes" in build.xml was the trick.
> >The test cases now run for me.
> 
> great
> 
> >Hooray, there were no errors reported and the ResolverImpl
> >testcase seemed to be resolving its entities properly.
> >It seems that all is OK now for Win and Linux.
>
> that's good news
> 
> >So will you now proceed to make the necessary changes to
> >ResolverImpl.java proper?
>
> no, that's already, to fix bug 5060, as far as I think. As Bug 5060
> only appeared in "build docs", changing CommandlineContext
> only is enough. As it returnde some strange URL for its getResource()
> method.

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.

> Try running build docs including the catalog-test in book.xml!
>   <menu label="Tests">
>     <menu-item label="Catalog Test" href="catalog-test.html"/>
>   </menu>
> 
> It should work now!


It does for me on Linux and i gather so too for you 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 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.
--David Crossley

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message