Re: xalan usage in taglibs

2018-04-04 Thread Romain Manni-Bucau
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" 
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" > >
>> 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.broadh...@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-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: taglibs-user-h...@tomcat.apache.org
>
>
> -
 To unsubscribe, e-mail: taglibs-user-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: taglibs-user-h...@tomcat.apache.org



>


Re: xalan usage in taglibs

2018-04-04 Thread Matthew Broadhead
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 
 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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: taglibs-user-h...@tomcat.apache.org




-
To unsubscribe, e-mail: taglibs-user-unsubscr...@tomcat.apache.org
For additional commands, e-mail: taglibs-user-h...@tomcat.apache.org




-
To unsubscribe, e-mail: taglibs-user-unsubscr...@tomcat.apache.org
For additional commands, e-mail: taglibs-user-h...@tomcat.apache.org



Re: xalan usage in taglibs

2018-02-08 Thread Matthew Broadhead
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 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 :

On Nov 27, 2017, at 7:38 AM, Romain Manni-Bucau  wrote:

2017-11-27 16:31 GMT+01:00 Jeremy Boynes :

On Nov 27, 2017, at 12:07 AM, Matthew Broadhead
 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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: 

Re: xalan usage in taglibs

2017-12-08 Thread Matthew Broadhead
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 
:

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.(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) 



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 :

On Nov 30, 2017, at 3:14 AM, Matthew Broadhead
 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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: taglibs-user-h...@tomcat.apache.org




-
To unsubscribe, e-mail: taglibs-user-unsubscr...@tomcat.apache.org
For additional commands, e-mail: taglibs-user-h...@tomcat.apache.org



Index: apache-taglibs-trunk/impl/pom.xml
===
--- apache-taglibs-trunk/impl/pom.xml   (revision 1815893)
+++ apache-taglibs-trunk/impl/pom.xml   (working copy)
@@ -91,13 +91,13 @@
 1.0
 provided
 
-
+
 
 
 junit
Index: 
apache-taglibs-trunk/impl/src/main/java/org/apache/taglibs/standard/tag/common/xml/ExprSupport.java
===
--- 
apache-taglibs-trunk/impl/src/main/java/org/apache/taglibs/standard/tag/common/xml/ExprSupport.java
 (revision 1815893)
+++ 
apache-taglibs-trunk/impl/src/main/java/org/apache/taglibs/standard/tag/common/xml/ExprSupport.java
 (working copy)
@@ -22,52 +22,55 @@
 import javax.servlet.jsp.JspException;
 import javax.servlet.jsp.JspTagException;
 import javax.servlet.jsp.tagext.TagSupport;
-import javax.xml.transform.TransformerException;
+//import javax.xml.transform.TransformerException;
 
 import org.apache.taglibs.standard.util.EscapeXML;
