Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-6738

Hudson doesn't start on tomcat 7

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Minor
    • Resolution: Fixed
    • Component/s: deploy-plugin
    • Labels:
      None
    • Environment:
      PLD Linux th, tomcat-7.0.0-rc4

      Description

      I'm trying to deploy hudson 1.361 into tomcat 7.0.0 rc4. (In fact I had working installation of hudson in tomcat 6.0.26 and I just upgraded tomcat, but I have same issue on fresh install).

      Tomcat 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. I tried on java-sun-1.6.0.20 and Icedtea6, same problem on both.

      My context.xml is:

      # 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>
      

      (same context works perfectly with tomcat-6.0.26)

      Please let me know if I can provide you with more details/information. I have testing environment, where I can test patches/workarounds/etc.

      PS.: I'm setting "Priority" to minor, because tomcat-7.0.0-rc4 is not released yet, and after downgrade to tomcat-6.0.26 everything works.
      PS2.: I'm not 1000% sure, that my tomcat is configured correctly, I'm just experimenting with tomcat 7 branch. But other applications (like for example Atlassian JIRA) works.

        Issue Links

          Activity

          pzz pzz created issue -
          Hide
          jieryn jieryn added a comment -

          Please set all Tomcat logging to FINEST.

          http://tomcat.apache.org/tomcat-6.0-doc/logging.html

          I don't think I've read anything about Tomcat 7 changing the way it is configured for logging so the 6.x docs should work.

          Show
          jieryn jieryn added a comment - Please set all Tomcat logging to FINEST. http://tomcat.apache.org/tomcat-6.0-doc/logging.html I don't think I've read anything about Tomcat 7 changing the way it is configured for logging so the 6.x docs should work.
          Hide
          pzz pzz added a comment -

          One new important observation: In fact hudson starts. For example it creates files and directories in its homedir. I'm just unable to open its web interface (HTTP 404 NOT FOUND).

          Jieryn, thank you for advice. I'v set log level to ALL, there are tomcat logs:

          catalina.out
          hudson home directory: /var/lib/hudson
          
          catalina.err
          Jun 10, 2010 6:54:51 PM org.apache.catalina.core.AprLifecycleListener init
          INFO: Loaded APR based Apache Tomcat Native library 1.1.20.
          Jun 10, 2010 6:54:51 PM org.apache.catalina.core.AprLifecycleListener init
          INFO: APR capabilities: IPv6 [true], sendfile [true], accept filters [false], random [true].
          Jun 10, 2010 6:54:51 PM org.apache.catalina.startup.Catalina load
          INFO: Initialization processed in 627 ms
          Jun 10, 2010 6:54:51 PM org.apache.catalina.core.StandardService startInternal
          INFO: Starting service Catalina
          Jun 10, 2010 6:54:51 PM org.apache.catalina.core.StandardEngine startInternal
          INFO: Starting Servlet Engine: Apache Tomcat/7.0.0-RC4
          Jun 10, 2010 6:54:51 PM org.apache.catalina.startup.HostConfig deployDescriptor
          INFO: Deploying configuration descriptor manager.xml from /var/lib/tomcat/conf/Catalina/localhost
          Jun 10, 2010 6:54:51 PM org.apache.catalina.startup.HostConfig deployDescriptor
          INFO: Deploying configuration descriptor hudson.xml from /var/lib/tomcat/conf/Catalina/localhost
          Jun 10, 2010 6:54:52 PM org.apache.catalina.startup.HostConfig deployDescriptor
          INFO: Deploying configuration descriptor ROOT.xml from /var/lib/tomcat/conf/Catalina/localhost
          Jun 10, 2010 6:54:52 PM org.apache.coyote.http11.Http11AprProtocol init
          INFO: Initializing Coyote HTTP/1.1 on http-8080
          Jun 10, 2010 6:54:52 PM org.apache.coyote.http11.Http11AprProtocol start
          INFO: Starting Coyote HTTP/1.1 on http-8080
          Jun 10, 2010 6:54:52 PM org.apache.coyote.ajp.AjpAprProtocol init
          INFO: Initializing Coyote AJP/1.3 on ajp-8009
          Jun 10, 2010 6:54:52 PM org.apache.coyote.ajp.AjpAprProtocol start
          INFO: Starting Coyote AJP/1.3 on ajp-8009
          Jun 10, 2010 6:54:52 PM org.apache.catalina.startup.Catalina start
          INFO: Server startup in 1178 ms
          Jun 10, 2010 6:55:00 PM org.apache.catalina.core.ApplicationContext log
          INFO: HTMLManager: init: Associated with Deployer 'Catalina:type=Deployer,host=localhost'
          Jun 10, 2010 6:55:00 PM org.apache.catalina.core.ApplicationContext log
          INFO: HTMLManager: init: Global resources are available
          Jun 10, 2010 6:55:00 PM org.apache.catalina.core.ApplicationContext log
          INFO: HTMLManager: list: Listing contexts for virtual host 'localhost'
          Jun 10, 2010 6:55:35 PM org.apache.coyote.http11.Http11AprProtocol pause
          INFO: Pausing Coyote HTTP/1.1 on http-8080
          Jun 10, 2010 6:55:35 PM org.apache.coyote.ajp.AjpAprProtocol pause
          INFO: Pausing Coyote AJP/1.3 on ajp-8009
          Jun 10, 2010 6:55:36 PM org.apache.catalina.core.StandardService stopInternal
          INFO: Stopping service Catalina
          Jun 10, 2010 6:55:36 PM org.apache.coyote.http11.Http11AprProtocol destroy
          INFO: Stopping Coyote HTTP/1.1 on http-8080
          Jun 10, 2010 6:55:36 PM org.apache.coyote.ajp.AjpAprProtocol destroy
          INFO: Stopping Coyote AJP/1.3 on ajp-8009
          
          localhost_access_log.2010-06-10.txt
          127.0.0.1 - z [10/Jun/2010:18:55:00 +0100] "GET /manager/html/ HTTP/1.1" 200 11308
          127.0.0.1 - - [10/Jun/2010:18:55:30 +0100] "GET /hudson HTTP/1.1" 302 -
          127.0.0.1 - - [10/Jun/2010:18:55:30 +0100] "GET /hudson/ HTTP/1.1" 404 982
          
          Show
          pzz pzz added a comment - One new important observation: In fact hudson starts. For example it creates files and directories in its homedir. I'm just unable to open its web interface (HTTP 404 NOT FOUND). Jieryn, thank you for advice. I'v set log level to ALL, there are tomcat logs: catalina.out hudson home directory: / var /lib/hudson catalina.err Jun 10, 2010 6:54:51 PM org.apache.catalina.core.AprLifecycleListener init INFO: Loaded APR based Apache Tomcat Native library 1.1.20. Jun 10, 2010 6:54:51 PM org.apache.catalina.core.AprLifecycleListener init INFO: APR capabilities: IPv6 [ true ], sendfile [ true ], accept filters [ false ], random [ true ]. Jun 10, 2010 6:54:51 PM org.apache.catalina.startup.Catalina load INFO: Initialization processed in 627 ms Jun 10, 2010 6:54:51 PM org.apache.catalina.core.StandardService startInternal INFO: Starting service Catalina Jun 10, 2010 6:54:51 PM org.apache.catalina.core.StandardEngine startInternal INFO: Starting Servlet Engine: Apache Tomcat/7.0.0-RC4 Jun 10, 2010 6:54:51 PM org.apache.catalina.startup.HostConfig deployDescriptor INFO: Deploying configuration descriptor manager.xml from / var /lib/tomcat/conf/Catalina/localhost Jun 10, 2010 6:54:51 PM org.apache.catalina.startup.HostConfig deployDescriptor INFO: Deploying configuration descriptor hudson.xml from / var /lib/tomcat/conf/Catalina/localhost Jun 10, 2010 6:54:52 PM org.apache.catalina.startup.HostConfig deployDescriptor INFO: Deploying configuration descriptor ROOT.xml from / var /lib/tomcat/conf/Catalina/localhost Jun 10, 2010 6:54:52 PM org.apache.coyote.http11.Http11AprProtocol init INFO: Initializing Coyote HTTP/1.1 on http-8080 Jun 10, 2010 6:54:52 PM org.apache.coyote.http11.Http11AprProtocol start INFO: Starting Coyote HTTP/1.1 on http-8080 Jun 10, 2010 6:54:52 PM org.apache.coyote.ajp.AjpAprProtocol init INFO: Initializing Coyote AJP/1.3 on ajp-8009 Jun 10, 2010 6:54:52 PM org.apache.coyote.ajp.AjpAprProtocol start INFO: Starting Coyote AJP/1.3 on ajp-8009 Jun 10, 2010 6:54:52 PM org.apache.catalina.startup.Catalina start INFO: Server startup in 1178 ms Jun 10, 2010 6:55:00 PM org.apache.catalina.core.ApplicationContext log INFO: HTMLManager: init: Associated with Deployer 'Catalina:type=Deployer,host=localhost' Jun 10, 2010 6:55:00 PM org.apache.catalina.core.ApplicationContext log INFO: HTMLManager: init: Global resources are available Jun 10, 2010 6:55:00 PM org.apache.catalina.core.ApplicationContext log INFO: HTMLManager: list: Listing contexts for virtual host 'localhost' Jun 10, 2010 6:55:35 PM org.apache.coyote.http11.Http11AprProtocol pause INFO: Pausing Coyote HTTP/1.1 on http-8080 Jun 10, 2010 6:55:35 PM org.apache.coyote.ajp.AjpAprProtocol pause INFO: Pausing Coyote AJP/1.3 on ajp-8009 Jun 10, 2010 6:55:36 PM org.apache.catalina.core.StandardService stopInternal INFO: Stopping service Catalina Jun 10, 2010 6:55:36 PM org.apache.coyote.http11.Http11AprProtocol destroy INFO: Stopping Coyote HTTP/1.1 on http-8080 Jun 10, 2010 6:55:36 PM org.apache.coyote.ajp.AjpAprProtocol destroy INFO: Stopping Coyote AJP/1.3 on ajp-8009 localhost_access_log.2010-06-10.txt 127.0.0.1 - z [10/Jun/2010:18:55:00 +0100] "GET /manager/html/ HTTP/1.1" 200 11308 127.0.0.1 - - [10/Jun/2010:18:55:30 +0100] "GET /hudson HTTP/1.1" 302 - 127.0.0.1 - - [10/Jun/2010:18:55:30 +0100] "GET /hudson/ HTTP/1.1" 404 982
          Hide
          jieryn jieryn added a comment -

          I gave this a try on Tomcat-7.0-RC4 and it seems that something strange is going on with the main welcome page. I can access other pages in Hudson just fine, e.g. http://localhost:8080/hudson/manage but the root welcome page is not loading. I looked back through a few versions previous to 1.361 and none of them define a welcome page..

          Also, this exact version, 1.361, works fine on Tomcat-6.0.18. Someone more familiar with Hudson's crazy bootstrapping is going to need to get involved.

          Show
          jieryn jieryn added a comment - I gave this a try on Tomcat-7.0-RC4 and it seems that something strange is going on with the main welcome page. I can access other pages in Hudson just fine, e.g. http://localhost:8080/hudson/manage but the root welcome page is not loading. I looked back through a few versions previous to 1.361 and none of them define a welcome page.. Also, this exact version, 1.361, works fine on Tomcat-6.0.18. Someone more familiar with Hudson's crazy bootstrapping is going to need to get involved.
          Hide
          mindless Alan Harder added a comment -

          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..

          Show
          mindless Alan Harder added a comment - 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..
          Hide
          jieryn jieryn added a comment -

          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.

          Show
          jieryn jieryn added a comment - 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.
          Hide
          kohsuke Kohsuke Kawaguchi added a comment -

          According to the servlet 2.5 spec section SRV.11.2,

          • A string containing only the '/' character indicates the "default" servlet of the application. In this case the servlet path is the request URI minus the context path and the path info is null.

          So I claim that '/' is valid according to the servlet spec.

          Show
          kohsuke Kohsuke Kawaguchi added a comment - According to the servlet 2.5 spec section SRV.11.2, A string containing only the '/' character indicates the "default" servlet of the application. In this case the servlet path is the request URI minus the context path and the path info is null. So I claim that '/' is valid according to the servlet spec.
          Hide
          pzz pzz added a comment -

          I have also reported it in tomcat bugzilla, see https://issues.apache.org/bugzilla/show_bug.cgi?id=49422

          Show
          pzz pzz added a comment - I have also reported it in tomcat bugzilla, see https://issues.apache.org/bugzilla/show_bug.cgi?id=49422
          Hide
          mindless Alan Harder added a comment -

          Per Kohsuke's comment above, "/" is valid per the servlet spec. We hope that Tomcat 7 will fix this prior to their next beta/final release (or we'll surely hear about this again!)

          Show
          mindless Alan Harder added a comment - Per Kohsuke's comment above, "/" is valid per the servlet spec. We hope that Tomcat 7 will fix this prior to their next beta/final release (or we'll surely hear about this again!)
          mindless Alan Harder made changes -
          Field Original Value New Value
          Status Open [ 1 ] Resolved [ 5 ]
          Resolution Won't Fix [ 2 ]
          Hide
          jieryn jieryn added a comment -

          Tomcat closed that issue as INVALID, they believe they are strictly adhering to the specification. Specification debates aside, is there some reason we can not just migrate to /* ? I tested this in Tomcat 7 and it works properly, but did not check embedded Winstone, or any other popular containers.

          Tomcat 7 has some unusual naming conventions for its releases, but they just announced a 7.0-BETA. The release manager stated that he'd like to get the first stable release out in 4 weeks or less. http://www.tomcatexpert.com/blog/2010/06/29/apache-tomcat-7-has-been-released

          So I expect we're going to see a lot more Hudson users deploying to Tomcat 7 soonish... It would be nice if we didn't have to answer mailing list messages or spurious bug reports about Hudson not working.

          Show
          jieryn jieryn added a comment - Tomcat closed that issue as INVALID, they believe they are strictly adhering to the specification. Specification debates aside, is there some reason we can not just migrate to /* ? I tested this in Tomcat 7 and it works properly, but did not check embedded Winstone, or any other popular containers. Tomcat 7 has some unusual naming conventions for its releases, but they just announced a 7.0-BETA. The release manager stated that he'd like to get the first stable release out in 4 weeks or less. http://www.tomcatexpert.com/blog/2010/06/29/apache-tomcat-7-has-been-released So I expect we're going to see a lot more Hudson users deploying to Tomcat 7 soonish... It would be nice if we didn't have to answer mailing list messages or spurious bug reports about Hudson not working.
          Hide
          jieryn jieryn added a comment -

          See comment above.

          Show
          jieryn jieryn added a comment - See comment above.
          jieryn jieryn made changes -
          Resolution Won't Fix [ 2 ]
          Status Resolved [ 5 ] Reopened [ 4 ]
          mindless Alan Harder made changes -
          Assignee kohsuke [ kohsuke ]
          Hide
          kohsuke Kohsuke Kawaguchi added a comment -

          I still don't agree that this is our fault, and I've updated https://issues.apache.org/bugzilla/show_bug.cgi?id=49422 accordingly.

          But in the mean time, I guess it'd wise to work around this issue in Hudson.

          I'll try the "empty welcome file list" approach that Mark suggested to see if that does the trick, as that seems least likely to cause regressions with other containers.

          Show
          kohsuke Kohsuke Kawaguchi added a comment - I still don't agree that this is our fault, and I've updated https://issues.apache.org/bugzilla/show_bug.cgi?id=49422 accordingly. But in the mean time, I guess it'd wise to work around this issue in Hudson. I'll try the "empty welcome file list" approach that Mark suggested to see if that does the trick, as that seems least likely to cause regressions with other containers.
          Hide
          kohsuke Kohsuke Kawaguchi added a comment -

          Empty welcome file list didn't work. Apparently the default web.xml in Tomcat also must have no welcome file list.

          Show
          kohsuke Kohsuke Kawaguchi added a comment - Empty welcome file list didn't work. Apparently the default web.xml in Tomcat also must have no welcome file list.
          Hide
          scm_issue_link SCM/JIRA link daemon added a comment -

          Code changed in hudson
          User: : kohsuke
          Path:
          trunk/hudson/main/war/resources/WEB-INF/web.xml
          trunk/www/changelog.html
          http://jenkins-ci.org/commit/33149
          Log:
          [FIXED JENKINS-6738] changed the servlet mapping to /* to make it work with Tomcat. My fingers are crossed that this doesn't cause regressions elsewhere.

          Show
          scm_issue_link SCM/JIRA link daemon added a comment - Code changed in hudson User: : kohsuke Path: trunk/hudson/main/war/resources/WEB-INF/web.xml trunk/www/changelog.html http://jenkins-ci.org/commit/33149 Log: [FIXED JENKINS-6738] changed the servlet mapping to /* to make it work with Tomcat. My fingers are crossed that this doesn't cause regressions elsewhere.
          scm_issue_link SCM/JIRA link daemon made changes -
          Status Reopened [ 4 ] Resolved [ 5 ]
          Resolution Fixed [ 1 ]
          jglick Jesse Glick made changes -
          Link This issue depends on JENKINS-7100 [ JENKINS-7100 ]
          Hide
          rdesgroppes Régis Desgroppes added a comment - - edited

          Using a proxied Winstone with Security Realm set to "Delegate to servlet container", I had to restore:

          <servlet-mapping>
            <servlet-name>Stapler</servlet-name>
            <url-pattern>/</url-pattern>
          </servlet-mapping>
          

          ... otherwise (with /*) hudson.security.BasicAuthenticationFilter::doFilter() works with an empty path, with the effect that my browser faces a infinite redirect loop.

          This is no surprise, according to javax.servlet.http.HttpServletRequest::getServletPath():

              Returns:
                  a String containing the name or path of the servlet being called, as specified in the request URL, decoded, or an empty string if the servlet used to process the request is matched using the "/*" pattern.
          

          Interestingly, I'm referring to Tomcat 7 hosted Servlet documentation: http://tomcat.apache.org/tomcat-7.0-doc/servletapi/javax/servlet/http/HttpServletRequest.html#getServletPath%28%29

          In my opinion, the workaround should be reverted since it comes from a misinterpretation.

          Show
          rdesgroppes Régis Desgroppes added a comment - - edited Using a proxied Winstone with Security Realm set to "Delegate to servlet container", I had to restore: <servlet-mapping> <servlet-name> Stapler </servlet-name> <url-pattern> / </url-pattern> </servlet-mapping> ... otherwise (with /*) hudson.security.BasicAuthenticationFilter::doFilter() works with an empty path, with the effect that my browser faces a infinite redirect loop. This is no surprise, according to javax.servlet.http.HttpServletRequest::getServletPath(): Returns: a String containing the name or path of the servlet being called, as specified in the request URL, decoded, or an empty string if the servlet used to process the request is matched using the "/*" pattern. Interestingly, I'm referring to Tomcat 7 hosted Servlet documentation: http://tomcat.apache.org/tomcat-7.0-doc/servletapi/javax/servlet/http/HttpServletRequest.html#getServletPath%28%29 In my opinion, the workaround should be reverted since it comes from a misinterpretation.
          rdesgroppes Régis Desgroppes made changes -
          Link This issue is blocking JENKINS-7278 [ JENKINS-7278 ]
          abayer abayer made changes -
          Status Resolved [ 5 ] Closed [ 6 ]

            People

            • Assignee:
              kohsuke Kohsuke Kawaguchi
              Reporter:
              pzz pzz
            • Votes:
              2 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: