etree.XSLT logging exception

Using lxml 2.2.8 on Python 2.4, I am wresting with a problem that I have never seen before: Exception Type: TypeError Exception Value: Cannot convert lxml.etree._RotatingErrorLog to lxml.etree._BaseErrorLog This happens when calling etree.XSLT(xsltdoc). I may be able to provide more details if it's helpful, but really I guess I'd just like to disable lxml's logging altogether, if that's possible -- at least to eliminate that as the real source of the problem. The error *sounds* like it's trying to rotate a log and can't do it, maybe due to an IOError (permissions or something). I have no idea where it's trying to write this log. As I said, I've been using lxml for a long time and never experienced this error before. I'd appreciate any clues to this mystery. Thanks, David -- David Chandek-Stark dchandekstark@gmail.com

As a followup I can report the same error occurs with lxml 2.3. However, with lxml 2.1.5 the etree.XSLT(xslt_doc) call raises an XSLTParseError: Exception Value: Cannot resolve URI /path/to/common-indexed-data-source-functions.xsl where this line is in the original xslt_doc: <xsl:include href="common-indexed-data-source-functions.xsl" /> which is weird b/c it's in the same dir as the original xslt doc. Also, I cannot reproduce the original problem (with 2.2.8) on a test server with an identical python virtual environment. (Obviously there could be other things different about the systems, but I'm not sure where to look.) --David On Thu, May 26, 2011 at 1:41 PM, David Chandek-Stark < dchandekstark@gmail.com> wrote:
-- David Chandek-Stark dchandekstark@gmail.com

David Chandek-Stark, 26.05.2011 19:41:
I've never seen this either. It makes no sense at all, _REL inherits from _BEL. Please always provide the exception stack trace, not only the message.
It's not I/O related, the _RotatingErrorLog simply keeps a bounded list of error messages in memory. Stefan

Here's the traceback: Traceback (most recent call last): File "/opt/pythonenv/catalog/lib/python2.4/site-packages/librarycatalog/views.py", line 168, in account transform = etree.XSLT(xslt_doc) File "xslt.pxi", line 395, in lxml.etree.XSLT.__init__ (src/lxml/lxml.etree.c:108690) File "lxml.etree.pyx", line 228, in lxml.etree._ExceptionContext._raise_if_stored (src/lxml/lxml.etree.c:6808) TypeError: Cannot convert lxml.etree._RotatingErrorLog to lxml.etree._BaseErrorLog --David On Thu, May 26, 2011 at 2:48 PM, Stefan Behnel <stefan_ml@behnel.de> wrote:
-- David Chandek-Stark dchandekstark@gmail.com

Stefan, BTW, the full lxml/libxml2/libxslt versions on both the working and problem systems are: lxml 2.2.8 libxml2 2.6.26 libxslt 1.1.17 However, there is a difference between the Python builds: Working system: Python 2.4.3 (#1, Sep 3 2009, 15:37:37) [GCC 4.1.2 20080704 (Red Hat 4.1.2-46)] on linux2 Problem system: Python 2.4.3 (#1, May 5 2011, 16:39:10) [GCC 4.1.2 20080704 (Red Hat 4.1.2-50)] on linux2 --David On Thu, May 26, 2011 at 3:23 PM, David Chandek-Stark < dchandekstark@gmail.com> wrote:
-- David Chandek-Stark dchandekstark@gmail.com

David Chandek-Stark, 27.05.2011 03:27:
Hmm, ok, in that case, I must assume that there's something broken with the newer Python installation on your system. Assuming this is on two different machines, I'd try to copy over the Python installation from the working system to the broken one to see if it works there. CPython 2.4.3 is really old and long out of maintenance. I wouldn't be surprised if it had subtle difficulties when entering newer environments. Or maybe you just forgot to build lxml with "-fno-strict-aliasing" or something like that (that's a general Py2.x requirement). Stefan

We're using the OS package (RHEL/CentOS) for Python 2.4 (and sadly, we may be stuck on 2.4 for the time being). In any case, I installed lxml with pip (I think I've always used pip or easy_install). Since downgrading lxml to 2.1.5 caused a different exception which pointed to problems loading included stylesheets, we're trying taking out the includes to see if that fixes the issue. Unfortunately, we're observing inconsistent results with the current problem -- sometimes the exception gets triggered, sometimes not. Thanks, David On Fri, May 27, 2011 at 2:54 AM, Stefan Behnel <stefan_ml@behnel.de> wrote:
-- David Chandek-Stark dchandekstark@gmail.com

