https://issues.apache.org/bugzilla/show_bug.cgi?id=51294
Philippe Busque <pbus...@mediagrif.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|FIXED |
--- Comment #9 from Philippe Busque <pbus...@mediagrif.com> 2012-02-02 15:05:37
UTC ---
This if is a major show stopper. It was working fine before, why 'fix' it?
We are currently investigating into upgrading from Tomcat 6 to Tomcat 7.
We have HUNDREDS of Tomcat application running. Some of require to be able to
manipulate the webapps content at runtime. Due to the amount of instance to
manage, we link our war outside the webapp for better management.
This 'fix' break any Tomcat server that require an unpacked war and use any
management tools to manage their configuration and data.
As mentioned by another user, there should be an option to allow unpacking a
WAR located outside of the Webapps.
It was mentioned in another thread the reason it isn't so is it complicate the
autodeploy. Well, make those feature mutually exclusive. You cannot use
autoDeploy if unpackWarOutsideWebapp is true. I know we don't use autoDeploy
for security reason.
We're strongly thinking of stopping the Tomcat 7 migration project and stick to
Tomcat 6 until the EOL if this 'fix' is not rollabacked or offer a workaround.
Nowhere in the documentation of Tomcat 6 was it mentioned the war need to be in
the Webapp to be unpacked. I haven't found any specification mentioning that
this has to be that way too. So changing this behaviour without first
consulting people and on an haunch really was a bad move.
If it's working, don't fix it. Right now, it's broken for a tomcat instance
fully relying on configuration files to manage context and deployment.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
