tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [Bug 57736] changes from Tomcat 7 to Tomcat 8 causing problems
Date Mon, 23 Mar 2015 10:02:41 GMT

--- Comment #4 from Frank Holler <> ---
(In reply to Mark Thomas from comment #3)
> (In reply to Frank Holler from comment #2)
> > To use unpackWars="true" is a problem for us.
> Why?
> > So i digged a little deeper into the problem.
> > I found out that Tomcat 7 and Tomcat 8 both extract classes and libs from
> > WEB-INF to CATALINA_BASE/work/[app]/, even if unpackWars="false" is set.
> That is not correct. Tomcat 8 does not extract JARs or classes to the work
> directory under any circumstances.
> One of the options considered to address the performance problems is to
> restore the extraction of the JARs to the work directory but that creates
> complexity in an area where we have been trying to reduce it. This is still
> an option of last resort but my preference - where possible - is to address
> the reasons why people can't use unpackWARs="true".

You're rigt, my fault. i did not clean up the work directory after changing
form unpackWars="true" to "false". So the remaining files was leftover from the
last restart.

The reason why we don't use unpackWars="true" is, that the unpacked directory
won't get updated, if the war changes. For security reasons we (and our
customers) don't deploy the "manager" or any other webapp, only our war.

So the deployment process with unpackWars="false" is:
1.) drop the new war into webapps
2.) restart tomcat

With unpackWars="true" and without using "manager"-app the steps to update
would be:
1.) stop tomcat
2.) delete the unpacked folder => otherwise it won't work!!!
3.) drop the new war into webapps
4.) start tomcat again

To check, if this behavior changed with tomcat 8 we did the following:

Our webapp version 2.6.6 is deployed with unpackwars="true", the unpacked
folder exists. Afterwards we replaced the WAR with version 2.6.7 and restart
As any version before, the unpacked directory wasn't updated, so the version
2.6.6 is started again, the new war with version 2.6.7 is ignored.
After this problem occured often, we told our customers to set
unpackWars="false", so our customers (and our support of course) has less
problems when delvierung updates of our app. 
So perhaps you understand, why we won't like to tell our customers to change
unpackWars back when updating to tomcat 8.

I understand, that a revert of the changes isn't easy, but for my opinion,
unpackWars="false" isn't usable with tomcat 8 any more without refactoring many
of our logic to bypass the new loader behavior. 
The problem is, that we don't know, which of the used libs also have a problem
(like com.mycila.xmltool), so we would be happy, if the behavior of tomcat 8
keeps compatible tomcat 7.

Kind regards, 

You are receiving this mail because:
You are the assignee for the bug.

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

View raw message