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.