java.lang.NullPointerException

Atlassian JIRA | Scott Farquhar [Atlassian] | 1 decade ago
tip
Your exception is missing from the Samebug knowledge base.
Here are the best solutions we found on the Internet.
Click on the to mark the helpful solution and get rewards for you help.
  1. 0

    Ok - here's the problem: {code} java.lang.NullPointerException at com.caucho.server.http.DispatchRequest.getContextPath(DispatchRequest.java:173) at com.atlassian.jira.plugin.JiraResourcedModuleDescriptor.getDefaultVelocityParams(JiraResourcedModuleDescriptor.java:217) at com.atlassian.jira.web.component.issuesummary.IssueSummaryWebComponent.getDefaultParams(IssueSummaryWebComponent.java:71) at com.atlassian.jira.web.component.issuesummary.IssueSummaryWebComponent.getHtml(IssueSummaryWebComponent.java:66) at _decorators._issuesummary__jsp._jspService(_issuesummary__jsp.java:1583) {code} In Resin, it uses a new request for each 'include' that it does. JSP include, using a requestwrapper etc. In JIRA's ServletRequestDispatcher (webwork implementation), we capture the Request in a Thread Local, and use it later on in the request. We also do the same with the action context. After each request has completed, it gets returned to the pool, and all of its internal state cleared. The problem that has been introduced with the new decorator is that in the decorator gets the request out of the Thread Local (ActionContext.getRequest()): {{JiraResourcedModuleDescriptor.getDefaultVelocityParams()}}. However, as this request has been released back into the pool, the request.getContextPath() has been cleared, which throws the NullPointerException. The solution is for our templates to not depend on the HttpServletRequest object, but instead see what we use from it, and provide that to the velocity context instead. A quick search shows that the request object isn't used in that many places (at least inside JIRA): {code} for i in `find . -name *.vm` ; do grep "\$req" $i | grep -v "\$req.getContextPath()" | grep -v "\$req.contextPath" ; done; {code} Mostly we just use the contextPath, and we could find a better variable name for that.

    Atlassian JIRA | 1 decade ago | Scott Farquhar [Atlassian]
    java.lang.NullPointerException
  2. 0

    Ok - here's the problem: {code} java.lang.NullPointerException at com.caucho.server.http.DispatchRequest.getContextPath(DispatchRequest.java:173) at com.atlassian.jira.plugin.JiraResourcedModuleDescriptor.getDefaultVelocityParams(JiraResourcedModuleDescriptor.java:217) at com.atlassian.jira.web.component.issuesummary.IssueSummaryWebComponent.getDefaultParams(IssueSummaryWebComponent.java:71) at com.atlassian.jira.web.component.issuesummary.IssueSummaryWebComponent.getHtml(IssueSummaryWebComponent.java:66) at _decorators._issuesummary__jsp._jspService(_issuesummary__jsp.java:1583) {code} In Resin, it uses a new request for each 'include' that it does. JSP include, using a requestwrapper etc. In JIRA's ServletRequestDispatcher (webwork implementation), we capture the Request in a Thread Local, and use it later on in the request. We also do the same with the action context. After each request has completed, it gets returned to the pool, and all of its internal state cleared. The problem that has been introduced with the new decorator is that in the decorator gets the request out of the Thread Local (ActionContext.getRequest()): {{JiraResourcedModuleDescriptor.getDefaultVelocityParams()}}. However, as this request has been released back into the pool, the request.getContextPath() has been cleared, which throws the NullPointerException. The solution is for our templates to not depend on the HttpServletRequest object, but instead see what we use from it, and provide that to the velocity context instead. A quick search shows that the request object isn't used in that many places (at least inside JIRA): {code} for i in `find . -name *.vm` ; do grep "\$req" $i | grep -v "\$req.getContextPath()" | grep -v "\$req.contextPath" ; done; {code} Mostly we just use the contextPath, and we could find a better variable name for that.

    Atlassian JIRA | 1 decade ago | Scott Farquhar [Atlassian]
    java.lang.NullPointerException

    Root Cause Analysis

    1. java.lang.NullPointerException

      No message provided

      at com.caucho.server.http.DispatchRequest.getContextPath()
    2. com.caucho.server
      DispatchRequest.getContextPath
      1. com.caucho.server.http.DispatchRequest.getContextPath(DispatchRequest.java:173)
      1 frame
    3. com.atlassian.jira
      IssueSummaryWebComponent.getHtml
      1. com.atlassian.jira.plugin.JiraResourcedModuleDescriptor.getDefaultVelocityParams(JiraResourcedModuleDescriptor.java:217)
      2. com.atlassian.jira.web.component.issuesummary.IssueSummaryWebComponent.getDefaultParams(IssueSummaryWebComponent.java:71)
      3. com.atlassian.jira.web.component.issuesummary.IssueSummaryWebComponent.getHtml(IssueSummaryWebComponent.java:66)
      3 frames
    4. _decorators
      _issuesummary__jsp._jspService
      1. _decorators._issuesummary__jsp._jspService(_issuesummary__jsp.java:1583)
      1 frame