On Nov 26, 2017, at 6:32 AM, Matthew Broadhead <matthew.broadh...@nbmlaw.co.uk> wrote: > > Hi, > I am currently evaluating whether the Xalan dependency can be dropped from > taglibs and replaced with javax.xml.*. > > The reason for this is a conflict which occurs when I have Apache Fop as a > dependency: > java.lang.ClassCastException: org.apache.xml.dtm.ref.DTMManagerDefault cannot > be cast to org.apache.xml.dtm.DTMManager > at org.apache.xml.dtm.DTMManager.newInstance(DTMManager.java:137) > at org.apache.xpath.XPathContext.<init>(XPathContext.java:102) > at org.apache.xpath.XPathContext.<init>(XPathContext.java:349) > at org.apache.xpath.XPathContext.<init>(XPathContext.java:337) > at > org.apache.xalan.transformer.TransformerImpl.<init>(TransformerImpl.java:397) > at > org.apache.xalan.templates.StylesheetRoot.newTransformer(StylesheetRoot.java:200) > > In org.apache.taglibs.standard.tag.common.xml it seems like > org.apache.xpath.XPath could be replaced with javax.xml.xpath.XPathExpression. > > But the thing I don't understand is the method getContext in > org.apache.taglibs.standard.tag.common.xml.XalanUtil uses a VariableStack and > returns an XPathContext. I am not sure how they fit into the SAX (?) model. > > Can anyone shed some light on the inner workings of this function?
This was added <https://svn.apache.org/viewvc?view=revision&revision=1054175> in 1.2.x to fix a performance problem (bug #27717 <https://bz.apache.org/bugzilla/show_bug.cgi?id=27717>) with x:forEach. At the time, the default XPath implementation in javax.xml had the same n^2 behaviour as the previous implementation. There are some micro-benchmarks <https://svn.apache.org/viewvc/tomcat/taglibs/standard/trunk/impl/src/test/java/org/apache/taglibs/standard/tag/common/xml/ForEachTagTest.java?view=markup&pathrev=1054175#l126> still in the test class if you want to see if that’s still true. Memory is a little fuzzy, but IIRC the JSTLVariableStack is used to make the JSP implicit variables (e.g. ${request.something}) resolvable in the transform. It’s the low-level equivalent of a custom XPathVariableResolver. If you’re not using the XML tags, you may be able to simply drop the Xalan dependency from your application to avoid the conflict.