FWIW, it seems that getting rid of <xsl:include>s fixes the problem. To give the fuller context, the xslt_doc is created by etree.parse() using a file path not a URL: xslt_doc = etree.parse('/path/to/file') transform = etree.XSLT(xslt_doc) Then in the XSLT doc the includes used relative paths (just file names, as they're all in the same dir). I don't know if that sheds any further light on the situation. Due to the inconsistency of the problem, it's hard to say whether the "working" system was actually stable. We're still testing, but removing the includes appears to stabilize the outcome. --David On Fri, May 27, 2011 at 9:51 AM, David Chandek-Stark < dchandekstark@gmail.com> wrote:
-- David Chandek-Stark dchandekstark@gmail.com

As a followup I can report the same error occurs with lxml 2.3. However, with lxml 2.1.5 the etree.XSLT(xslt_doc) call raises an XSLTParseError: Exception Value: Cannot resolve URI /path/to/common-indexed-data-source-functions.xsl where this line is in the original xslt_doc: <xsl:include href="common-indexed-data-source-functions.xsl" /> which is weird b/c it's in the same dir as the original xslt doc. Also, I cannot reproduce the original problem (with 2.2.8) on a test server with an identical python virtual environment. (Obviously there could be other things different about the systems, but I'm not sure where to look.) --David On Thu, May 26, 2011 at 1:41 PM, David Chandek-Stark < dchandekstark@gmail.com> wrote:
-- David Chandek-Stark dchandekstark@gmail.com

David Chandek-Stark, 26.05.2011 19:41:
I've never seen this either. It makes no sense at all, _REL inherits from _BEL. Please always provide the exception stack trace, not only the message.
It's not I/O related, the _RotatingErrorLog simply keeps a bounded list of error messages in memory. Stefan

Here's the traceback: Traceback (most recent call last): File "/opt/pythonenv/catalog/lib/python2.4/site-packages/librarycatalog/views.py", line 168, in account transform = etree.XSLT(xslt_doc) File "xslt.pxi", line 395, in lxml.etree.XSLT.__init__ (src/lxml/lxml.etree.c:108690) File "lxml.etree.pyx", line 228, in lxml.etree._ExceptionContext._raise_if_stored (src/lxml/lxml.etree.c:6808) TypeError: Cannot convert lxml.etree._RotatingErrorLog to lxml.etree._BaseErrorLog --David On Thu, May 26, 2011 at 2:48 PM, Stefan Behnel <stefan_ml@behnel.de> wrote:
-- David Chandek-Stark dchandekstark@gmail.com

Stefan, BTW, the full lxml/libxml2/libxslt versions on both the working and problem systems are: lxml 2.2.8 libxml2 2.6.26 libxslt 1.1.17 However, there is a difference between the Python builds: Working system: Python 2.4.3 (#1, Sep 3 2009, 15:37:37) [GCC 4.1.2 20080704 (Red Hat 4.1.2-46)] on linux2 Problem system: Python 2.4.3 (#1, May 5 2011, 16:39:10) [GCC 4.1.2 20080704 (Red Hat 4.1.2-50)] on linux2 --David On Thu, May 26, 2011 at 3:23 PM, David Chandek-Stark < dchandekstark@gmail.com> wrote:
-- David Chandek-Stark dchandekstark@gmail.com

David Chandek-Stark, 27.05.2011 03:27:
Hmm, ok, in that case, I must assume that there's something broken with the newer Python installation on your system. Assuming this is on two different machines, I'd try to copy over the Python installation from the working system to the broken one to see if it works there. CPython 2.4.3 is really old and long out of maintenance. I wouldn't be surprised if it had subtle difficulties when entering newer environments. Or maybe you just forgot to build lxml with "-fno-strict-aliasing" or something like that (that's a general Py2.x requirement). Stefan

We're using the OS package (RHEL/CentOS) for Python 2.4 (and sadly, we may be stuck on 2.4 for the time being). In any case, I installed lxml with pip (I think I've always used pip or easy_install). Since downgrading lxml to 2.1.5 caused a different exception which pointed to problems loading included stylesheets, we're trying taking out the includes to see if that fixes the issue. Unfortunately, we're observing inconsistent results with the current problem -- sometimes the exception gets triggered, sometimes not. Thanks, David On Fri, May 27, 2011 at 2:54 AM, Stefan Behnel <stefan_ml@behnel.de> wrote:
-- David Chandek-Stark dchandekstark@gmail.com

FWIW, it seems that getting rid of <xsl:include>s fixes the problem. To give the fuller context, the xslt_doc is created by etree.parse() using a file path not a URL: xslt_doc = etree.parse('/path/to/file') transform = etree.XSLT(xslt_doc) Then in the XSLT doc the includes used relative paths (just file names, as they're all in the same dir). I don't know if that sheds any further light on the situation. Due to the inconsistency of the problem, it's hard to say whether the "working" system was actually stable. We're still testing, but removing the includes appears to stabilize the outcome. --David On Fri, May 27, 2011 at 9:51 AM, David Chandek-Stark < dchandekstark@gmail.com> wrote:
-- David Chandek-Stark dchandekstark@gmail.com
participants (2)
-
David Chandek-Stark
-
Stefan Behnel