tomcat-taglibs-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matthew Broadhead <matthew.broadh...@nbmlaw.co.uk>
Subject Re: xalan usage in taglibs
Date Thu, 08 Feb 2018 10:19:09 GMT
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 <jboynes@apache.org>:
>>> On Nov 27, 2017, at 7:38 AM, Romain Manni-Bucau <rmannibucau@apache.org>
wrote:
>>>
>>> 2017-11-27 16:31 GMT+01:00 Jeremy Boynes <jboynes@apache.org>:
>>>> On Nov 27, 2017, at 12:07 AM, Matthew Broadhead
>>>> <matthew.broadhead@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


Mime
View raw message