I'm trying to run hudson (tried with 1.361 and 1.352) on tomcat 7.0.0 rc4. I'm deploying it by putting the following hudson.xml file (it works with tomcat-6.0.26): # cat /etc/tomcat/Catalina/localhost/hudson.xml <?xml version="1.0" encoding="UTF-8"?> <!-- $Id: hudson-context.xml,v 1.2 2009/02/01 23:26:40 pawelz Exp $ --> <Context path="/hudson" docBase="/usr/share/hudson" privileged="false" allowLinking="true"> </Context> into Catalina/localhost directory. I have also tried to deploy .war file directly via web interface, with no luck. After deploying tomcat, manager says: ‘OK - Started application at context path /hudson’, but when I navigate to /hudson/, I'm getting e404', but when I navigate to /hudson/, I get HTTP 404 NOT FOUND error. There are no errors/exceptions in catalina log. Other applications work correctly (nexus, JIRA). I don't know whether it is bug in tomcat or in nexus, so I've also filed a bug report in hudson JIRA: http://issues.hudson-ci.org/browse/HUDSON-6738 My environment is: PLD Linux th tomcat 7.0.0 rc4 icedtea6 1.8 (also tried with java-sun-1.6.0.20 with no luck) Please let me know if I can provide you with more details/information.
(In reply to comment #0) > I don't know whether it is bug in tomcat or in nexus, so I've also filed a bug I meant ‘hudson’, not ‘nexus’ of course.
There are comments of HUDSON developers, they asked me to paste them here. I hope they will be helpful in tracking the problem: ============================= mindless added a comment - 11/Jun/10 01:09 PM There may be crazy parts of Hudson bootstrapping but I don't think this part is crazy. war/resources/WEB-INF/web.xml is pretty basic, with: <servlet-mapping> <servlet-name>Stapler</servlet-name> <url-pattern>/</url-pattern> </servlet-mapping> which should map everything to stapler for handling.. ============================= jieryn added a comment - 11/Jun/10 01:36 PM Change this to <servlet-mapping> <servlet-name>Stapler</servlet-name> <url-pattern>/*</url-pattern> </servlet-mapping> and it will work. I tested this and things appear to be working sanely now.
This was triggered by fixing bug47378 which implemented a spec mandated requirement for welcome file mapping. This has its issues - see that bug report and the linked Jetty discussion for details. The upshot is that welcome files are inherited from Tomcat's default web.xml and include index.jsp. Tomcat is (correctly as per the spec) matching the index.jsp welcome file to the JSP servlet which in turn is returning a 404 to the user since index.jsp doesn't exist. I have doubled checked the Servlet 3.0 spec wording on welcome files and I believe Tomcat is spec complaint here. I hate to bounce this one back to Hudson, but I think fixing this is going to require a change to Hudson. The simplest change is to switch the mapping to "/*" rather than "/". This effectively bypasses the welcome file process and ensures *all* requests are mapped to the desired servlet. Alternative options include: - requiring users to remove any global welcome files - setting an empty set of welcome files in Hudson's web.xml Since the desired behaviour is to map everything to the Stapler servlet and not use use welcome files then I would recommend switching to a mapping of "/*" since that will always bypass any welcome file settings as is desired in this case. I am closing this as invalid since Tomcat is implementing the spec correctly here.
I'm the developer of Hudson, and I'm not sure if I agree with the conclusion. In the servlet 3.0 spec section 10.10, one of the examples reads: A request URI of /catalog/products/ will be passed to the "default" servlet, if any. If no "default" servlet is mapped, the request may cause a 404 not found, may cause a directory listing including shop.jsp and register.jsp, or may cause other behavior defined by the container. See Section 12.2, "Specification of Mappings" for the definition of "default" servlet. This is with the following contents in the WAR: /foo/index.html /foo/default.jsp /foo/orderform.html /foo/home.gif /catalog/default.jsp /catalog/products/shop.jsp /catalog/products/register.jsp The "default" servlet defined in section 12.2 is the servlet with url-pattern="/", which in our case is "Stapler". In Hudson, we don't have /index.html nor /index.jsp. So I expect the same logic to dispatch the request to the default servlet, instead of 404. To put this another way, while the section 10.10 says the following, it shouldn't be interpreted that the container can really do whatever it wants --- otherwise it doesn't explain why the above /catalog/products/ would map to the default servlet. It should be interpreted that the default servlet be consulted: If no matching welcome file is found in the manner described, the container may handle the request in a manner it finds suitable. For some configurations this may mean returning a directory listing or for others returning a 404 response.
Mark is correct with his reading of the Servlet 3.0 spec. The default web.xml includes "index.jsp" in the welcome-file list. This pattern is also mapped to the JspServlet. As a result, Tomcat is required to pass the request to JspServlet by the spec. The Tomcat developers have a long history of resisting this change to the spec, but it is there now, and Tomcat has to follow it. Other than what Mark has suggested above, another possibility is for Hudson to include a welcome-file in their web.xml for, say, index.hds, which is suffix mapped to their default servlet.
*** Bug 50073 has been marked as a duplicate of this bug. ***
*** Bug 50161 has been marked as a duplicate of this bug. ***
The new Servlet 3.0 requirements have caused a number of issues. As of Tomcat 7.0.5 a new context option is available "resourceOnlyServlets" that can be used to list Servlets that expect physical resources to exist. By default the JSP Servlet is included in this list that should restore 7.0.5+ to the current 6.0.x behaviour regarding welcome files.
Changed the resolution from INVALID to FIXED since there was an actual change to the code to change the behavior.