[lxml-dev] problems with document(''), possibly thread related

[Brad Clements]

I have a stylesheet that uses document('') to reference itself.

The stylesheet works with xsltproc and xmlstarlet on ubuntu 7.10

However when I use it in a threaded wsgi app with lxml 2.11 or 2.0, it 
does not work.

I then wrote a simple test case (thinking.. aha, I'll report this 
error), but of course the test case functions correctly.

I've spent 4 hours working on this tonight, I'm pooped, and going nuts.

basically given  an xml document whose root element is "<root />"

and a stylesheet that has:

  <xsl:value-of select="name(document('')/*)" />


 From within the threaded wsgi app, the output I get from this is 
"root", but from the test case and from xsltproc, I get "xsl:stylesheet"

My code is more or less like this:

    ss_parser = etree.XMLParser(load_dtd=True)
    ss_parser.resolvers.add(Resolver())

    stylesheet_doc = etree.fromstring(stylesheet_src, ss_parser, 
base_url='http://mystylesheet.xsl')
    stylesheet = etree.XSLT(stylesheet_doc)
   
    doc_parser = etree.XMLParser(load_dtd=True)
    doc_parser.resolvers.add(Resolver())
                              
    xml_doc = etree.fromstring(xml_src, doc_parser, 
base_url='http://myfile.xml')


however base_url is some real value when called from wsgi, it's 
threaded, and my Resolver.resolve method does get called in the wsgi 
app, but not from the test app.

Before I give up, can someone suggest ways in which using lxml from 
within a threaded app might somehow "break" resolving document(''), but 
non-threaded it works ok?

I don't think I'm using the same parser object for the stylesheet and 
xml document, the real wsgi code is a tad complicated. However the 
stylesheet and xml document should be parsed and used within the same 
thread (which just happens to not be the main thread)

I believe this works ok on lxml 1.1.2, but I've already updated my code 
to use 'base_url' and so forth and I'm too worn out to change all that 
code just to test a theory.

So .. any ideas on what could cause this? thanks for any suggestions..



-- 
Brad Clements,                bkc at murkworks.com    (315)268-1000
http://www.murkworks.com                          
AOL-IM: BKClements