You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Michael Heinen <mh...@googlemail.com> on 2017/05/17 13:32:32 UTC
Tomcat 8.5: wrong classloader used during context startup?
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.
My question:
Is this behaviour expected?
Should Tomcat use libraries of the web app for the startup of a context,
here for web-xml parsing?
Regards,
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 8.5: wrong classloader used during context startup?
Posted by Michael Heinen <mh...@googlemail.com>.
Am 18.05.2017 um 19:01 schrieb Mark Thomas:
> 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:
> https://svn.apache.org/viewvc?view=revision&revision=1731216
>
>> 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?
A commercial third party web application contains some oracle database
jars. This application is not yet released for Tomcat 8.5. One of these
jars contains a SAXParserFactory implementation which references a class
from another oracle jar which we do not have. Therefore a
ClassNotFoundException occurred. Nothing to blame Tomcat for. The third
party webApp is not packaged correctly and not ready for TC 8.5.
I just noticed this changed behaviour and wanted to let you know about it.
Maybe it is relevant for others or maybe it is something you want to fix
in order to make the start procedure more robust.
>
> 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?
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 8.5: wrong classloader used during context startup?
Posted by Mark Thomas <ma...@apache.org>.
On 23/05/17 19:09, Christopher Schultz wrote:
> Mark,
>
> On 5/21/17 5:49 AM, Mark Thomas wrote:
>> On 21/05/2017 00:30, Christopher Schultz wrote:
>>> Mark,
>>>
>>> On 5/19/17 3:45 PM, Mark Thomas wrote:
>>>> On 19/05/2017 15:25, Christopher Schultz wrote:
>
>>>>> 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.
>>>
>>> That's exactly my point: Tomcat is using an untrusted XML parser
>>> to parse untrusted XML. If the XML parser is trusted, then
>>> parsing the untrusted XML is safe(r).
>
>> I disagree.
>
>>> Take for example XML billion laughs or external entity attacks.
>>> These attacks are typically prevented through disabling external
>>> entities or DTDs themselves.
>>>
>>> If the XML parser is provided by the application, those
>>> capabilities can be left enabled even if Tomcat attempts to
>>> disable them by setting the proper properties on the parser.
>>>
>>> If Tomcat (or the JVM) provides the XML parser, then those
>>> security precautions can be relied upon to protect the JVM from
>>> such an application.
>
>> The threat being considered here is malicious application code.
>
>> The standard protection against malicious application code is
>> running under a security manager. And even then, there are plenty
>> of things an application can do to harm the server.
>
>> while (true) { }
>
>> being one of the simplest.
>
>> What this quickly boils down to is 'Does placing malicious code in
>> the XML parser enable an attacker to do something they could not
>> otherwise do?' Does it enable them to bypass any of the security
>> constraints imposed by the SecurityManager? I believe the answer to
>> that question is no - hence I believe that using an XML parser
>> provided by the application is not a security threat.
>
> The reason I think it's a security threat is because, when Tomcat
> calls the XML parser, the XML parser is being run with elevated
> (Tomcat) privileges instead of with the privileges normally associated
> with the application (that is, restricted privileges).
No, it isn't.
If the XML parser has been provide by the application, then restricted
application privileges apply.
> The billion laughs example was just an illustration. If running under
> a SecurityManager, the application (usually) couldn't open the
> /etc/passwd file, but if the app provides an XML parser
> implementation, then it can get Tomcat to read that file for it...
> again perhaps using XML entities.
No, it can't.
>> Note that the previous XXE issues were possible partly because
>> there was a single container level web.xml parser that executed
>> with container permissions.
>
> What do you mean by "single" here? Do you mean that the parser wasn't
> being re-initialized (or, better yet, re-constructed) and so there may
> have been some carry-over from a previous parse() call?
No. The issue was that it was container (actually JRE) provided so it
ran with container permissions.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 8.5: wrong classloader used during context startup?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Mark,
On 5/21/17 5:49 AM, Mark Thomas wrote:
> On 21/05/2017 00:30, Christopher Schultz wrote:
>> Mark,
>>
>> On 5/19/17 3:45 PM, Mark Thomas wrote:
>>> On 19/05/2017 15:25, Christopher Schultz wrote:
>
>>>> 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.
>>
>> That's exactly my point: Tomcat is using an untrusted XML parser
>> to parse untrusted XML. If the XML parser is trusted, then
>> parsing the untrusted XML is safe(r).
>
> I disagree.
>
>> Take for example XML billion laughs or external entity attacks.
>> These attacks are typically prevented through disabling external
>> entities or DTDs themselves.
>>
>> If the XML parser is provided by the application, those
>> capabilities can be left enabled even if Tomcat attempts to
>> disable them by setting the proper properties on the parser.
>>
>> If Tomcat (or the JVM) provides the XML parser, then those
>> security precautions can be relied upon to protect the JVM from
>> such an application.
>
> The threat being considered here is malicious application code.
>
> The standard protection against malicious application code is
> running under a security manager. And even then, there are plenty
> of things an application can do to harm the server.
>
> while (true) { }
>
> being one of the simplest.
>
> What this quickly boils down to is 'Does placing malicious code in
> the XML parser enable an attacker to do something they could not
> otherwise do?' Does it enable them to bypass any of the security
> constraints imposed by the SecurityManager? I believe the answer to
> that question is no - hence I believe that using an XML parser
> provided by the application is not a security threat.
The reason I think it's a security threat is because, when Tomcat
calls the XML parser, the XML parser is being run with elevated
(Tomcat) privileges instead of with the privileges normally associated
with the application (that is, restricted privileges).
The billion laughs example was just an illustration. If running under
a SecurityManager, the application (usually) couldn't open the
/etc/passwd file, but if the app provides an XML parser
implementation, then it can get Tomcat to read that file for it...
again perhaps using XML entities.
A slightly more concrete example: <Context logEffectiveWebXml="true">;
the WEB-INF/web.xml file contains an entity reference to /etc/passwd;
Tomcat loads the web.xml file and replaces the entity with
/etc/passwd, then writes the effective web.xml to the logger. The
application presumably has access to its own logs (even after the
fact) and the application owner has read a file they ought not to have
access to.
> Keep in mind that this parser is only used for this application and
> is only used for web.xml (and fragments).
>
> If there was a single parser shared between all applications then
> this would be an issue. We'd have a memory leak as well as the
> potential for information disclosure across the web application
> boundary. We have had issues like that in the past (CVE-2009-0783)
> but this bug is not the same.
>
> Note that the previous XXE issues were possible partly because
> there was a single container level web.xml parser that executed
> with container permissions.
What do you mean by "single" here? Do you mean that the parser wasn't
being re-initialized (or, better yet, re-constructed) and so there may
have been some carry-over from a previous parse() call?
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIyBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlkket4ACgkQHPApP6U8
pFg0Cg/4pQwjYsJI/VREZMtJ2kUgL9B2k3f6HI0xFGQWL8+tnHSo+3EI+4TGf8p+
/K3Ea8basxkJYSNOeFuGVMtEEjZJpjsu3enwOxJ0WPFN8DrS6L13xRNrhBTk+cfa
d8TiboR1TgE8fa7rX1tEOgZEQ+Om/3vBbMjVYrsuQqsbsfdLaik7QTNZEFsMrnth
B6fHHjj7JvGM91g7jNcQXLd87vMAE7yW8NWYK1YJ5Hqgb9vzGpMTVJpJpP0dIEDC
qx+2gQLZHNdI0MoJtQIxwYg/MZtOfcu6iT8OPj0KZXJixwZ8uUK7y9VClMdvr/pr
nGe0+MCelaHD5eUqXYxGnWmj8noxoD62oPQFlTb1rfwM8LCnQZz4KwAX7jkzx1tJ
gQspDsjS4qgcKM0mX9T0cNziTjlUN/lmMC1rSz6zLTxm4nVhXmskJltPWm3xDETv
NIqM05hvDcQkpD1Nj+BkDQ/lVb2U1EY0+j6Nt+eCTnpjbdtGL3JxPuQQwA9dnfGx
lyidNf3sNVbB7lfDQYOLpo3UAXY4U7uCpT1/gj83TBm5mZaQrgUnv7/LFWZjiLI5
Je0DTAg86GuAHxuJ+0OeSuvG52Z9Gyg4YblBS05M1KOwFq6HZF9DeJb70vLRE7G3
hjN6a6CnMSXxAcrpkMxaT0lKeSPhV9Ozt7GmUX4ox8l5pOYBGA==
=ninR
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 8.5: wrong classloader used during context startup?
Posted by Mark Thomas <ma...@apache.org>.
On 21/05/2017 00:30, Christopher Schultz wrote:
> Mark,
>
> On 5/19/17 3:45 PM, Mark Thomas wrote:
>> On 19/05/2017 15:25, Christopher Schultz wrote:
>>> 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.
>
> That's exactly my point: Tomcat is using an untrusted XML parser to
> parse untrusted XML. If the XML parser is trusted, then parsing the
> untrusted XML is safe(r).
I disagree.
> Take for example XML billion laughs or external entity attacks. These
> attacks are typically prevented through disabling external entities or
> DTDs themselves.
>
> If the XML parser is provided by the application, those capabilities
> can be left enabled even if Tomcat attempts to disable them by setting
> the proper properties on the parser.
>
> If Tomcat (or the JVM) provides the XML parser, then those security
> precautions can be relied upon to protect the JVM from such an
> application.
The threat being considered here is malicious application code.
The standard protection against malicious application code is running
under a security manager. And even then, there are plenty of things an
application can do to harm the server.
while (true) {
}
being one of the simplest.
What this quickly boils down to is 'Does placing malicious code in the
XML parser enable an attacker to do something they could not otherwise
do?' Does it enable them to bypass any of the security constraints
imposed by the SecurityManager? I believe the answer to that question is
no - hence I believe that using an XML parser provided by the
application is not a security threat.
Keep in mind that this parser is only used for this application and is
only used for web.xml (and fragments).
If there was a single parser shared between all applications then this
would be an issue. We'd have a memory leak as well as the potential for
information disclosure across the web application boundary. We have had
issues like that in the past (CVE-2009-0783) but this bug is not the same.
Note that the previous XXE issues were possible partly because there was
a single container level web.xml parser that executed with container
permissions.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 8.5: wrong classloader used during context startup?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Mark,
On 5/19/17 3:45 PM, Mark Thomas wrote:
> 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:
>>> https://svn.apache.org/viewvc?view=revision&revision=1731216
>>
>>>> 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.
That's exactly my point: Tomcat is using an untrusted XML parser to
parse untrusted XML. If the XML parser is trusted, then parsing the
untrusted XML is safe(r).
Take for example XML billion laughs or external entity attacks. These
attacks are typically prevented through disabling external entities or
DTDs themselves.
If the XML parser is provided by the application, those capabilities
can be left enabled even if Tomcat attempts to disable them by setting
the proper properties on the parser.
If Tomcat (or the JVM) provides the XML parser, then those security
precautions can be relied upon to protect the JVM from such an
application.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlkg0a4ACgkQHPApP6U8
pFg20g/9G7hHrLSaPFF7jhZ/LLhbOHhf8c1eCttSDQx8FoUDmH/zzeYjUKDCKsvu
XceUeOhSGL42NqCfUffztttt/jo3+LObFYBxDjrx0PA5pIatJi/1ISh85W2CcbP/
OcNHPM9QIzGeXJ3mxXFodDiZQYesZXtysqwI7YapdqUujNaWOiy15pJMSN5M/ij4
bUJuzeUnwcsJ5xRn6Lsnqf/4Nq8N7nbzQVzE2tX/evmn9p2BBdvpcMoyyHB+V9hx
IUb9hHMtoOQrFOZTQ/noQ6h7CI+fiyQm5RCH08Eq4ZMJ662K521E00dyBQpxNGxq
D7u8yHnc7WpOjXx7Mf+ECVDeHlVGkE7Q4skBYbdxkUjCUhTmjvvYFiCEI7aFymF6
kd5YAvr2IxsfBGPyyAD5eeBoKrKLUE+GeT+jikGjWKxgbD/jwRMwJw8E9xaO7P6T
SmzR4FMySdmGKXuTozCDjS0IKiHrT567DDBg3yZ5QLX8qKMByxVbCJ88VBlTj3Xy
+wGrlApX/C0BMmsY+5uIS/wZqzA8u6uqkfIhas7+th9CbrBsJq1FZfvgZLUROw0M
jQGsUHiclE2PmrALFeGV/pqzpKX1BvxeIMcDspd8HpJxQAcKSOFCSKUtNZ5skG2f
EVopsN97eNgeqV6ZaLHqzsJTqhFEFfvOoJ7B2syvTCHqcDUuMOk=
=fzQH
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 8.5: wrong classloader used during context startup?
Posted by Mark Thomas <ma...@apache.org>.
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:
>> https://svn.apache.org/viewvc?view=revision&revision=1731216
>
>>> 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.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 8.5: wrong classloader used during context startup?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
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:
> https://svn.apache.org/viewvc?view=revision&revision=1731216
>
>> 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.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlkfAHIACgkQHPApP6U8
pFhZlQ//XXcwN31vZixekSO0tIqAa0Ekcas7jMngfIBlHh2AcIJlNy2qTdXvNPGO
Fow/ZULS8dpZ5Elfd3CXUSrmq6tgbRJvA22MInsme1GfWLdBen4XfkKOS0RQrJIG
h+VkNS46Yr0rCU9pNW/cHlGKYckDnigLkwGQWBND6pz02yJZ138lVruZlTOyq/e3
hOwgd25LJ7nmEEfIZ2ZqYRCTltOts4LSrZxmkrSiPs6ibLU86ehbseBPo1j6nWoP
g7LpLS6AZcJGIFlYaAMh9yN7twLv6dI9U8Qy7eZxb8BL7VBvV4zDNV1EqQqs15SY
Y+ruSq13Oqk19KY3KaabCkeGI+dsP6sj0w7hQigdS9zrI8eiMITX+zxc8nBq/vbJ
L169hW4UtCgo/a8YziUZCZYcBeH0D1cxyr5KWjS6FBsVF/tvtRm6vE6bKY2UNE4C
4oFIpcPcrU9kWMkkZxrMnt+c/E2MN4w6tL6C348RV931wLgePreqUPXu1cFlTgC5
B+qbZ4Ug6NVm+5bi4iY2eb+kzSwHcc9Ds1ILIsdhmLUhIWoV0P0Rfpd6mCgg41qL
yy5eiLZ3Gi4NLqgMRHSbsrJCBm9pwbUc+sIbz9wElG6QPwUgwCpekvat1mM3KxDR
eQtoqOD14qqfU8J+uKs7ViUVzylTCip1IGqv/BoXMqc4/dE5giw=
=HlM/
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 8.5: wrong classloader used during context startup?
Posted by Mark Thomas <ma...@apache.org>.
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:
https://svn.apache.org/viewvc?view=revision&revision=1731216
> 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?
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org