You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Filip Hanik - Dev Lists <de...@hanik.com> on 2012/01/13 23:04:08 UTC
Re: svn commit: r1080719 - in /tomcat/trunk: java/org/apache/catalina/startup/ContextConfig.java
webapps/docs/changelog.xml
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.
best
Filip
On 3/11/2011 11:40 AM, markt@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.
>
> Modified:
> tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java
> tomcat/trunk/webapps/docs/changelog.xml
>
> Modified: tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java
> URL: http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java?rev=1080719&r1=1080718&r2=1080719&view=diff
> ==============================================================================
> --- tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java (original)
> +++ tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java Fri Mar 11 18:40:13 2011
> @@ -672,12 +672,6 @@ public class ContextConfig
> Host host = (Host) context.getParent();
> String appBase = host.getAppBase();
>
> - boolean unpackWARs = true;
> - if (host instanceof StandardHost) {
> - unpackWARs = ((StandardHost) host).isUnpackWARs()
> -&& ((StandardContext) context).getUnpackWAR();
> - }
> -
> File canonicalAppBase = new File(appBase);
> if (canonicalAppBase.isAbsolute()) {
> canonicalAppBase = canonicalAppBase.getCanonicalFile();
> @@ -711,6 +705,13 @@ public class ContextConfig
> context.getWebappVersion());
> String pathName = cn.getBaseName();
>
> + boolean unpackWARs = true;
> + if (host instanceof StandardHost) {
> + unpackWARs = ((StandardHost) host).isUnpackWARs()&&
> + ((StandardContext) context).getUnpackWAR()&&
> + (docBase.startsWith(canonicalAppBase.getPath()));
> + }
> +
> if (docBase.toLowerCase(Locale.ENGLISH).endsWith(".war")&& !file.isDirectory()&& unpackWARs) {
> URL war = new URL("jar:" + (new File(docBase)).toURI().toURL() + "!/");
> docBase = ExpandWar.expand(host, war, pathName);
>
> Modified: tomcat/trunk/webapps/docs/changelog.xml
> URL: http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/changelog.xml?rev=1080719&r1=1080718&r2=1080719&view=diff
> ==============================================================================
> --- tomcat/trunk/webapps/docs/changelog.xml (original)
> +++ tomcat/trunk/webapps/docs/changelog.xml Fri Mar 11 18:40:13 2011
> @@ -50,6 +50,10 @@
> inside server.xml and log a warning that the configuration has been
> corrected. (markt)
> </add>
> +<fix>
> + Don't unpack WAR files if they are not located in the Host's
> + appBase. (markt)
> +</fix>
> </changelog>
> </subsection>
> <subsection name="Other">
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 10.0.1204 / Virus Database: 1498/3500 - Release Date: 03/11/11
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: svn commit: r1080719 - in /tomcat/trunk: java/org/apache/catalina/startup/ContextConfig.java
webapps/docs/changelog.xml
Posted by Konstantin Kolinko <kn...@gmail.com>.
2012/1/17 Filip Hanik - Dev Lists <de...@hanik.com>:
> The current behavior is a lot cleaner, (it just broke existing
> installations), as removing the XML file when the tomcat is not running
> actually undeploys the app. When the war was expanded into appBase before,
> it would have still been deployed.
>
>
>
> On 1/14/2012 10:57 AM, Mark Thomas wrote:
>>
>> 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, markt@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.
>>
I do not mind if someone reimplemented the feature, but keeping it off
by default,
That is like we have Host's "copyXML" that restores TC6 behaviour and
is off by default.
Here is Bugzilla report that one can reference:
https://issues.apache.org/bugzilla/show_bug.cgi?id=51294
I wonder whether it shall be configurable at Context level as well.
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: svn commit: r1080719 - in /tomcat/trunk: java/org/apache/catalina/startup/ContextConfig.java
webapps/docs/changelog.xml
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
The current behavior is a lot cleaner, (it just broke existing installations), as removing the XML file when the tomcat is not running
actually undeploys the app. When the war was expanded into appBase before, it would have still been deployed.
On 1/14/2012 10:57 AM, Mark Thomas wrote:
> 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, markt@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: svn commit: r1080719 - in /tomcat/trunk: java/org/apache/catalina/startup/ContextConfig.java
webapps/docs/changelog.xml
Posted by Mark Thomas <ma...@apache.org>.
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, markt@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org