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: https://issues.apache.org/bugzilla/show_bug.cgi?id=51294 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? Thanks! --Jason This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement, you may review at http://www.amdocs.com/email_disclaimer.asp
