You are viewing a plain text version of this content. The canonical link for it is here.
Posted to taglibs-user@tomcat.apache.org by Matthew Broadhead <ma...@nbmlaw.co.uk> on 2017/11/26 14:32:35 UTC
xalan usage in taglibs
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?
Regards,
Matthew
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-user-unsubscribe@tomcat.apache.org
For additional commands, e-mail: taglibs-user-help@tomcat.apache.org
Re: xalan usage in taglibs
Posted by Romain Manni-Bucau <rm...@apache.org>.
Well issues i mentionned were to have xalan in the classpath. This
particular issue can be solved but this will not help tomee sadly.
Le 4 avr. 2018 19:48, "Matthew Broadhead" <ma...@nbmlaw.co.uk>
a écrit :
> could xalan be fixed or has everyone given up on it
> meaning https://issues.apache.org/jira/browse/XALANJ-2540 which has 31 up
> votes
>
> On 04/04/2018 17:30, Romain Manni-Bucau wrote:
>
>> That is why we have that hardcoded dep ATM but in tomee it creates as much
>> issues for apps not using that featire than it solves problem for others
>> :(
>>
>> Le 4 avr. 2018 17:24, "Matthew Broadhead" <matthew.broadhead@nbmlaw.co.uk
>> >
>> a écrit :
>>
>> i posted these links to the issue. did anyone see them? they seem
>>> important to the problem
>>> https://stackoverflow.com/questions/6340802/java-xpath-apach
>>> e-jaxp-implementation-performance
>>> https://blogs.sap.com/2009/12/04/performance-improvements-in
>>> -nw-java-applications-with-xml-processing/
>>>
>>> On 08/12/2017 17:08, Matthew Broadhead wrote:
>>>
>>> ok i created an issue https://bz.apache.org/bugzilla
>>>> /show_bug.cgi?id=61875
>>>>
>>>> On 08/12/2017 16:29, Jeremy Boynes wrote:
>>>>
>>>> On Dec 8, 2017, at 3:58 AM, Matthew Broadhead <
>>>>>
>>>>>> matthew.broadhead@nbmlaw.co.uk> wrote:
>>>>>>
>>>>>> here is a patch which removes the xalan dependency. but it breaks the
>>>>>> ForEachTagTest.
>>>>>> i notice that every constructor generates a JSTLXPathCompiler. could
>>>>>> it
>>>>>> not be a singleton?
>>>>>>
>>>>>> Thanks for the patch. I tried applying it but it looks like the
>>>>> support
>>>>> classes from o.a.t.standard.xpath e.g. JSTLXPathCompiler were not
>>>>> included
>>>>> - please could you update. It would also be easier to read the diff if
>>>>> you
>>>>> removed the old code rather than commenting it out.
>>>>>
>>>>> How about creating an new issue in Bugzilla and attaching patches to
>>>>> that.
>>>>>
>>>>> Cheers
>>>>> Jeremy
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: taglibs-user-unsubscribe@tomcat.apache.org
>>>>> For additional commands, e-mail: taglibs-user-help@tomcat.apache.org
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: taglibs-user-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: taglibs-user-help@tomcat.apache.org
>>>>
>>>>
>>>>
>
Re: xalan usage in taglibs
Posted by Matthew Broadhead <ma...@nbmlaw.co.uk>.
could xalan be fixed or has everyone given up on it
meaning https://issues.apache.org/jira/browse/XALANJ-2540 which has 31
up votes
On 04/04/2018 17:30, Romain Manni-Bucau wrote:
> That is why we have that hardcoded dep ATM but in tomee it creates as much
> issues for apps not using that featire than it solves problem for others :(
>
> Le 4 avr. 2018 17:24, "Matthew Broadhead" <ma...@nbmlaw.co.uk>
> a écrit :
>
>> i posted these links to the issue. did anyone see them? they seem
>> important to the problem
>> https://stackoverflow.com/questions/6340802/java-xpath-apach
>> e-jaxp-implementation-performance
>> https://blogs.sap.com/2009/12/04/performance-improvements-in
>> -nw-java-applications-with-xml-processing/
>>
>> On 08/12/2017 17:08, Matthew Broadhead wrote:
>>
>>> ok i created an issue https://bz.apache.org/bugzilla
>>> /show_bug.cgi?id=61875
>>>
>>> On 08/12/2017 16:29, Jeremy Boynes wrote:
>>>
>>>> On Dec 8, 2017, at 3:58 AM, Matthew Broadhead <
>>>>> matthew.broadhead@nbmlaw.co.uk> wrote:
>>>>>
>>>>> here is a patch which removes the xalan dependency. but it breaks the
>>>>> ForEachTagTest.
>>>>> i notice that every constructor generates a JSTLXPathCompiler. could it
>>>>> not be a singleton?
>>>>>
>>>> Thanks for the patch. I tried applying it but it looks like the support
>>>> classes from o.a.t.standard.xpath e.g. JSTLXPathCompiler were not included
>>>> - please could you update. It would also be easier to read the diff if you
>>>> removed the old code rather than commenting it out.
>>>>
>>>> How about creating an new issue in Bugzilla and attaching patches to
>>>> that.
>>>>
>>>> Cheers
>>>> Jeremy
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: taglibs-user-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: taglibs-user-help@tomcat.apache.org
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: taglibs-user-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: taglibs-user-help@tomcat.apache.org
>>>
>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-user-unsubscribe@tomcat.apache.org
For additional commands, e-mail: taglibs-user-help@tomcat.apache.org
Re: xalan usage in taglibs
Posted by Romain Manni-Bucau <rm...@apache.org>.
That is why we have that hardcoded dep ATM but in tomee it creates as much
issues for apps not using that featire than it solves problem for others :(
Le 4 avr. 2018 17:24, "Matthew Broadhead" <ma...@nbmlaw.co.uk>
a écrit :
> i posted these links to the issue. did anyone see them? they seem
> important to the problem
> https://stackoverflow.com/questions/6340802/java-xpath-apach
> e-jaxp-implementation-performance
> https://blogs.sap.com/2009/12/04/performance-improvements-in
> -nw-java-applications-with-xml-processing/
>
> On 08/12/2017 17:08, Matthew Broadhead wrote:
>
>> ok i created an issue https://bz.apache.org/bugzilla
>> /show_bug.cgi?id=61875
>>
>> On 08/12/2017 16:29, Jeremy Boynes wrote:
>>
>>> On Dec 8, 2017, at 3:58 AM, Matthew Broadhead <
>>>> matthew.broadhead@nbmlaw.co.uk> wrote:
>>>>
>>>> here is a patch which removes the xalan dependency. but it breaks the
>>>> ForEachTagTest.
>>>> i notice that every constructor generates a JSTLXPathCompiler. could it
>>>> not be a singleton?
>>>>
>>> Thanks for the patch. I tried applying it but it looks like the support
>>> classes from o.a.t.standard.xpath e.g. JSTLXPathCompiler were not included
>>> - please could you update. It would also be easier to read the diff if you
>>> removed the old code rather than commenting it out.
>>>
>>> How about creating an new issue in Bugzilla and attaching patches to
>>> that.
>>>
>>> Cheers
>>> Jeremy
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: taglibs-user-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: taglibs-user-help@tomcat.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: taglibs-user-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: taglibs-user-help@tomcat.apache.org
>>
>>
>
Re: xalan usage in taglibs
Posted by Matthew Broadhead <ma...@nbmlaw.co.uk>.
i posted these links to the issue. did anyone see them? they seem
important to the problem
https://stackoverflow.com/questions/6340802/java-xpath-apache-jaxp-implementation-performance
https://blogs.sap.com/2009/12/04/performance-improvements-in-nw-java-applications-with-xml-processing/
On 08/12/2017 17:08, Matthew Broadhead wrote:
> ok i created an issue
> https://bz.apache.org/bugzilla/show_bug.cgi?id=61875
>
> On 08/12/2017 16:29, Jeremy Boynes wrote:
>>> On Dec 8, 2017, at 3:58 AM, Matthew Broadhead
>>> <ma...@nbmlaw.co.uk> wrote:
>>>
>>> here is a patch which removes the xalan dependency. but it breaks
>>> the ForEachTagTest.
>>> i notice that every constructor generates a JSTLXPathCompiler. could
>>> it not be a singleton?
>> Thanks for the patch. I tried applying it but it looks like the
>> support classes from o.a.t.standard.xpath e.g. JSTLXPathCompiler were
>> not included - please could you update. It would also be easier to
>> read the diff if you removed the old code rather than commenting it out.
>>
>> How about creating an new issue in Bugzilla and attaching patches to
>> that.
>>
>> Cheers
>> Jeremy
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: taglibs-user-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: taglibs-user-help@tomcat.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: taglibs-user-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: taglibs-user-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-user-unsubscribe@tomcat.apache.org
For additional commands, e-mail: taglibs-user-help@tomcat.apache.org
Re: xalan usage in taglibs
Posted by Matthew Broadhead <ma...@nbmlaw.co.uk>.
ok i created an issue https://bz.apache.org/bugzilla/show_bug.cgi?id=61875
On 08/12/2017 16:29, Jeremy Boynes wrote:
>> On Dec 8, 2017, at 3:58 AM, Matthew Broadhead <ma...@nbmlaw.co.uk> wrote:
>>
>> here is a patch which removes the xalan dependency. but it breaks the ForEachTagTest.
>> i notice that every constructor generates a JSTLXPathCompiler. could it not be a singleton?
> Thanks for the patch. I tried applying it but it looks like the support classes from o.a.t.standard.xpath e.g. JSTLXPathCompiler were not included - please could you update. It would also be easier to read the diff if you removed the old code rather than commenting it out.
>
> How about creating an new issue in Bugzilla and attaching patches to that.
>
> Cheers
> Jeremy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: taglibs-user-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: taglibs-user-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-user-unsubscribe@tomcat.apache.org
For additional commands, e-mail: taglibs-user-help@tomcat.apache.org
Re: xalan usage in taglibs
Posted by Jeremy Boynes <jb...@apache.org>.
> On Dec 8, 2017, at 3:58 AM, Matthew Broadhead <ma...@nbmlaw.co.uk> wrote:
>
> here is a patch which removes the xalan dependency. but it breaks the ForEachTagTest.
> i notice that every constructor generates a JSTLXPathCompiler. could it not be a singleton?
Thanks for the patch. I tried applying it but it looks like the support classes from o.a.t.standard.xpath e.g. JSTLXPathCompiler were not included - please could you update. It would also be easier to read the diff if you removed the old code rather than commenting it out.
How about creating an new issue in Bugzilla and attaching patches to that.
Cheers
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-user-unsubscribe@tomcat.apache.org
For additional commands, e-mail: taglibs-user-help@tomcat.apache.org
Re: xalan usage in taglibs
Posted by Matthew Broadhead <ma...@nbmlaw.co.uk>.
here is a patch which removes the xalan dependency. but it breaks the
ForEachTagTest.
i notice that every constructor generates a JSTLXPathCompiler. could it
not be a singleton?
On 07/12/2017 15:08, Matthew Broadhead wrote:
> is there any other way to rewrite it so that it doesn't use
> DTMManager? that would also keep the speed? is it a matter of
> keeping the object in memory so that it doesn't have to keep building
> fragments?
> also could i build the old version that doesn't need DTMManager and
> drop it in my system to see what effect it has?
>
> On 06/12/2017 14:30, Romain Manni-Bucau wrote:
>> requires a classloader hack, no other trivial way, and that's why we
>> removed it from tomee
>>
>> 2017-12-06 14:27 GMT+01:00 Matthew Broadhead
>> <ma...@nbmlaw.co.uk>:
>>> is there any way that i can get the correct xalan at runtime?
>>>
>>> to recap this is the code that is blowing up for me:
>>> Reader xsl = new InputStreamReader(filepath.openStream());
>>> TransformerFactory transformerfactory =
>>> TransformerFactory.newInstance();
>>> StreamSource ssXsl = new StreamSource(xsl);
>>> ssXsl.setSystemId(filepath.toExternalForm());
>>> Templates templates = transformerfactory.newTemplates(ssXsl);
>>> Transformer transformer = templates.newTransformer();
>>>
>>> last line causes:
>>> 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)
>>>
>>>
>>> maybe you know some way to find the Impl with the correct DTMManager?
>>>
>>>
>>> On 30/11/2017 17:30, Romain Manni-Bucau wrote:
>>>> 2017-11-30 16:51 GMT+01:00 Jeremy Boynes <je...@boynes.com>:
>>>>>> On Nov 30, 2017, at 3:14 AM, Matthew Broadhead
>>>>>> <ma...@nbmlaw.co.uk> wrote:
>>>>>>
>>>>>> has anything been decided? if i try to redeploy a context in
>>>>>> production
>>>>>> all my xslt processors blow up. there should be a solution that
>>>>>> fits all?
>>>>> Taglibs (both Apache and Glassfish) has always had a dependency on
>>>>> Xalan.
>>>>> My understanding is that TomEE did not include it and so broke
>>>>> users that
>>>>> use the XML tags. If so, TomEE should fix that.
>>>> Sadly this is not a bug on tomee but the best solution we went through
>>>> after having delivered xalan for some releases. Xalan dependency
>>>> breaks 80% of apps so no way to include it - and this is the issue of
>>>> Matthew. Note it also affects simple apps in tomcat including taglib
>>>> and other libs.
>>>>
>>>>> You can probably add Xalan to your TomEE installation somehow to work
>>>>> around it but how to do that is really a question for the TomEE
>>>>> users list.
>>>>>
>>>>> A patch for Taglibs that removes the Xalan dependency and doesn't
>>>>> regress
>>>>> the #27717 performance fix would be great. A patch that removed the
>>>>> dependency but regressed performance would have to be evaluated at
>>>>> the time.
>>>>> The previous decision was not to do that.
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: taglibs-user-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: taglibs-user-help@tomcat.apache.org
>>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: taglibs-user-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: taglibs-user-help@tomcat.apache.org
>
Re: xalan usage in taglibs
Posted by Matthew Broadhead <ma...@nbmlaw.co.uk>.
is there any other way to rewrite it so that it doesn't use DTMManager?
that would also keep the speed? is it a matter of keeping the object in
memory so that it doesn't have to keep building fragments?
also could i build the old version that doesn't need DTMManager and drop
it in my system to see what effect it has?
On 06/12/2017 14:30, Romain Manni-Bucau wrote:
> requires a classloader hack, no other trivial way, and that's why we
> removed it from tomee
>
> 2017-12-06 14:27 GMT+01:00 Matthew Broadhead <ma...@nbmlaw.co.uk>:
>> is there any way that i can get the correct xalan at runtime?
>>
>> to recap this is the code that is blowing up for me:
>> Reader xsl = new InputStreamReader(filepath.openStream());
>> TransformerFactory transformerfactory = TransformerFactory.newInstance();
>> StreamSource ssXsl = new StreamSource(xsl);
>> ssXsl.setSystemId(filepath.toExternalForm());
>> Templates templates = transformerfactory.newTemplates(ssXsl);
>> Transformer transformer = templates.newTransformer();
>>
>> last line causes:
>> 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)
>>
>> maybe you know some way to find the Impl with the correct DTMManager?
>>
>>
>> On 30/11/2017 17:30, Romain Manni-Bucau wrote:
>>> 2017-11-30 16:51 GMT+01:00 Jeremy Boynes <je...@boynes.com>:
>>>>> On Nov 30, 2017, at 3:14 AM, Matthew Broadhead
>>>>> <ma...@nbmlaw.co.uk> wrote:
>>>>>
>>>>> has anything been decided? if i try to redeploy a context in production
>>>>> all my xslt processors blow up. there should be a solution that fits all?
>>>> Taglibs (both Apache and Glassfish) has always had a dependency on Xalan.
>>>> My understanding is that TomEE did not include it and so broke users that
>>>> use the XML tags. If so, TomEE should fix that.
>>> Sadly this is not a bug on tomee but the best solution we went through
>>> after having delivered xalan for some releases. Xalan dependency
>>> breaks 80% of apps so no way to include it - and this is the issue of
>>> Matthew. Note it also affects simple apps in tomcat including taglib
>>> and other libs.
>>>
>>>> You can probably add Xalan to your TomEE installation somehow to work
>>>> around it but how to do that is really a question for the TomEE users list.
>>>>
>>>> A patch for Taglibs that removes the Xalan dependency and doesn't regress
>>>> the #27717 performance fix would be great. A patch that removed the
>>>> dependency but regressed performance would have to be evaluated at the time.
>>>> The previous decision was not to do that.
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: taglibs-user-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: taglibs-user-help@tomcat.apache.org
>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-user-unsubscribe@tomcat.apache.org
For additional commands, e-mail: taglibs-user-help@tomcat.apache.org
Re: xalan usage in taglibs
Posted by Romain Manni-Bucau <rm...@apache.org>.
requires a classloader hack, no other trivial way, and that's why we
removed it from tomee
2017-12-06 14:27 GMT+01:00 Matthew Broadhead <ma...@nbmlaw.co.uk>:
> is there any way that i can get the correct xalan at runtime?
>
> to recap this is the code that is blowing up for me:
> Reader xsl = new InputStreamReader(filepath.openStream());
> TransformerFactory transformerfactory = TransformerFactory.newInstance();
> StreamSource ssXsl = new StreamSource(xsl);
> ssXsl.setSystemId(filepath.toExternalForm());
> Templates templates = transformerfactory.newTemplates(ssXsl);
> Transformer transformer = templates.newTransformer();
>
> last line causes:
> 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)
>
> maybe you know some way to find the Impl with the correct DTMManager?
>
>
> On 30/11/2017 17:30, Romain Manni-Bucau wrote:
>>
>> 2017-11-30 16:51 GMT+01:00 Jeremy Boynes <je...@boynes.com>:
>>>>
>>>> On Nov 30, 2017, at 3:14 AM, Matthew Broadhead
>>>> <ma...@nbmlaw.co.uk> wrote:
>>>>
>>>> has anything been decided? if i try to redeploy a context in production
>>>> all my xslt processors blow up. there should be a solution that fits all?
>>>
>>> Taglibs (both Apache and Glassfish) has always had a dependency on Xalan.
>>> My understanding is that TomEE did not include it and so broke users that
>>> use the XML tags. If so, TomEE should fix that.
>>
>> Sadly this is not a bug on tomee but the best solution we went through
>> after having delivered xalan for some releases. Xalan dependency
>> breaks 80% of apps so no way to include it - and this is the issue of
>> Matthew. Note it also affects simple apps in tomcat including taglib
>> and other libs.
>>
>>> You can probably add Xalan to your TomEE installation somehow to work
>>> around it but how to do that is really a question for the TomEE users list.
>>>
>>> A patch for Taglibs that removes the Xalan dependency and doesn't regress
>>> the #27717 performance fix would be great. A patch that removed the
>>> dependency but regressed performance would have to be evaluated at the time.
>>> The previous decision was not to do that.
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: taglibs-user-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: taglibs-user-help@tomcat.apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-user-unsubscribe@tomcat.apache.org
For additional commands, e-mail: taglibs-user-help@tomcat.apache.org
Re: xalan usage in taglibs
Posted by Matthew Broadhead <ma...@nbmlaw.co.uk>.
is there any way that i can get the correct xalan at runtime?
to recap this is the code that is blowing up for me:
Reader xsl = new InputStreamReader(filepath.openStream());
TransformerFactory transformerfactory = TransformerFactory.newInstance();
StreamSource ssXsl = new StreamSource(xsl);
ssXsl.setSystemId(filepath.toExternalForm());
Templates templates = transformerfactory.newTemplates(ssXsl);
Transformer transformer = templates.newTransformer();
last line causes:
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)
maybe you know some way to find the Impl with the correct DTMManager?
On 30/11/2017 17:30, Romain Manni-Bucau wrote:
> 2017-11-30 16:51 GMT+01:00 Jeremy Boynes <je...@boynes.com>:
>>> On Nov 30, 2017, at 3:14 AM, Matthew Broadhead <ma...@nbmlaw.co.uk> wrote:
>>>
>>> has anything been decided? if i try to redeploy a context in production all my xslt processors blow up. there should be a solution that fits all?
>> Taglibs (both Apache and Glassfish) has always had a dependency on Xalan. My understanding is that TomEE did not include it and so broke users that use the XML tags. If so, TomEE should fix that.
> Sadly this is not a bug on tomee but the best solution we went through
> after having delivered xalan for some releases. Xalan dependency
> breaks 80% of apps so no way to include it - and this is the issue of
> Matthew. Note it also affects simple apps in tomcat including taglib
> and other libs.
>
>> You can probably add Xalan to your TomEE installation somehow to work around it but how to do that is really a question for the TomEE users list.
>>
>> A patch for Taglibs that removes the Xalan dependency and doesn't regress the #27717 performance fix would be great. A patch that removed the dependency but regressed performance would have to be evaluated at the time. The previous decision was not to do that.
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: taglibs-user-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: taglibs-user-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-user-unsubscribe@tomcat.apache.org
For additional commands, e-mail: taglibs-user-help@tomcat.apache.org
Re: xalan usage in taglibs
Posted by Romain Manni-Bucau <rm...@apache.org>.
2017-11-30 16:51 GMT+01:00 Jeremy Boynes <je...@boynes.com>:
>> On Nov 30, 2017, at 3:14 AM, Matthew Broadhead <ma...@nbmlaw.co.uk> wrote:
>>
>> has anything been decided? if i try to redeploy a context in production all my xslt processors blow up. there should be a solution that fits all?
>
> Taglibs (both Apache and Glassfish) has always had a dependency on Xalan. My understanding is that TomEE did not include it and so broke users that use the XML tags. If so, TomEE should fix that.
Sadly this is not a bug on tomee but the best solution we went through
after having delivered xalan for some releases. Xalan dependency
breaks 80% of apps so no way to include it - and this is the issue of
Matthew. Note it also affects simple apps in tomcat including taglib
and other libs.
>
> You can probably add Xalan to your TomEE installation somehow to work around it but how to do that is really a question for the TomEE users list.
>
> A patch for Taglibs that removes the Xalan dependency and doesn't regress the #27717 performance fix would be great. A patch that removed the dependency but regressed performance would have to be evaluated at the time. The previous decision was not to do that.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-user-unsubscribe@tomcat.apache.org
For additional commands, e-mail: taglibs-user-help@tomcat.apache.org
Re: xalan usage in taglibs
Posted by Jeremy Boynes <je...@boynes.com>.
> On Nov 30, 2017, at 3:14 AM, Matthew Broadhead <ma...@nbmlaw.co.uk> wrote:
>
> has anything been decided? if i try to redeploy a context in production all my xslt processors blow up. there should be a solution that fits all?
Taglibs (both Apache and Glassfish) has always had a dependency on Xalan. My understanding is that TomEE did not include it and so broke users that use the XML tags. If so, TomEE should fix that.
You can probably add Xalan to your TomEE installation somehow to work around it but how to do that is really a question for the TomEE users list.
A patch for Taglibs that removes the Xalan dependency and doesn't regress the #27717 performance fix would be great. A patch that removed the dependency but regressed performance would have to be evaluated at the time. The previous decision was not to do that.
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-user-unsubscribe@tomcat.apache.org
For additional commands, e-mail: taglibs-user-help@tomcat.apache.org
Re: xalan usage in taglibs
Posted by Matthew Broadhead <ma...@nbmlaw.co.uk>.
has anything been decided? if i try to redeploy a context in production
all my xslt processors blow up. there should be a solution that fits all?
On 27/11/2017 20:03, Romain Manni-Bucau wrote:
> 2017-11-27 20:01 GMT+01:00 Jeremy Boynes <jb...@apache.org>:
>>> On Nov 27, 2017, at 7:38 AM, Romain Manni-Bucau <rm...@apache.org> wrote:
>>>
>>> 2017-11-27 16:31 GMT+01:00 Jeremy Boynes <jb...@apache.org>:
>>>> On Nov 27, 2017, at 12:07 AM, Matthew Broadhead
>>>> <ma...@nbmlaw.co.uk> wrote:
>>>>
>>>> In TomEE 7.0.3 everything is fine at startup. But if a webapp is reloaded I
>>>> get
>>>> java.lang.ClassCastException: org.apache.xml.dtm.ref.DTMManagerDefault
>>>> cannot be cast to org.apache.xml.dtm.DTMManager
>>>> and the whole container needs to be restarted which is not ideal during
>>>> production
>>>>
>>>> Now in TomEE 7.0.4 I cannot even start without this error so I cannot
>>>> upgrade.
>>>>
>>>> It seems like a classloader issue but taglibs is the only hardcoded
>>>> dependency on xalan
>>>>
>>>>
>>>> Are you including the taglibs jars in your war when deploying to TomEE? You
>>>> shouldn’t need to do that as TomEE should be providing its own
>>>> implementation of JSTL which would mean there is a chance of conflict if you
>>>> also include them.
>>> Issue is xalan conflicts very easily in terms of transitive deps.
>>>
>>>> From a thread on tomee-users, it sounds like TomEE could be trying include
>>>> taglibs and avoid including the Xalan dependency but I wouldn’t expect that
>>>> to work as it actually is needed by the XML tags. The dependency is
>>>> “provided” scope to avoid automatic transitive inclusion for applications
>>>> that don’t use the XML tags (which is most). For container integration it
>>>> should be included as an application might use those tags.
>>> TomEE bundles taglib and therefore must bundle xalan otherwise several
>>> features don't work and TCK don't pass.
>> That was one of the tradeoffs in fixing #27717. I tried to use pure JAXP and the implementation from the JRE but it had the same issue as the way 1.1 worked, perhaps not surprisingly given they are both Xalan based. To avoid rebuilding the DTM for each XPath execution, the tags work the same way an XSLT does, creating the DTM once and then evaluating the expression using the DTM. Unfortunately that meant using the low-level Xalan DTM APIs hence the direct dependency. The trade off doing this was:
>>
>> a) do nothing, leaving #27717 unresolved
>> b) use Xalan as a dependency that was only actually needed if the XML tags were used in an application
>> c) shade Xalan and increase the library size when most users wouldn’t need it
>> d) refactor the XML tags into a separate taglib from the others so users would need to include multiple libraries
>>
>> Option b) seemed like a reasonable compromise because:
>> - users on a Servlet-profile container would not have JSTL provided by the container and so would control which dependencies they needed
>> - users on a Web- or Full-profile container would have the entire JSTL implementation provided by the container and the container vendor would have ensured the dependencies were resolved appropriately
> This is where it doesn't work. In tomcat you impose it to be inherited
> in the app and therefore conflict 80% of the time :(.
>
> I'd be for option e): support xalan as an optional dependency if
> present or fallback on a) if not.
>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: taglibs-user-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: taglibs-user-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-user-unsubscribe@tomcat.apache.org
For additional commands, e-mail: taglibs-user-help@tomcat.apache.org
Re: xalan usage in taglibs
Posted by Matthew Broadhead <ma...@nbmlaw.co.uk>.
i bumped into this again yesterday. i still can't upgrade from 7.0.3 to
7.0.4. for some reason 7.0.4 loads up with the error whereas 7.0.3
fails after a webapp is reloaded. hopefully this doesn't mean i can no
longer move forward with any upgrades.
all i am doing is simple xsl transformations. is there some way i can
be bypassing this error?
example code is
Reader xsl = new InputStreamReader(filepath.openStream());
TransformerFactory transformerfactory =
TransformerFactory.newInstance();
// transformerfactory.setURIResolver(new
MyUriResolver(prefix));
StreamSource ssXsl = new StreamSource(xsl);
ssXsl.setSystemId(filepath.toExternalForm());
Templates templates =
transformerfactory.newTemplates(ssXsl);
Transformer transformer = templates.newTransformer();
if (parameters != null) {
Iterator<String> iterator =
parameters.keySet().iterator();
while (iterator.hasNext()) {
String key = iterator.next();
String value = parameters.get(key);
if (value != null && !value.equals("")) {
transformer.setParameter(key, value);
}
}
}
StringReader reader = new StringReader(xml);
StringWriter writer = new StringWriter();
transformer.transform(new StreamSource(reader), new
StreamResult(writer));
out = new StringBuffer(writer.toString());
writer.close();
reader.close();
On 27/11/2017 20:03, Romain Manni-Bucau wrote:
> 2017-11-27 20:01 GMT+01:00 Jeremy Boynes <jb...@apache.org>:
>>> On Nov 27, 2017, at 7:38 AM, Romain Manni-Bucau <rm...@apache.org> wrote:
>>>
>>> 2017-11-27 16:31 GMT+01:00 Jeremy Boynes <jb...@apache.org>:
>>>> On Nov 27, 2017, at 12:07 AM, Matthew Broadhead
>>>> <ma...@nbmlaw.co.uk> wrote:
>>>>
>>>> In TomEE 7.0.3 everything is fine at startup. But if a webapp is reloaded I
>>>> get
>>>> java.lang.ClassCastException: org.apache.xml.dtm.ref.DTMManagerDefault
>>>> cannot be cast to org.apache.xml.dtm.DTMManager
>>>> and the whole container needs to be restarted which is not ideal during
>>>> production
>>>>
>>>> Now in TomEE 7.0.4 I cannot even start without this error so I cannot
>>>> upgrade.
>>>>
>>>> It seems like a classloader issue but taglibs is the only hardcoded
>>>> dependency on xalan
>>>>
>>>>
>>>> Are you including the taglibs jars in your war when deploying to TomEE? You
>>>> shouldn’t need to do that as TomEE should be providing its own
>>>> implementation of JSTL which would mean there is a chance of conflict if you
>>>> also include them.
>>> Issue is xalan conflicts very easily in terms of transitive deps.
>>>
>>>> From a thread on tomee-users, it sounds like TomEE could be trying include
>>>> taglibs and avoid including the Xalan dependency but I wouldn’t expect that
>>>> to work as it actually is needed by the XML tags. The dependency is
>>>> “provided” scope to avoid automatic transitive inclusion for applications
>>>> that don’t use the XML tags (which is most). For container integration it
>>>> should be included as an application might use those tags.
>>> TomEE bundles taglib and therefore must bundle xalan otherwise several
>>> features don't work and TCK don't pass.
>> That was one of the tradeoffs in fixing #27717. I tried to use pure JAXP and the implementation from the JRE but it had the same issue as the way 1.1 worked, perhaps not surprisingly given they are both Xalan based. To avoid rebuilding the DTM for each XPath execution, the tags work the same way an XSLT does, creating the DTM once and then evaluating the expression using the DTM. Unfortunately that meant using the low-level Xalan DTM APIs hence the direct dependency. The trade off doing this was:
>>
>> a) do nothing, leaving #27717 unresolved
>> b) use Xalan as a dependency that was only actually needed if the XML tags were used in an application
>> c) shade Xalan and increase the library size when most users wouldn’t need it
>> d) refactor the XML tags into a separate taglib from the others so users would need to include multiple libraries
>>
>> Option b) seemed like a reasonable compromise because:
>> - users on a Servlet-profile container would not have JSTL provided by the container and so would control which dependencies they needed
>> - users on a Web- or Full-profile container would have the entire JSTL implementation provided by the container and the container vendor would have ensured the dependencies were resolved appropriately
> This is where it doesn't work. In tomcat you impose it to be inherited
> in the app and therefore conflict 80% of the time :(.
>
> I'd be for option e): support xalan as an optional dependency if
> present or fallback on a) if not.
>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: taglibs-user-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: taglibs-user-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-user-unsubscribe@tomcat.apache.org
For additional commands, e-mail: taglibs-user-help@tomcat.apache.org
Re: xalan usage in taglibs
Posted by Romain Manni-Bucau <rm...@apache.org>.
2017-11-27 20:01 GMT+01:00 Jeremy Boynes <jb...@apache.org>:
>> On Nov 27, 2017, at 7:38 AM, Romain Manni-Bucau <rm...@apache.org> wrote:
>>
>> 2017-11-27 16:31 GMT+01:00 Jeremy Boynes <jb...@apache.org>:
>>> On Nov 27, 2017, at 12:07 AM, Matthew Broadhead
>>> <ma...@nbmlaw.co.uk> wrote:
>>>
>>> In TomEE 7.0.3 everything is fine at startup. But if a webapp is reloaded I
>>> get
>>> java.lang.ClassCastException: org.apache.xml.dtm.ref.DTMManagerDefault
>>> cannot be cast to org.apache.xml.dtm.DTMManager
>>> and the whole container needs to be restarted which is not ideal during
>>> production
>>>
>>> Now in TomEE 7.0.4 I cannot even start without this error so I cannot
>>> upgrade.
>>>
>>> It seems like a classloader issue but taglibs is the only hardcoded
>>> dependency on xalan
>>>
>>>
>>> Are you including the taglibs jars in your war when deploying to TomEE? You
>>> shouldn’t need to do that as TomEE should be providing its own
>>> implementation of JSTL which would mean there is a chance of conflict if you
>>> also include them.
>>
>> Issue is xalan conflicts very easily in terms of transitive deps.
>>
>>>
>>> From a thread on tomee-users, it sounds like TomEE could be trying include
>>> taglibs and avoid including the Xalan dependency but I wouldn’t expect that
>>> to work as it actually is needed by the XML tags. The dependency is
>>> “provided” scope to avoid automatic transitive inclusion for applications
>>> that don’t use the XML tags (which is most). For container integration it
>>> should be included as an application might use those tags.
>>
>> TomEE bundles taglib and therefore must bundle xalan otherwise several
>> features don't work and TCK don't pass.
>
> That was one of the tradeoffs in fixing #27717. I tried to use pure JAXP and the implementation from the JRE but it had the same issue as the way 1.1 worked, perhaps not surprisingly given they are both Xalan based. To avoid rebuilding the DTM for each XPath execution, the tags work the same way an XSLT does, creating the DTM once and then evaluating the expression using the DTM. Unfortunately that meant using the low-level Xalan DTM APIs hence the direct dependency. The trade off doing this was:
>
> a) do nothing, leaving #27717 unresolved
> b) use Xalan as a dependency that was only actually needed if the XML tags were used in an application
> c) shade Xalan and increase the library size when most users wouldn’t need it
> d) refactor the XML tags into a separate taglib from the others so users would need to include multiple libraries
>
> Option b) seemed like a reasonable compromise because:
> - users on a Servlet-profile container would not have JSTL provided by the container and so would control which dependencies they needed
> - users on a Web- or Full-profile container would have the entire JSTL implementation provided by the container and the container vendor would have ensured the dependencies were resolved appropriately
This is where it doesn't work. In tomcat you impose it to be inherited
in the app and therefore conflict 80% of the time :(.
I'd be for option e): support xalan as an optional dependency if
present or fallback on a) if not.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-user-unsubscribe@tomcat.apache.org
For additional commands, e-mail: taglibs-user-help@tomcat.apache.org
Re: xalan usage in taglibs
Posted by Jeremy Boynes <jb...@apache.org>.
> On Nov 27, 2017, at 7:38 AM, Romain Manni-Bucau <rm...@apache.org> wrote:
>
> 2017-11-27 16:31 GMT+01:00 Jeremy Boynes <jb...@apache.org>:
>> On Nov 27, 2017, at 12:07 AM, Matthew Broadhead
>> <ma...@nbmlaw.co.uk> wrote:
>>
>> In TomEE 7.0.3 everything is fine at startup. But if a webapp is reloaded I
>> get
>> java.lang.ClassCastException: org.apache.xml.dtm.ref.DTMManagerDefault
>> cannot be cast to org.apache.xml.dtm.DTMManager
>> and the whole container needs to be restarted which is not ideal during
>> production
>>
>> Now in TomEE 7.0.4 I cannot even start without this error so I cannot
>> upgrade.
>>
>> It seems like a classloader issue but taglibs is the only hardcoded
>> dependency on xalan
>>
>>
>> Are you including the taglibs jars in your war when deploying to TomEE? You
>> shouldn’t need to do that as TomEE should be providing its own
>> implementation of JSTL which would mean there is a chance of conflict if you
>> also include them.
>
> Issue is xalan conflicts very easily in terms of transitive deps.
>
>>
>> From a thread on tomee-users, it sounds like TomEE could be trying include
>> taglibs and avoid including the Xalan dependency but I wouldn’t expect that
>> to work as it actually is needed by the XML tags. The dependency is
>> “provided” scope to avoid automatic transitive inclusion for applications
>> that don’t use the XML tags (which is most). For container integration it
>> should be included as an application might use those tags.
>
> TomEE bundles taglib and therefore must bundle xalan otherwise several
> features don't work and TCK don't pass.
That was one of the tradeoffs in fixing #27717. I tried to use pure JAXP and the implementation from the JRE but it had the same issue as the way 1.1 worked, perhaps not surprisingly given they are both Xalan based. To avoid rebuilding the DTM for each XPath execution, the tags work the same way an XSLT does, creating the DTM once and then evaluating the expression using the DTM. Unfortunately that meant using the low-level Xalan DTM APIs hence the direct dependency. The trade off doing this was:
a) do nothing, leaving #27717 unresolved
b) use Xalan as a dependency that was only actually needed if the XML tags were used in an application
c) shade Xalan and increase the library size when most users wouldn’t need it
d) refactor the XML tags into a separate taglib from the others so users would need to include multiple libraries
Option b) seemed like a reasonable compromise because:
- users on a Servlet-profile container would not have JSTL provided by the container and so would control which dependencies they needed
- users on a Web- or Full-profile container would have the entire JSTL implementation provided by the container and the container vendor would have ensured the dependencies were resolved appropriately
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-user-unsubscribe@tomcat.apache.org
For additional commands, e-mail: taglibs-user-help@tomcat.apache.org
Re: xalan usage in taglibs
Posted by Romain Manni-Bucau <rm...@apache.org>.
2017-11-27 16:31 GMT+01:00 Jeremy Boynes <jb...@apache.org>:
> On Nov 27, 2017, at 12:07 AM, Matthew Broadhead
> <ma...@nbmlaw.co.uk> wrote:
>
> In TomEE 7.0.3 everything is fine at startup. But if a webapp is reloaded I
> get
> java.lang.ClassCastException: org.apache.xml.dtm.ref.DTMManagerDefault
> cannot be cast to org.apache.xml.dtm.DTMManager
> and the whole container needs to be restarted which is not ideal during
> production
>
> Now in TomEE 7.0.4 I cannot even start without this error so I cannot
> upgrade.
>
> It seems like a classloader issue but taglibs is the only hardcoded
> dependency on xalan
>
>
> Are you including the taglibs jars in your war when deploying to TomEE? You
> shouldn’t need to do that as TomEE should be providing its own
> implementation of JSTL which would mean there is a chance of conflict if you
> also include them.
Issue is xalan conflicts very easily in terms of transitive deps.
>
> From a thread on tomee-users, it sounds like TomEE could be trying include
> taglibs and avoid including the Xalan dependency but I wouldn’t expect that
> to work as it actually is needed by the XML tags. The dependency is
> “provided” scope to avoid automatic transitive inclusion for applications
> that don’t use the XML tags (which is most). For container integration it
> should be included as an application might use those tags.
TomEE bundles taglib and therefore must bundle xalan otherwise several
features don't work and TCK don't pass.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-user-unsubscribe@tomcat.apache.org
For additional commands, e-mail: taglibs-user-help@tomcat.apache.org
Re: xalan usage in taglibs
Posted by Jeremy Boynes <jb...@apache.org>.
> On Nov 27, 2017, at 12:07 AM, Matthew Broadhead <ma...@nbmlaw.co.uk> wrote:
>
> In TomEE 7.0.3 everything is fine at startup. But if a webapp is reloaded I get
> java.lang.ClassCastException: org.apache.xml.dtm.ref.DTMManagerDefault cannot be cast to org.apache.xml.dtm.DTMManager
> and the whole container needs to be restarted which is not ideal during production
>
> Now in TomEE 7.0.4 I cannot even start without this error so I cannot upgrade.
>
> It seems like a classloader issue but taglibs is the only hardcoded dependency on xalan
Are you including the taglibs jars in your war when deploying to TomEE? You shouldn’t need to do that as TomEE should be providing its own implementation of JSTL which would mean there is a chance of conflict if you also include them.
From a thread <http://mail-archives.apache.org/mod_mbox/tomee-users/201707.mbox/%3CCAJMhK2JCM3d1qjq4pkRsiJ6burVH-yQ=O5Dc2-NO0jMcQcHuiA@mail.gmail.com%3E> on tomee-users, it sounds like TomEE could be trying include taglibs and avoid including the Xalan dependency but I wouldn’t expect that to work as it actually is needed by the XML tags. The dependency is “provided” scope to avoid automatic transitive inclusion for applications that don’t use the XML tags (which is most). For container integration it should be included as an application might use those tags.
Re: xalan usage in taglibs
Posted by Matthew Broadhead <ma...@nbmlaw.co.uk>.
In TomEE 7.0.3 everything is fine at startup. But if a webapp is
reloaded I get
java.lang.ClassCastException: org.apache.xml.dtm.ref.DTMManagerDefault
cannot be cast to org.apache.xml.dtm.DTMManager
and the whole container needs to be restarted which is not ideal during
production
Now in TomEE 7.0.4 I cannot even start without this error so I cannot
upgrade.
It seems like a classloader issue but taglibs is the only hardcoded
dependency on xalan
On 27/11/2017 01:12, Jeremy Boynes wrote:
>> On Nov 26, 2017, at 2:17 PM, Matthew Broadhead <ma...@nbmlaw.co.uk> 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 <https://bz.apache.org/bugzilla/attachment.cgi?id=26445&action=diff> 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?
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-user-unsubscribe@tomcat.apache.org
For additional commands, e-mail: taglibs-user-help@tomcat.apache.org
Re: xalan usage in taglibs
Posted by Jeremy Boynes <je...@boynes.com>.
> On Nov 26, 2017, at 2:17 PM, Matthew Broadhead <ma...@nbmlaw.co.uk> 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 <https://bz.apache.org/bugzilla/attachment.cgi?id=26445&action=diff> 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
Posted by Matthew Broadhead <ma...@nbmlaw.co.uk>.
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?
On 26/11/2017 17:33, Jeremy Boynes wrote:
> On Nov 26, 2017, at 6:32 AM, Matthew Broadhead <ma...@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.
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-user-unsubscribe@tomcat.apache.org
For additional commands, e-mail: taglibs-user-help@tomcat.apache.org
Re: xalan usage in taglibs
Posted by Jeremy Boynes <jb...@apache.org>.
On Nov 26, 2017, at 6:32 AM, Matthew Broadhead <ma...@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.