-import org.apache.xpath.XPath;
-import org.apache.xpath.XPathContext;
+import org.apache.taglibs.standard.xpath.JSTLXPathCompiler;
+import org.apache.taglibs.standard.xpath.JSTLXPathExpression;
+import org.apache.taglibs.standard.xpath.JSTLXPathFactory;
+//import org.apache.xpath.XPath;
+//import org.apache.xpath.XPathContext;
 
 /**
- * Tag handler for out in JSTL's XML 

Re: xalan usage in taglibs

2017-12-07 Thread Matthew Broadhead
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 :

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.(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)

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 :

On Nov 30, 2017, at 3:14 AM, Matthew Broadhead
 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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: taglibs-user-h...@tomcat.apache.org




-
To unsubscribe, e-mail: taglibs-user-unsubscr...@tomcat.apache.org
For additional commands, e-mail: taglibs-user-h...@tomcat.apache.org



Re: xalan usage in taglibs

2017-12-06 Thread Romain Manni-Bucau
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 :
> 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.(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)
>
> 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 :

 On Nov 30, 2017, at 3:14 AM, Matthew Broadhead
  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-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: taglibs-user-h...@tomcat.apache.org
>>
>

-
To unsubscribe, e-mail: taglibs-user-unsubscr...@tomcat.apache.org
For additional commands, e-mail: taglibs-user-h...@tomcat.apache.org



Re: xalan usage in taglibs

2017-12-06 Thread Matthew Broadhead

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.(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)


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 :

On Nov 30, 2017, at 3:14 AM, Matthew Broadhead  
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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: taglibs-user-h...@tomcat.apache.org




-
To unsubscribe, e-mail: taglibs-user-unsubscr...@tomcat.apache.org
For additional commands, e-mail: taglibs-user-h...@tomcat.apache.org



Re: xalan usage in taglibs

2017-11-30 Thread Romain Manni-Bucau
2017-11-30 16:51 GMT+01:00 Jeremy Boynes :
>> On Nov 30, 2017, at 3:14 AM, Matthew Broadhead 
>>  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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: taglibs-user-h...@tomcat.apache.org



Re: xalan usage in taglibs

2017-11-30 Thread Jeremy Boynes
> On Nov 30, 2017, at 3:14 AM, Matthew Broadhead 
>  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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: taglibs-user-h...@tomcat.apache.org



Re: xalan usage in taglibs

2017-11-30 Thread Matthew Broadhead
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 :

On Nov 27, 2017, at 7:38 AM, Romain Manni-Bucau  wrote:

2017-11-27 16:31 GMT+01:00 Jeremy Boynes :

On Nov 27, 2017, at 12:07 AM, Matthew Broadhead
 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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: taglibs-user-h...@tomcat.apache.org




-
To unsubscribe, e-mail: taglibs-user-unsubscr...@tomcat.apache.org
For additional commands, e-mail: taglibs-user-h...@tomcat.apache.org



Re: xalan usage in taglibs

2017-11-27 Thread Romain Manni-Bucau
2017-11-27 20:01 GMT+01:00 Jeremy Boynes :
>> On Nov 27, 2017, at 7:38 AM, Romain Manni-Bucau  
>> wrote:
>>
>> 2017-11-27 16:31 GMT+01:00 Jeremy Boynes :
>>> On Nov 27, 2017, at 12:07 AM, Matthew Broadhead
>>>  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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: taglibs-user-h...@tomcat.apache.org



Re: xalan usage in taglibs

2017-11-27 Thread Jeremy Boynes
> On Nov 27, 2017, at 7:38 AM, Romain Manni-Bucau  
> wrote:
> 
> 2017-11-27 16:31 GMT+01:00 Jeremy Boynes :
>> On Nov 27, 2017, at 12:07 AM, Matthew Broadhead
>>  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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: taglibs-user-h...@tomcat.apache.org



Re: xalan usage in taglibs

2017-11-27 Thread Romain Manni-Bucau
2017-11-27 16:31 GMT+01:00 Jeremy Boynes :
> On Nov 27, 2017, at 12:07 AM, Matthew Broadhead
>  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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: taglibs-user-h...@tomcat.apache.org



Re: xalan usage in taglibs

2017-11-27 Thread Jeremy Boynes
> On Nov 27, 2017, at 12:07 AM, Matthew Broadhead 
>  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 

 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

2017-11-27 Thread Matthew Broadhead
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  
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?



-
To unsubscribe, e-mail: taglibs-user-unsubscr...@tomcat.apache.org
For additional commands, e-mail: taglibs-user-h...@tomcat.apache.org



Re: xalan usage in taglibs

2017-11-26 Thread 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

2017-11-26 Thread Matthew Broadhead
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  
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.



-
To unsubscribe, e-mail: taglibs-user-unsubscr...@tomcat.apache.org
For additional commands, e-mail: taglibs-user-h...@tomcat.apache.org



Re: xalan usage in taglibs

2017-11-26 Thread 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.