Bug 38198 - When using context xml definitions standalone file, tomcat wrongly uses the file name instead the context path definition
Summary: When using context xml definitions standalone file, tomcat wrongly uses the f...
Status: RESOLVED FIXED
Alias: None
Product: Tomcat 5
Classification: Unclassified
Component: Unknown (show other bugs)
Version: 5.5.8
Hardware: PC Linux
: P1 major with 5 votes (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
URL: https://www.zarb.org/pipermail/jpacka...
Keywords:
Depends on:
Blocks:
 
Reported: 2006-01-09 16:24 UTC by Oded Arbel
Modified: 2007-01-21 17:50 UTC (History)
3 users (show)



Attachments
Desctiption of path encoding into xml deploy filenames (852 bytes, patch)
2006-01-13 09:32 UTC, Michal Ka
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Oded Arbel 2006-01-09 16:24:59 UTC
When deploying an application in Tomcat 5.5 (been observed in 5.5.8 but not in  
5.0.30), using a context definition xml file, such as  
<TOMCAT_CONF>/Catalina/hostname/myapp.xml, tomcat ignores the context path  
definition in the XML file (i.e. <context path="/some/path">) and instead uses  
the file name (i.e. "myapp" in this case) as the path.  
  
This makes it impossible to create complex server configurations where  
applications are hosted not under the root of the server, in addition to being  
confusing, counter-intuitive and just plain wrong.  
 
The behavior should be reverted to how it was handled under tomcat 5.0.
Comment 1 Markus Schönhaber 2006-01-09 16:53:51 UTC
(In reply to comment #0)
> When deploying an application in Tomcat 5.5 (been observed in 5.5.8 but not in  
> 5.0.30), using a context definition xml file, such as  
> <TOMCAT_CONF>/Catalina/hostname/myapp.xml, tomcat ignores the context path  
> definition in the XML file (i.e. <context path="/some/path">) and instead uses  
> the file name (i.e. "myapp" in this case) as the path.  

RTFM. Especially the section in
http://tomcat.apache.org/tomcat-5.5-doc/config/context.html
that states:
"The value of this field [path] must not be set except when statically defining
a Context in server.xml, as it will be infered from the filenames used for
either the .xml context file or the docBase."

> This makes it impossible to create complex server configurations where  
> applications are hosted not under the root of the server, in addition to being  
> confusing, counter-intuitive and just plain wrong.  

No, your statement is plain wrong. If you want to set the context path to
"/some/path", name the XML file containing the Context definition "some#path.xml".

BTW: Just doing a quick glance over Tomcat's documention, I didn't find the
latter mentioned. So it might be a good idea to add this to
http://tomcat.apache.org/tomcat-5.5-doc/config/context.html
or
http://tomcat.apache.org/tomcat-5.5-doc/config/host.html#Automatic%20Application%20Deployment

Comment 2 Fernando Nasser 2006-01-09 17:10:59 UTC
We've encountered this as well, and got complaints about it.
It is very annoying, looks like afeature regression.

But now it seems that it is still possible, but one must code the path in the
file name by using '#'s instead of the '/'s ?
Comment 3 Oded Arbel 2006-01-09 17:23:26 UTC
> RTFM. Especially the section in   
> http://tomcat.apache.org/tomcat-5.5-doc/config/context.html   
> that states:   
> "The value of this field [path] must not be set..it will be infered   
> from the filenames used for either the .xml context file or the docBase."   
   
I must say that though I have read that documentation several times I haven't   
actually read that paragraph - probably because the introduction paragraphs do   
an very good job of describing the path attribute and what it does, and the   
introduction does not say anything about guessing from the file name.    
Specifically the introduction says that context path MUST [sic] be used and   
then goes to great lengths explaining how contexts can be loaded from files,   
without ever mentioning to auto-guessing mechanism.   
   
I would also like to mention again that adhering to the path attribute is how   
tomcat have worked in all previous versions, its how everyone who upgrades to   
tomcat 5.5 would probably expect it to work, and it makes sense.    
   
> No, your statement is plain wrong. If you want to set the context path to  
> /some/path", name the XML file containing the Context definition  
> "some#path.xml".  
  
That is contrived. So basically you are saying that I can forget about having  
logical meaningful names to context files and instead I must use line noise to  
form complex structures ? That sounds like a regression to me.   
 
Might I suggest that for the sake of backward compatibility and for the peace 
of mind of people who are going to upgrade from 5.0 to 5.5, to support the 
path attribute if it exists and do the inferring only if it doesn't ?  
Also it might be a good idea to support a directory structure under 
cont/<engine name>/<host name>/ instead of coding directory separators into 
weird characters, chosen no doubt for their incompatibility with paths in URLs 
and not for readability and ease of use. 
Comment 4 Oded Arbel 2006-01-09 17:40:03 UTC
Sorry about the flip reply, sometimes I can't help it :-(  
  
Can you please point me at the mailing list archive or somewhere else where  
this issue was discussed so I can follow up the arguments in favor of this  
change of behavior ? I did some web searches but couldn't find such a  
discussion.  
  
Thanks, and sorry about the previous comment. 
Comment 5 Fabio Da Soghe 2006-01-12 10:20:49 UTC
I'm one of those users who got lost upgrading from 5.0 to 5.5.
In particular: how you can map the root of the web server using a xml file? Have
you to name it .xml?

Anyway, it seems to me very reasonable the last proposal: to have 5.5 backward
compatible and do the inferring only if the path attribute is missing.

Regards,

Fabio Da Soghe
Comment 6 Michal Ka 2006-01-13 09:32:55 UTC
Created attachment 17409 [details]
Desctiption of path encoding into xml deploy filenames

I am the one who originally issued this problem in redhat's bugzilla so I think
it would be good thing to have the same behaviour as in 5.0 because it makes
upgrades much easier.
But for now the filename solution is sufficient as soon as it is documented
somewhere. I prepared this small patch against docs/config/host.xml.
Changes like this should be probably documented somewhere in Release docs too.
Comment 7 Mark Thomas 2006-11-06 18:58:35 UTC
I recently re-wrote the context name from filename section of the Context docs
so I added a reference to this from the Host docs.

The changes will be in 5.5.21 onwards.

For the record, 5.5.x will not be made backwards compatible with the 5.0.x
functionality.
Comment 8 Marcin.Burdyk 2007-01-21 17:50:33 UTC
Comment on attachment 17409 [details]
Desctiption of path encoding into xml deploy filenames

>--- container/webapps/docs/config/host.xml	2006-01-03 16:15:14.000000000 +0100
>+++ /home/mkaspar/prac/host.xml	2006-01-13 09:16:53.000000000 +0100
>@@ -272,7 +272,9 @@
>         attribute of this <code>&lt;Context&gt;</code> element will typically
>         be the absolute pathname to a web application directory, or the
>         absolute pathname of a web application archive (WAR) file (which
>-        will not be expanded).</li>
>+        will not be expanded). The path attribute wil be automatically set to
>+        its filename where slashes ("/") are encoded as hashes ("#") so
>+        any#path.xml will result in path="/any/path").</li>
>     <li>Any web application archive file within the application base (appBase)
>         directory that does not have a corresponding
>         directory of the same name (without the ".war" extension) will be