Re: xalan usage in taglibs

[Jeremy Boynes]

> On Nov 26, 2017, at 2:17 PM, Matthew Broadhead 
>  wrote:
> 
> So to run the tests I could reverse the changes of the commit and then update 
> to javax.xml.* and run tests?
> 
> I am still struggling a bit to understand exactly what is happening wrt 
> VariableStack and how I can change over to XPathVariableResolver.  And also 
> don't see a way to replace XBoolean, XNumber, XString etc...
> 
> I will keep trying things.   Can I come back to you with specific queries?

I did experiment with a pure JAXP based solution - there’s a patch 
 attached 
to #27717 that might be a place to start from. You may need to roll back a bit 
to get it to apply. 

From what I remember, the performance problem stemmed from the evaluation of 
XPath inside the loop, with both Xalan and JAXP (which used a shaded version of 
Xalan) reinitializing the DTM each time leading to N * N scaling. The fix was 
to use Xalan’s API directly to convert the document’s DOM to a DTM once and 
then apply the XPath against the DTM each time leading to 1 * N scaling. 

The downside is that there was a direct dependency on Xalan 2.7.1. I think we 
tried using 2.7.2 but there was some other problem with that I can’t find at 
the moment. Given the stability of Xalan/Xerces, what’s causing the conflict 
with FOP?

Re: xalan usage in taglibs

[Jeremy Boynes]

On Nov 26, 2017, at 6:32 AM, Matthew Broadhead  
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.(XPathContext.java:102)
> at org.apache.xpath.XPathContext.(XPathContext.java:349)
> at org.apache.xpath.XPathContext.(XPathContext.java:337)
> at 
> org.apache.xalan.transformer.TransformerImpl.(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  
in 1.2.x to fix a performance problem (bug #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 

 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.