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 2018/04/04 15:24:00 UTC
Re: xalan usage in taglibs
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 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
>>
>>
>