I have a set of XSLT stylesheets that were working fine previously. Recently, a fellow developer upgraded our Perl to a newer version. Ever since that time, we have been getting intermittent stylesheet compilation errors where EXSLT functions are defined.
Here is an example of the error:
element param only allowed within a template, variable or param
The variable is defined within the EXSLT function. Once the error is received, I will get the error every time that I try to access my web page until I restart Apache (used in conjunction with mod_perl). After restarting, I can get the web page calling XML::LibXSLT and the EXSLT function to display properly once, but reloading the page will trigger the error again.
After reading the XML::LibXSLT docs, I have confirmed that the HAVE_EXSLT() function returns a value of 1. My current version of XML::LibXSLT is 1.79. My LibXSLT DLL is 1.1.28. My perl version is 5.14.3. The previous versions that worked were 5.8.8, 1.66, and 1.1.22, respectively.
Why am I now seeing these errors when I previously did not? Below is the beginning snippet from the stylesheet that is throwing compilation errors. Please let me know if there is any additional information that would be useful to provide.
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:exsl="http://exslt.org/common"
xmlns:func="http://exslt.org/functions"
xmlns:dtbl="http://docbook.sourceforge.net/dtbl"
extension-element-prefixes="func"
exclude-result-prefixes="exsl func dtbl"
version="1.0">
<func:function name="dtbl:convertLength">
<xsl:param name="arbitrary.length"/>
Additional findings:
After my initial posting of this question, I discovered that I cannot reproduce the error at all if I use plain old CGI instead of mod_perl. Additionally, I found the following line in my Apache httpd.conf. When commenting it out, I saw that the frequency of the error occurrence dropped dramatically, although it did not completely remove the error.
PerlModule XML::LibXSLT;
From experience mod_perl does a lot of funny things for example JSON::XS works terrible under mod_perl and causes a serious memory leak + stuck process, so I moved to JSON::Tiny which is a native and simple code - which mod_perl can handle
I have a feeling that XML::LibXSLT has the same issue, I migrated my code from XML::LibXSLT to using native xsltproc for this reason, yes it requires spawning, but if you do it right, the overhead isn't worse that what you are doing now, and it is more stable
So my suggestion is to either move from XML::LibXSLT to xsltproc (binary) which I use under mod_perl without issues, or to find some other library to do the XSLT conversion for you (maybe FOP ? )
Related
I have a Catalyst application that uses Template Toolkit.
We recently decided to reorganise some of the tests so that some are skipped unless AUTHOR_TESTING or RELEASE_TESTING variables are set (which would be set for automated continuous integration tests).
Apparently when either the AUTHOR_TESTING or RELEASE_TESTING is set, some of the pages die with an error in the Catalyst view rendering stage:
Couldn't render template "[path to template]: undef error - "
A bit of searching on the web found something about enabling debugging at http://lists.scsys.co.uk/pipermail/catalyst/2007-March/012548.html but this is unhelpful.
I've run a grep for these environment variables in the installed Perl modules and Carton local library, in the hopes of finding the code that uses them. They only seem to be referenced by testing and Module-Build.
Can anyone help with identifying the cause of this?
After a bit of exploration and trial and error, it turns out that a custom method in the view (added to the template using expose_methods) died via Devel::StrictMode.
I have an existing CentOS 7 server (setup by someone else, of course) running Saxon. If I run:
/usr/bin/java net.sf.saxon.Transform -s:input.xml -xsl:input.xsl -o:output.xml
...it works perfectly.
On a new server, I've installed Saxon via "yum install saxon". If I attempt the same command, it fails with the error:
Error at HTML on line 19 column 38 of 2.xsl:
XTSE0150: Simplified stylesheet: xsl:version attribute is missing
Failed to compile stylesheet. 1 error detected.
If I download the latest Saxon from sourceforge.net/projects/saxon, redirect my CLASSPATH from the yum-installed saxon.jar (dated 2014!) to the jar files from sourceforge, the transform works perfectly.
So, I have a FIX for the problem (i.e. use the latest from sourceforge, not CentOS's out-dated version) but I'm still curious as to what's going on.
Is this simply some old bug that's fixed in a newer release? Or maybe I'm missing supporting files that are in the sourceforge-derived jars, but not in the yum-derived files? Or something else???
For what it's worth, here's the head of my XSLT file. The error is specifically pointing at the end of the xsl:stylesheet tag, although there is clearly a "version=" setting in that config:
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:oai_dc="http://www.openarchives.org/OAI/2.0/oai_dc/"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:oai-pmh="http://www.openarchives.org/OAI/2.0/"
xmlns:oai_qdc="http://worldcat.org/xmlschemas/qdc-1.0/"
xmlns:dcterms="http://purl.org/dc/terms/"
xmlns:dcmitype="http://purl.org/dc/dcmitype/"
xmlns:edm="http://www.europeana.eu/schemas/edm/"
xmlns:oclcdc="http://worldcat.org/xmlschemas/oclcdc-1.0/"
xsi:schemaLocation="http://worldcat.org/xmlschemas/qdc-1.0/
http://worldcat.org/xmlschemas/qdc/1.0/qdc-1.0.xsd
http://purl.org/net/oclcterms
http://worldcat.org/xmlschemas/oclcterms/1.4/oclcterms-1.4.xsd"
exclude-result-prefixes="xs"
version="2.0"
xmlns="http://www.loc.gov/mods/v3">
Given that the code works perfectly fine with the alternate Saxon install, I don't believe that there's a problem with the code. It's something else, but I don't know what...
You can find out which version of Saxon is in a particular JAR file by doing
java -cp saxon.jar net.sf.saxon.Version
and this would be a lot more useful than just telling us where you installed it from.
The error message suggests to me that the "stylesheet" being used is actually not a stylesheet at all, but an ordinary XML document. (Saxon sees that the root element isn't xsl:stylesheet, so it decides it must be a simplified stylesheet; then it looks for the xsl:version attribute, finds that there isn't one, and complains).
I don't know exactly what's wrong here, but the application is using an invocation of Saxon that works with one release and doesn't work with the other. There haven't been many incompatible changes to the command line interface over the 20 years of Saxon's life, but there have been a few, and I suspect one of these Saxon versions is very old indeed.
AFTERTHOUGHT
There's another clue which I missed on first reading: the error message refers to a file called 2.xsl. From the supplied information, we can't see what 2.xsl is. It must be the file that appears to be a stylesheet but isn't... But why does it have a different name? Certainly the fact that your file has the end of the start tag at line 19, and so does this mystery file, appears significant. Perhaps there's some script that's being executed before Saxon actually gets invoked, and that creates 2.xsl?
I am using php-cs-fixer for code formatting in Netbeans 8.2. When I try to format one file, it shows the error
Files that were not fixed due to errors reported during linting after fixing:
I searched for the fix in many websites, but couldn't get this fixed. Is there any way to fix this? I tried with both php-cs-fixer 1 and php-cs-fixer 2.
The error message means that PHP CS Fixer loaded some files from drive, apply changes on them, and then realised that files are not valid anymore (invalid PHP syntax) after those changes, thus it decided to not save it. That's one of the safety mechanism of PHP CS Fixer to not break your project.
This means that you have found an issue in PHP CS Fixer itself.
Please, verify you are using newest release, maybe the bug was already fixed!
If not, please consider to expose your configuration file (if any) and content of files you got listed at https://github.com/FriendsOfPHP/PHP-CS-Fixer/issues/new !
There is also an option to see what happen in progress.
$ ./vendor/bin/php-cs-fixer fix src/ErrorFile.php -vvv
The --verbose option will show the applied rules. When using the txt format it will also display progress notifications.
NOTE: if there is an error like "errors reported during linting after fixing", you can use this to be even more verbose for debugging purpose
-v: verbose
-vv: very verbose
-vvv: debug
Good morning guys,
I just built a CentOS server with php 7.0.13 and apache 2.2 and the strangest thing is happening when testing it.
I had a curl script that works perfectly well through the command line but not when invoked through the browser, after investigating a bit, I realized that I can also not write to files if I do it through the browser, but I have no problem whatsoever doing it through the command line.
I assumed that the problem would be on two different php.ini files, but after verifying the phpinfo I realized that both the CL and the browser are loading the same, and all extensions seem to be loading correctly as well, by using get_current_user() I can also verify that the same user is executing both. I would assume the problem would be in apache, but I have no clue as to what could be causing it.
Can someone point out to possible avenues to solve the issue? I have no idea what to do from this point onwards.
As Hassan indicated the problem was with the user executing the script.
I commited an error thinking get_current_user() indicates the user executing the script, it does not, it indicates the file owner.
If you have a similar problem and need to figure who is executing the script use exec('whoami'); instead.
EDIT:Ok although that was one of the errors, the main error was on the fact that SELinux was activated, as soon as I deactivated the scripts started working perfectly.
I am just getting started with setting up an app using Perl Dancer on Apache. I used the provided dancer script to setup my initial directory structure, and was able to get things setup to the point of seeing the initial "Perl is Dancing" page. Unfortunately, I noticed that the very end of the HTML markup is not included when I do a view source. Further investigation with Fiddler revealed the following error:
Content-Length mismatch: Response Header indicated 3,168 bytes, but server sent 3,364 bytes.
After seeing this, I did some additional experimentation, running the Dancer app directly via invoking app.pl from the command line. When I access that server, I get the full HTML markup and not content-length issues are reported by Fiddler.
Does anyone have any ideas why I may be seeing this incorrect content length issue when running through Apache? I should also mention that I am running through the generated CGI script that invokes app.pl via Plack::Runner. Please let me know if I need to provide additional details.
Dancer version is 1.3030 and Plack version is 0.9976.
It turns out that there was an issue with Plack. The revision history mentions "Fixed a CGI/FastCGI handler to ensure newlines are not mangled on Win32 platforms" for version 0.9977 (I failed to mention previously that I am running on Win32). I updated Plack to the latest version (currently 0.9978), and the problem went away.