tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Pringle <>
Subject Use case for adding configurable behavior for unpacking WARs deployed outside the Host's appBase?
Date Thu, 20 Oct 2011 20:17:19 GMT
We finally tracked down why a 3rd party application we use stopped working as of our upgrade
to 7.0.14 (and subsequent) - it was the fix applied to 7.0.12 which stopped unpacking WARs
that were deployed from an appBase outside that of the container.  It presented itself in
an odd way, which is why it took so long to track down (vague and unhelpful RMI connection
failure from some spawned RMI server).

Digging a bit today I found some history on this issue, which seems to be summarized in this
bugzilla report:

Here's my use case for why I'd like this behavior to be configurable, either at the app level
or the host level (ie, honor either or both of the unpackWAR flags for applications outside
of the host's appBase).

We have a standardized deployment mechanism.  We prefer the model where wars are put in a
standard directory (outside of the server's app base) and then referenced by a context file
for the instance (<instance>/conf/<engine>/<host>/mycontext.xml).  This
allows us to manage the WAR files outside of the tomcat instance directory and have the war
file names be something other than the context path for the web app (like a filename with
version information in it!).

We deploy mostly web applications developed in-house.  These applications don't care whether
they are exploded or not.

We also deploy a few 3rd party web applications.  One in particular *requires* that it be
exploded on disk.  The vendor refuses to change the app.

Given the current state of things, we will have to modify our deployment approach across the
board just to satisfy this one 3rd party application, or have a non-homogenous approach to
web application deployment and treat this one in the "special manner".

Neither approach is appealing (3rd party app forcing a particular deployment model on our
operations or heterogeneous deployment model).

Would it be possible to have the behavior put back at least as an optional behavior?



This message and the information contained herein is proprietary and confidential and subject
to the Amdocs policy statement,
you may review at

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message