From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050825 Firefox/1.0.4 (Debian package 1.0.4-2sarge3) Description of problem: If I try to deploy application via locating .xml file into $CATALINA_HOME/conf/[enginename]/[hostname]/contextname.xml, it places the context under root path and ignores deeper paths. Ie. I need context path /nsnzr/piv but tomcat deploys application into /piv. After writing apropriate lines into server.xml, everything works fine. The contents of my .xml file is: <Context docBase="/var/www/html/snzr/piv" path="/nsnzr/piv"> </Context> Under tomcat5 from AS1 deployment works fine. Version-Release number of selected component (if applicable): tomcat5-5.5.9-1jpp_5rh How reproducible: Always Steps to Reproduce: 1. Stop tomcat 2. Put .xml file into /etc/tomcat5/conf/[enginename]/[hostname]/ 3. Start tomcat 4. Try http://hostname:port/nsnzr/piv or http://hostname:port/manager/status/all Actual Results: If I try directly the path defined I get no reply (path does not exist), in /manager I can see that the only context that was deployed is hostname/piv. Expected Results: The app should be deployed under /nsnzr/piv not /piv. Additional info: From access log: 127.0.0.1 - - [19/Sep/2005:09:22:09 +0100] "GET /nsnzr/piv HTTP/1.1" 400 - From catalina.out: INFO: REQUEST URI =/nsnzr/piv/ Sep 16, 2005 3:54:04 PM org.apache.catalina.valves.RequestDumperValve invoke INFO: authType=null Sep 16, 2005 3:54:04 PM org.apache.catalina.valves.RequestDumperValve invoke INFO: characterEncoding=null Sep 16, 2005 3:54:04 PM org.apache.catalina.valves.RequestDumperValve invoke INFO: contentLength=0 Sep 16, 2005 3:54:04 PM org.apache.catalina.valves.RequestDumperValve invoke INFO: contentType=null Sep 16, 2005 3:54:04 PM org.apache.catalina.valves.RequestDumperValve invoke INFO: contextPath=null Sep 16, 2005 3:54:04 PM org.apache.catalina.valves.RequestDumperValve invoke INFO: header=host=apl01.ksrzis.cz Sep 16, 2005 3:54:04 PM org.apache.catalina.valves.RequestDumperValve invoke INFO: header=user-agent=Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050825 Firefox/1.0.4 (Debian package 1.0.4-2sarge3) Sep 16, 2005 3:54:04 PM org.apache.catalina.valves.RequestDumperValve invoke INFO: header=accept=text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Sep 16, 2005 3:54:04 PM org.apache.catalina.valves.RequestDumperValve invoke INFO: header=accept-language=en,cs;q=0.5 Sep 16, 2005 3:54:04 PM org.apache.catalina.valves.RequestDumperValve invoke INFO: header=accept-encoding=gzip,deflate Sep 16, 2005 3:54:04 PM org.apache.catalina.valves.RequestDumperValve invoke INFO: header=accept-charset=ISO-8859-1,utf-8;q=0.7,*;q=0.7 Sep 16, 2005 3:54:04 PM org.apache.catalina.valves.RequestDumperValve invoke INFO: header=keep-alive=300 Sep 16, 2005 3:54:04 PM org.apache.catalina.valves.RequestDumperValve invoke INFO: header=connection=keep-alive Sep 16, 2005 3:54:04 PM org.apache.catalina.valves.RequestDumperValve invoke INFO: header=content-length=0 Sep 16, 2005 3:54:04 PM org.apache.catalina.valves.RequestDumperValve invoke INFO: locale=en Sep 16, 2005 3:54:04 PM org.apache.catalina.valves.RequestDumperValve invoke INFO: method=GET Sep 16, 2005 3:54:04 PM org.apache.catalina.valves.RequestDumperValve invoke INFO: pathInfo=null Sep 16, 2005 3:54:04 PM org.apache.catalina.valves.RequestDumperValve invoke INFO: protocol=HTTP/1.1 Sep 16, 2005 3:54:04 PM org.apache.catalina.valves.RequestDumperValve invoke INFO: queryString=null Sep 16, 2005 3:54:04 PM org.apache.catalina.valves.RequestDumperValve invoke INFO: remoteAddr=10.16.11.84 Sep 16, 2005 3:54:04 PM org.apache.catalina.valves.RequestDumperValve invoke INFO: remoteHost=10.16.11.84 Sep 16, 2005 3:54:04 PM org.apache.catalina.valves.RequestDumperValve invoke INFO: remoteUser=null Sep 16, 2005 3:54:04 PM org.apache.catalina.valves.RequestDumperValve invoke INFO: requestedSessionId=null Sep 16, 2005 3:54:04 PM org.apache.catalina.valves.RequestDumperValve invoke INFO: scheme=https Sep 16, 2005 3:54:04 PM org.apache.catalina.valves.RequestDumperValve invoke INFO: serverName=apl01.ksrzis.cz Sep 16, 2005 3:54:04 PM org.apache.catalina.valves.RequestDumperValve invoke INFO: serverPort=443 Sep 16, 2005 3:54:04 PM org.apache.catalina.valves.RequestDumperValve invoke INFO: servletPath=null Sep 16, 2005 3:54:04 PM org.apache.catalina.valves.RequestDumperValve invoke INFO: isSecure=true Sep 16, 2005 3:54:04 PM org.apache.catalina.valves.RequestDumperValve invoke INFO: --------------------------------------------------------------- Sep 16, 2005 3:54:04 PM org.apache.catalina.valves.RequestDumperValve invoke INFO: --------------------------------------------------------------- Sep 16, 2005 3:54:04 PM org.apache.catalina.valves.RequestDumperValve invoke INFO: authType=null Sep 16, 2005 3:54:04 PM org.apache.catalina.valves.RequestDumperValve invoke INFO: contentLength=-1 Sep 16, 2005 3:54:04 PM org.apache.catalina.valves.RequestDumperValve invoke INFO: contentType=null Sep 16, 2005 3:54:04 PM org.apache.catalina.valves.RequestDumperValve invoke INFO: message=No Host matches server name apl01.ksrzis.cz Sep 16, 2005 3:54:04 PM org.apache.catalina.valves.RequestDumperValve invoke INFO: remoteUser=null Sep 16, 2005 3:54:04 PM org.apache.catalina.valves.RequestDumperValve invoke INFO: status=400
Hi, Can you be more specific about "tomcat5 from AS1", please? What is it, which version release, how and where was it downloaded from, how was it built if not downloaded as binary etc. Thanks. Fernando
It was tomcat5-5.0.28-2jpp_5rh.noarch.rpm from Red Hat Application Server 1.0 (AS for i386) that I was experimenting with before availability of Application Server 2.
In this tag you have <Context docBase="/var/www/html/snzr/piv" path="/nsnzr/piv"> ^^^^ ^^^^^ Doesn't the path have to match the docBase? Actually, wouldn't the path be inferred from the value of docBase if it was just omitted? In any case, just make sure the endings overlap.
I do not think they have to match. First because it worked this way in 5.0, second I havent found it in documentation (the only part about matching is that request URI is matched against path attribute) and third I've just tried it: <Context docBase="/var/www/html/psnzr/piv" path="/psnzr/piv"> and made a link in html psnzr -> snzr. Same result as before. In server.xml, it works as expected.
Thanks for trying anyway. We will have to run some experiments here. I will get back to you as soon as possible.
According to the documentation for tomcat 5.5: "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."[1] This did not exist in tomcat 5.0.X previously and I have posted a message on tomcat's developer list asking for an explanation for this change. However, as it stands it is clear that this is expected behaviour. Depending on the name of your xml file, the context name would be inferred, but not for deeper contexts. From these lines in the documentation it seems your work around of editing this in the server.xml seems like the only solution at the moment. Footnotes: 1: http://tomcat.apache.org/tomcat-5.5-doc/config/context.html
OK, I have been bugging Tomcat folks about this and now I've got some more support from other people who are also annoyed by this. Someone is claiming that if you name the file nsnzr#piv.xml it should work I.e, one should replace the context path '/'s with '#'s (no leading '#'). It is a documentation ommission, it is claimed. I am trying to get confirmation on this, but if any of you want to give it a try and let the others know it would be nice.
For reference, this is the bug created by Oded. Please vote if possible, and comment if you have preferences about the way it is handled: http://issues.apache.org/bugzilla/show_bug.cgi?id=38198
Thank you. The # solution works fine, which is good. I am moving to apache's bugzilla to help to solve this problem.
Adding reference to the upstream bug and changing the resolution to UPSTREAM, where this should be fixed/clarified.