On 13/01/2012 22:04, Filip Hanik - Dev Lists wrote: > I'm looking for a better reason for this change. What was the reasoning > behind this limitation, as it breaks years of compatibility. > Workaround is to point docBase to a directory.
The reasoning was that the documentation said one thing (that WARs outside the appBase would not be unpacked into the appBase) while the code did exactly the opposite but did not handle any of the special cases it should have. The documentation was the same (and had been for many years) for 5.5.x, 6.0.x and 7.0.x. I choose to align the code with the documentation on that occasion as it was simpler than making sure that the unpackWARs option worked correctly. The deployment process is full of edge cases (although fortunately a lot fewer than there were in the 4.1.x days) and it would have taken a fair amount of time to go through them and check that they were all handled correctly. As an aside, it would probably be a good idea if we documented all the use cases that deployment is meant to handle. It would make it easier to assess any future changes. I also took into account the following: - the current behaviour was undocumented (the documentation stated the opposite would happen) - the workaround (use a directory for the external docBase rather than a WAR) was simple. I'm not against a change to the documented behaviour and expanding external WARs into the docBase but any change along those lines would need to be carefully thought through. I don't think it is as simple as just unpacking the WAR, particularly for undeployment and context.xml updates (e.g. a context.xml update that changed the docBase would need special handling). Mark > > best > Filip > > > On 3/11/2011 11:40 AM, ma...@apache.org wrote: >> Author: markt >> Date: Fri Mar 11 18:40:13 2011 >> New Revision: 1080719 >> >> URL: http://svn.apache.org/viewvc?rev=1080719&view=rev >> Log: >> Don't unpack WAR files if they are not located in the Host's appBase. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
