java.lang.NullPointerException

Atlassian JIRA | Scott Farquhar [Atlassian] | 1 decade ago
  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
  3. 0

    Android: Saving Map State in Google map

    Stack Overflow | 11 months ago | Junie Negentien
    java.lang.RuntimeException: Unable to resume activity {com.ourThesis.junieNegentien2015/com.ourThesis.junieNegentien2015.MainActivity}: java.lang.NullPointerException
  4. Speed up your debug routine!

    Automated exception search integrated into your IDE

    Not finding the right solution?
    Take a tour to get the most out of Samebug.

    Tired of useless tips?

    Automated exception search integrated into your IDE

    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