Re: xalan usage in taglibs

[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

[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