Created attachment 1147678 [details] example.xsl Description of problem: > $ java com.sun.org.apache.xalan.internal.xsltc.cmdline.Compile example.xsl java.lang.NullPointerException > at com.sun.org.apache.xalan.internal.xsltc.compiler.Parser.parse(Parser.java:496) > at com.sun.org.apache.xalan.internal.xsltc.compiler.XSLTC.compile(XSLTC.java:466) > at com.sun.org.apache.xalan.internal.xsltc.compiler.XSLTC.compile(XSLTC.java:392) > at com.sun.org.apache.xalan.internal.xsltc.compiler.XSLTC.compile(XSLTC.java:528) > at com.sun.org.apache.xalan.internal.xsltc.cmdline.Compile.main(Compile.java:146) > Compiler errors: > Could not compile stylesheet Version-Release number of selected component (if applicable): $ java -version openjdk version "1.8.0_72" OpenJDK Runtime Environment (build 1.8.0_72-b16) OpenJDK 64-Bit Server VM (build 25.72-b16, mixed mode) How reproducible: always Steps to Reproduce: 1. download attached example xsl straight from wikipedia 2. execure command in description 3. Actual results: NPE Expected results: Properly compiled style Additional info: I tried with regular xalan and template is correct. I also tried other simple templates and empty template. All fail in the same way.
I reproduced this on OpenJDK 6, 7 and 8. It seems to be down to the security fix S8014530, CVE-2013-5825: "Better digital signature processing". This adds the use of XMLSecurityManager. In com.sun.org.apache.xalan.internal.xsltc.trax.Util, the code checks that the security manager is not null first: + if (securityManager != null) { + for (XMLSecurityManager.Limit limit : XMLSecurityManager.Limit.values()) { + reader.setProperty(limit.apiProperty(), + securityManager.getLimitValueAsString(limit)); + } but in Parser, where the above crash occurs: + XMLSecurityManager securityManager = + (XMLSecurityManager)_xsltc.getProperty(XalanConstants.SECURITY_MANAGER); + for (XMLSecurityManager.Limit limit : XMLSecurityManager.Limit.values()) { + reader.setProperty(limit.apiProperty(), securityManager.getLimitValueAsString(limit)); + } which is the code that fails. So it looks like the fix would just be the addition of a null check, but this is worth raising upstream to check that's the right solution.
Created attachment 1202866 [details] TestXslt.java: Java API test case
Created attachment 1202867 [details] Example XML to transform
It looks to me it's an issue specifically to com.sun.org.apache.xalan.internal.xsltc.cmdline.Compile and how it uses XSLTC. The test case in comment 3 works fine without NPE[1]. The reason for this is that if proper Java API is being used, code path goes through TransformerFactoryImpl.newTemplates() which sets the XML security manager property for XSLTC to a non-null value. In fact, JDK 9 no longer has the Compile class. [1] person.xml.in is from comment 4. $ javac TestXslt.java $ java TestXslt example.xsl person.xml.in <?xml version="1.0" encoding="UTF-8"?><root> <name username="JS1">John</name> <name username="MI1">Morka</name> </root> This works for JDK 6 through JDK 9 in my testing.
Sorry, it is unclear to me from all the comments above -- do we have a fix for this then?
(In reply to Deepak Bhole from comment #6) > Sorry, it is unclear to me from all the comments above -- do we have a fix > for this then? No, not really. I've tried to reproduce this issue by using supported Java API only, but I failed. Also note that JDK 9 no longer has this com.sun.org.apache.xalan.internal.xsltc.cmdline.Compile class, so it's not an issue there. Either way, it seems an untested/obscure use-case :)
(In reply to Severin Gehwolf from comment #7) > (In reply to Deepak Bhole from comment #6) > > Sorry, it is unclear to me from all the comments above -- do we have a fix > > for this then? > > No, not really. I've tried to reproduce this issue by using supported Java > API only, but I failed. > > Also note that JDK 9 no longer has this > com.sun.org.apache.xalan.internal.xsltc.cmdline.Compile class, so it's not > an issue there. Either way, it seems an untested/obscure use-case :) Fair enough. So if it is not reproducible with the Java api, does that put the fix out of our scope? In that case, whats the right component to reassign to, or should we close this?
As noted in comment #1, this can be reproduced on OpenJDK 6, 7 and 8 as specified in the original bug report. As noted in comment #1, it looks like just a null check is missing, but I haven't tested a fix for this yet. Given the bug was already assigned to someone else at the time, I left it for them to work on. I do think this is fixable and, from the code, the issue seems to still be there in 9, but https://bugs.openjdk.java.net/browse/JDK-8130238 removed the Compile class. I guess the question is; does Compile get used in the wild?
I used it for testing purposes: 1. to do quick cli XSLT 2. to make sure something specifically works with the JVM implementation of XSLT So it is convenient and nice to have something working without compiling custom classes. About how much used, there are a number of stackoverflow questions about XSLT on command line. So it seems people are interested to be able to do this. Specifically this approach is in: http://stackoverflow.com/questions/8535947/xslt-2-0-transformation-via-linux-shell IMO if the fix is straightforward, I think it's good to have it although I understand priority might not be very high. Also would appreciate a recommendation about jdk9 alternative approach.
(In reply to Aleksandar Kostadinov from comment #10) > I used it for testing purposes: > 1. to do quick cli XSLT Use xsltproc? I.e. $ xsltproc example.xsl persons.xml.in > 2. to make sure something specifically works with the JVM implementation of > XSLT There should be no difference in the Java implementation. If there are differences, it's a bug. > So it is convenient and nice to have something working without compiling > custom classes. Understood. I'm not sure if providing that should be the purpose of the java platform itself, though. Have you considered asking for this RFE on the OpenJDK mailing list for jaxp: http://mail.openjdk.java.net/mailman/listinfo/core-libs-dev > About how much used, there are a number of stackoverflow questions about > XSLT on command line. So it seems people are interested to be able to do > this. Specifically this approach is in: > http://stackoverflow.com/questions/8535947/xslt-2-0-transformation-via-linux- > shell > > IMO if the fix is straightforward, I think it's good to have it although I > understand priority might not be very high. Also would appreciate a > recommendation about jdk9 alternative approach. FWIW, TestXslt (see comment 5) does a simplified command-line transformation of xml + xsl files. Works on JDK 9 too. It would need to get extended to support entity expansions, etc.
xsltproc is v1 AFAIK wrt "There should be no difference", I have noticed in the past some differences dealing with namespaces. wrt "Have you considered asking for this RFE on the OpenJDK mailing list for jaxp" no, because it's been an existing feature, just stopped working. If there's no other option in jdk9, then I will consider it.
(In reply to Aleksandar Kostadinov from comment #12) > xsltproc is v1 AFAIK So is the reference impl for JAXP in JDK 8, AFAIK[1]. [1] https://jaxp.java.net/1.6/index.html
Strange, I believe I used some things that didn't work with xsltproc but worked with jdk. I have to dig some things out. Not doing lot with java lately.
This message is a reminder that Fedora 23 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 23. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '23'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 23 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.