Since you are very XML-programming aware, could you check how the entity resolver is working for the <style> task? Last time I tried to <style> an ANT build file that includes a ./fragment.xml, and call ANT from a different directory than the one the build and fragment files are, it fails (but the ANT build files works, so ANT itself resolve the entity correctly, wherever called from). --DD
-----Original Message----- From: Craeg K Strong [mailto:[EMAIL PROTECTED] Sent: Monday, June 03, 2002 1:09 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: [PATCH] Fix for XMLCatalog for EntityResolver from document() function Hello: Attached please find a fix for <xmlcatalog> This is for a certain boundary condition that I originally failed to test. namely: it was not properly setting the EntityResolver on a _new_ XML parser instance spawned in response to an XSLT document() function in the case where the URI being resolved was not present in the <xmlcatalog> as an entry. (whew!) It was a 6 line change. The first thing I did was add a new test for this condition: XMLCatalogBuildFileTest.java (The original XMLCatalogTest.java inherits from TestCase; this one inherits from BuildFileTest. We need 'em both :-) The new test fails with the old code. The new test succeeds with the new code. The test makes use of several ancillary files, which I have put in src/etc/testcases/types, including a buildfile "xmlcatalog.xml" which can also be run by hand (see -projecthelp) Because the new test makes use of the <style> task, I put the proper <exclude> directives in build.xml for it. I tested this with xalan/saxon/no-xslt on both Linux and win32. Everything is in the zip. Thanks to Christian for pointing this out, and to Erik for cc-ing me on the message! (I don't subscribe to ant-user) Regards, --Craeg -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
