Re: xalan usage in taglibs

2017-11-27 20:01 GMT+01:00 Jeremy Boynes <[email protected]>:
>> On Nov 27, 2017, at 7:38 AM, Romain Manni-Bucau <[email protected]>=
 wrote:
>>
>> 2017-11-27 16:31 GMT+01:00 Jeremy Boynes <[email protected]>:
>>> On Nov 27, 2017, at 12:07 AM, Matthew Broadhead
>>> <[email protected]> wrote:
>>>
>>> In TomEE 7.0.3 everything is fine at startup.  But if a webapp is reloa=
ded 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=E2=80=99t need to do that as TomEE should be providing its own
>>> implementation of JSTL which would mean there is a chance of conflict i=
f 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 incl=
ude
>>> taglibs and avoid including the Xalan dependency but I wouldn=E2=80=99t=
 expect that
>>> to work as it actually is needed by the XML tags. The dependency is
>>> =E2=80=9Cprovided=E2=80=9D scope to avoid automatic transitive inclusio=
n for applications
>>> that don=E2=80=99t use the XML tags (which is most). For container inte=
gration 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 avoi=
d rebuilding the DTM for each XPath execution, the tags work the same way a=
n 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 tag=
s were used in an application
> c) shade Xalan and increase the library size when most users wouldn=E2=80=
=99t 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 th=
e container and so would control which dependencies they needed
> - users on a Web- or Full-profile container would have the entire JSTL im=
plementation 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.

>
>