You are viewing a plain text version of this content. The canonical link for it is here.
Posted to axkit-dev@xml.apache.org by Matt Sergeant <ma...@sergeant.org> on 2004/04/18 21:34:30 UTC
The axkit: URI bug...
OK, I'm finally tracking down this bug. Unfortunately I've run out of
time now, so I'll document what I've found in case someone else has
chance to fix it before me...
Basically the problem lies within nested callbacks. Within
XML::LibXSLT's LibXML.xs/transform() function is this snippet:
xmlRegisterInputCallbacks((xmlInputMatchCallback)
LibXSLT_input_match,
(xmlInputOpenCallback) LibXSLT_input_open,
(xmlInputReadCallback) LibXSLT_input_read,
(xmlInputCloseCallback)
LibXSLT_input_close);
real_dom = xsltApplyStylesheet(self, doc, xslt_params);
xmlCleanupInputCallbacks();
xmlRegisterDefaultInputCallbacks();
Which registers LibXSLT specific callbacks. But LibXSLT doesn't *have*
its own callback mechanism as you can see - it hijacks LibXML's
callback system...
So if within the callback you do some other parse, such as an axkit:
URI call, the callbacks get reset at the end. This means that while the
open() callback gets called, the read() callback never happens because
that callback is now libxml's default callback.
So what's the solution? Dunno. Perhaps once again remove LibXSLT's
callback mechanism. Or perhaps have a "temp" storage of current
callbacks and restore them after the call to xsltApplyStylesheet. The
latter is probably the only proper solution, but will be more work.
That's all I have time for right now.
Matt.