tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject Re: Tomcat 8.5: wrong classloader used during context startup?
Date Fri, 19 May 2017 19:45:37 GMT
On 19/05/2017 15:25, Christopher Schultz wrote:
> Mark,
> On 5/18/17 1:01 PM, Mark Thomas wrote:
>> On 17/05/2017 14:32, Michael Heinen wrote:
>>> I am currently migrating a web app from Tomcat 7.0.73 to 8.5.15.
>>> An embedded Tomcat is used on development systems.
>>> The web-inf/lib folder of the application contains a jar with a 
>>> SAXParserFactory implementation. This SAXParserFactory is now
>>> used with TC 8.5 by the WebXmlParser in order to parse the
>>> web.xml (and fails unfortunately). The ServiceLoader finds the
>>> jar because the ParallelWebappClassLoader is used for the
>>> lookup.
>>> TC 7.0.73 uses the sun.misc.Launcher$AppClassLoader and does
>>> therefore not use the jar under web-inf\lib. It creates the
>>> webXml Digester in the init() phase of the stanrardContext. TC
>>> 8.5 does this in the startInternal() phase where the
>>> ParallelWebappClassLoader is instantiated and bound to the
>>> current thread.
>>> Specifying "javax.xml.parsers.SAXParserFactory" as VM param
>>> solves the issue of course.
>> I think this is the fix that triggered this: 
>>> My question: Is this behaviour expected?
>> It looks like an unintended side-effect of the change.
>>> Should Tomcat use libraries of the web app for the startup of a 
>>> context, here for web-xml parsing?
>> The change has been in place for over a year and this is the first 
>> problem we have seen. I'm curious, what exactly was the problem you
>> saw?
>> I'd probably lean towards fixing this on the grounds that you want
>> to parsing of web.xml to be deterministic rather than dependent on
>> what may, or may not, be included in the app.
>> What do others think?
> +1
> Also, for an untrusted application (admittedly a minority use case),
> having Tomcat parse the app-provided XML with an application-provided
> XML parser might have security implications.

I don't believe it does in this case. The file being parsed is web.xml
which is application provided anyway so any manipulation a malicious app
could do via the parser could just be done directly in web.xml.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message