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
    • Similar Issues:

      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.

        Attachments

          Issue Links

            Activity

            Hide
            jieryn jieryn added a comment -

            See comment above.

            Show
            jieryn jieryn added a comment - See comment above.
            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.
            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.

              People

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

                Dates

                • Created:
                  Updated:
                  Resolved: