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

Reply via email to