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
