Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Subject: Re: Tomcat 8.5: wrong classloader used during context startup?
To: users@tomcat.apache.org
References: <f69475a6-55c0-abe4-df0c-e0829682ccc0@googlemail.com>
From: Mark Thomas <markt@apache.org>
Message-ID: <847f40ab-1559-7520-74c1-10517821b5c4@apache.org>
Date: Thu, 18 May 2017 18:01:28 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0)
 Gecko/20100101 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: <f69475a6-55c0-abe4-df0c-e0829682ccc0@googlemail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
archived-at: Thu, 18 May 2017 17:01:52 -0000

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