I've been using AxKit without a hitch for over a month, then had a small, strange problem with path handling (not pertinent for the present discussion). As a troubleshooting technique, I decided to update libxml2, libxslt, the associated Perl modules, and AxKit to the latest versions (libxml2 2.6.2, libxslt 1.1.0, XML-LibXML-Common 0.13, XML-LibXML-Common 0.13, XML-LibXSLT 1.53, and the latest CVS sources for AxKit). This went well enough until I tested AxKit -- 4 failures -- uri/axkit.t, xslt-basic/02_include.t, xslt-basic/03_document_1arg.t, and xslt-basic/04_document_2args.t, i.e., the tests involving external file references in XSLT stylesheets. Upon investigation, it appears that the libxml2 I/O callbacks (match_cb, open_cb, etc.) aren't getting triggered. A kernel trace of the httpd process running uri/axkit.t shows this:
26863 httpd CALL stat(0x1119210,0xbfffe2e0) 26863 httpd NAMI "axkit:./subrequest.xml" 26863 httpd RET stat -1 errno 2 No such file or directory (this is from Mac OS X 10.3) I tried several versions of the various libraries and AxKit 1.6.2, similar results. I also tried on a FreeBSD 5.1 machine: 95879 httpd CALL stat(0x80f92e0,0xbfbfecd0) 95879 httpd NAMI "axkit:./subrequest.xml" 95879 httpd RET stat -1 errno 2 No such file or directory I tried the suggestions in the "AxKit 1.6.2 xslt-basic tests failing on RH 7.3" thread in re removing catalog support from AxKit, same results. This is not suprising, because it's _finding_ the catalog and reading it just fine on the BSD box, besides, I thought the problem was that the callbacks were looking for the catalog in the Web root; on the OS X machine, it's failing to find /etc/xml/catalog, but it's looking for it "in the right place", it's just not there; I thought it was the subrequest that was killing us -- on an unrelated note, do we fail if catalog support is enabled but the catalog is not found? If so, why, as the same thing works fine outside of AxKit (not the "axkit:" URL, naturally, but external documents in LibXSLT, with or without I/O callbacks). There has to be something astonishingly simple I'm missing, as prior to this I had installed AxKit on several machines with several different library versions and haven't seen this problem until now. FWIW, the OS X 10.3 machine is running Perl 5.8.1 (my build, not Apple's), Apache 1.3.29 (likewise), and mod_perl 1.29, and the FreeBSD 5.1 machine is running the same versions, with the exception of Perl 5.8.2. All Apaches are statically linked, no DSOs at all. I've tested LibXML callbacks within LibXSLT within mod_perl with test handlers (using the LibXSLT transform() method, just like AxKit), and they work just fine. What could be making them fail for AxKit? Just realized as I was typing this, these are the first installs with 1.3.29 (last time I was running 1.3.28). Could this be the problem? Cheers, Jason T. Miller [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
