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

NPE in WebSphere at start-up since v1.271

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Blocker
    • Resolution: Fixed
    • Component/s: _unsorted
    • Labels:
      None
    • Environment:
      Platform: All, OS: All
    • Similar Issues:

      Description

      v1.271 changes the security filter implementation in hudson. Unfortunately this
      causes NPE to be thrown at application start in WebSphere with the following
      stack trace:

      Failed to initialize Hudson
      java.lang.NullPointerException
      at hudson.model.Hudson.setSecurityRealm(Hudson.java:1333)
      at hudson.model.Hudson.load(Hudson.java:1696)
      at hudson.model.Hudson.<init>(Hudson.java:446)

      at hudson.WebAppMain$2.run(WebAppMain.java:160)

      The NPE is caused because the instance of HudsonFilter is not available at the
      initializing time of Hudson instance in the servlet context. This is probably
      caused by the fact that WebSphere loads and initializes Filters at the first
      call to the filter mapped resources and not at the start-up of the application.
      The related code segments are:

      WebAppMain tries to init Hudson in separate thread:

      new Thread("hudson initialization thread") {
      public void run() {
      try {
      try

      { context.setAttribute(APP,new Hudson(home,context)); }

      catch( IOException e )

      { throw new Error(e); }

      initing new Hudson calls load(), which in turn tries to set the security realm
      to the proxy filter (in hudson.model.Hudson):

      public void setSecurityRealm(SecurityRealm securityRealm) {
      if(securityRealm==null)
      securityRealm= SecurityRealm.NO_AUTHENTICATION;
      this.securityRealm = securityRealm;
      // reset the filters and proxies for the new SecurityRealm
      try

      { HudsonFilter.get(servletContext).reset(securityRealm); }

      catch (ServletException e) {
      // for binary compatibility, this method cannot throw a checked
      exception
      throw new AcegiSecurityException("Failed to configure filter",e) {};
      }
      }

      HudsonFilter.get(context) tries to find its own instance saved at the init time
      in its init(FilterConfig) method into the servlet context and fails because the
      filter hasn't been initialized yet (in hudson.security.HudsonFilter):

      public void init(FilterConfig filterConfig) throws ServletException

      { this.filterConfig = filterConfig; // this is how we make us available to the rest of Hudson. filterConfig.getServletContext().setAttribute(HudsonFilter.class.getName(),this); }

      /**

      • Gets the {@link HudsonFilter}

        created for the given

        {@link ServletContext}

        .
        */
        public static HudsonFilter get(ServletContext context)

        { return (HudsonFilter)context.getAttribute(HudsonFilter.class.getName()); }

      IMHO the implementation here relays upon the availability of the servlet filters
      at application start-up time, but this is container specific implementation,
      because the servlet specification does not define exactly at what time the
      container should load and initialize a filter, but only that this must be done
      prior to first call to mapped resource for this filter. Because of this I can't
      consider this as a WebSphere incompatibility.

        Attachments

          Activity

          Hide
          ilkomiliev ilkomiliev added a comment -

          Can someone please take the responsibility to commit this changes please! It has been a week since
          this is pending here. Thanks!

          Show
          ilkomiliev ilkomiliev added a comment - Can someone please take the responsibility to commit this changes please! It has been a week since this is pending here. Thanks!
          Hide
          rseguy Romain Seguy added a comment -

          Created an attachment (id=587)
          Patch updated as of 03/03/2009 to fit the latest Hudson version

          Show
          rseguy Romain Seguy added a comment - Created an attachment (id=587) Patch updated as of 03/03/2009 to fit the latest Hudson version
          Hide
          evantd evantd added a comment -

          I'm seeing this with Jetty as well, and the attached patch fixes it for me.

          Show
          evantd evantd added a comment - I'm seeing this with Jetty as well, and the attached patch fixes it for me.
          Hide
          scm_issue_link SCM/JIRA link daemon added a comment -

          Code changed in hudson
          User: : kohsuke
          Path:
          trunk/hudson/main/core/src/main/java/hudson/model/Descriptor.java
          trunk/hudson/main/core/src/main/java/hudson/model/Hudson.java
          trunk/hudson/main/core/src/main/java/hudson/security/ChainedServletFilter.java
          trunk/hudson/main/core/src/main/java/hudson/security/HudsonFilter.java
          trunk/hudson/main/core/src/main/java/hudson/security/SecurityRealm.java
          trunk/www/changelog.html
          http://fisheye4.cenqua.com/changelog/hudson/?cs=16150
          Log:
          [FIXED JENKINS-3069]
          Fixed the initialization order issue.

          Show
          scm_issue_link SCM/JIRA link daemon added a comment - Code changed in hudson User: : kohsuke Path: trunk/hudson/main/core/src/main/java/hudson/model/Descriptor.java trunk/hudson/main/core/src/main/java/hudson/model/Hudson.java trunk/hudson/main/core/src/main/java/hudson/security/ChainedServletFilter.java trunk/hudson/main/core/src/main/java/hudson/security/HudsonFilter.java trunk/hudson/main/core/src/main/java/hudson/security/SecurityRealm.java trunk/www/changelog.html http://fisheye4.cenqua.com/changelog/hudson/?cs=16150 Log: [FIXED JENKINS-3069] Fixed the initialization order issue.
          Hide
          rseguy Romain Seguy added a comment -

          Verified with 1.191 on WAS 7.0.0.1 ND. Works fine. Thanks.

          Show
          rseguy Romain Seguy added a comment - Verified with 1.191 on WAS 7.0.0.1 ND. Works fine. Thanks.

            People

            • Assignee:
              Unassigned
              Reporter:
              ilkomiliev ilkomiliev
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: