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.
(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
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 ?
> 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.
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.
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
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.
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 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><Context></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