Thursday, 1 September 2011

Unable to View Dashboard 'UrlPortMismatchException' Due to Apache Tomcat Connector

Symptoms

Users trying to access the dashboard will encounter a System Error page containing an exception like the following:
com.atlassian.gadgets.dashboard.internal.diagnostics.UrlPortMismatchException: Detected URL port, 'XXXX', does not match expected port, '80'
at com.atlassian.gadgets.dashboard.internal.diagnostics.Diagnostics.checkExpectedPort(Diagnostics.java:81)
at com.atlassian.gadgets.dashboard.internal.diagnostics.Diagnostics.check(Diagnostics.java:32)
at com.atlassian.gadgets.dashboard.internal.diagnostics.DiagnosticsServlet.executeDiagnostics(DiagnosticsServlet.java:92)
at com.atlassian.gadgets.dashboard.internal.diagnostics.DiagnosticsServlet.doPost(DiagnosticsServlet.java:61)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
...

Cause

The most common cause of this is the use of a reverse-proxy HTTP server (often Apache or IIS) in front of the application server running JIRA. The front-end proxy is misdirecting traffic to the wrong port.

Resolution

Append proxyName="mycompany.com" and proxyPort="80" to your Tomcat connector (located in conf/server.xml). For example:
<Connector port="XXXX"
      ...........
      proxyName="mycompany.com" proxyPort="80"/
      ...........
Read Full[..]

The Plugin 'Gadget Dashboard' is not available

Symptoms

Viewing the dashboard fails with this message The Plugin 'Gadget Dashboard' is not available.
From the log file, this stack trace is found:
...
2010-10-01 17:45:18,027 http-8080-Processor19 ERROR abc 63917x369x1 n32ntl http://localhost:8080/browse/ATL-950 [webwork.util.ValueStack\] query="/issueTabPanels" {[id="null" type="5" values=""\]} {[id="issueTabPanels" type="8" values=""\]}
java.lang.reflect.InvocationTargetException
&nbsp;&nbsp; &nbsp;at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
...
at org.apache.jsp.includes.panels.issue.actions_jsp._jspService(actions_jsp.java:93)
...
2010-10-01 18:13:47,445 http-8080-Processor15 ERROR abc 65627x561x1 1bs13dg http://localhost:8080/secure/ViewProfile.jspa [webwork.util.ValueStack\] query="/selectedTab" {[id="null" type="5" values=""\]} {[id="selectedTab" type="8" values=""\]}
 
java.lang.reflect.InvocationTargetException
...
Caused by: com.atlassian.util.concurrent.LazyReference$InitializationException: java.lang.IllegalStateException: Cannot autowire object because the Spring context is unavailable.&nbsp; Ensure your OSGi bundle contains the 'Spring-Context' header.
&nbsp;&nbsp; &nbsp;at com.atlassian.util.concurrent.LazyReference.getInterruptibly(LazyReference.java:152)
...

Cause

The web application server's work directory (e.g. Tomcat's work directory) contains outdated files or may have been corrupted.

Resolution

  1. Delete the <JIRA_HOME|CATALINA_BASE>/work folder.
  2. Verify the user running the JIRA application process has Read/Write permission to the <JIRA_HOME|CATALINA_BASE>/work directory.
  3. Restart the JIRA application container to rebuild the files.
Read Full[..]

Open Issues and statistic Bar are Missing in the 'Project Gadget' Detailed View

Symptoms

In the Projects Gadget's Detailed view, some projects doesn't show neither the open issues nor the issue's priority statistic bar:


Cause

The Priority field is being hidden in one of the field configuration used in its Field Configuration Scheme.

Resolution

Make sure Priority field is not being hidden by checking the affected project's Field Configuration Scheme and issue type's field configurations that associated.
Read Full[..]

OAuth after Initial Configuration Does Not Work

Symptoms

While requesting content such as gadgets to be served over OAuth similar warnings are recoded in atlassian-jira.log log file:
2010-09-02 09:21:30,434 http-8081-2 WARN jbond 561x2193x6 h5pd0p  /plugins/servlet/gadgets/makeRequest [http.impl.client.DefaultRequestDirector]  Authentication error: Unable to respond to any of these challenges: {oauth=WWW-Authenticate: OAuth realm="http%3A%2F%2Fbamboo", oauth_problem="token_rejected"}
2010-09-02 09:21:30,742 http-8081-8 WARN jbond 561x2196x6 h5pd0p  /plugins/servlet/gadgets/makeRequest [http.impl.client.DefaultRequestDirector] Authentication error: Unable to respond to any of these challenges: {oauth=WWW-Authenticate: OAuth realm="http%3A%2F%2Fbamboo", oauth_problem="token_rejected"}

Cause

OAuth provider doesn't recognise the consumer as the valid and authorised consumer of its service. In most cases problem observed, if the consumer application is hosted behind Apache HTTPD.

Resolution

Ensure that the front-end Apache HTTPD is configured with the ProxyPreserveHost directive set to ON
Read Full[..]

Non-ASCII Characters in Charts and Graphs are not Displayed Correctly

Symptoms

None ASCII (latin) characters are not being displayed or are replaced with squares.


Cause

The chart is generated on the JIRA server side. To generate this image, the JVM uses fonts that are configured with (supplied by OS).

Resolution

The JVM needs to be configured with fonts location. For more information regarding this configuration option refer to Font Configuration Files.
Read Full[..]

JIRA Throws IllegalArgumentException when using Activity Stream Gadget

Symptoms

When viewing the activity stream gadget in a source outside JIRA (such as FishEye), JIRA logs the following exception:
2010-03-22 11:27:56,345 http-8180-Processor21 ERROR whitmore 41276x216x1 ntz3oe /plugins/servlet/streams [atlassian.streams.servlet.StreamsActivityServlet] Error getting activity
java.lang.IllegalArgumentException: The Project argument and its backing generic value must not be null
at com.atlassian.jira.security.AbstractPermissionManager.hasPermission(AbstractPermissionManager.java:171)
at com.atlassian.jira.security.AbstractPermissionManager.hasPermission(AbstractPermissionManager.java:159)
at sun.reflect.GeneratedMethodAccessor103.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.atlassian.util.profiling.object.ObjectProfiler.profiledInvoke(ObjectProfiler.java:70)
at com.atlassian.jira.config.component.SwitchingInvocationHandler.invoke(SwitchingInvocationHandler.java:28)
at $Proxy40.hasPermission(Unknown Source)
at sun.reflect.GeneratedMethodAccessor103.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.atlassian.plugin.osgi.hostcomponents.impl.DefaultComponentRegistrar$ContextClassLoaderSettingInvocationHandler.invoke(DefaultComponentRegistrar.java:129)

Cause

Apache Web Proxy is interfering with the project name when configured incorrectly.

Workaround

Remove the Apache Proxy between FishEye (or the product housing the JIRA activity stream) and JIRA.

Resolution

Atlassian is still investigating the exact configuration that's responsible for this problem. Please comment on this article if you discover any specifics.
Read Full[..]

JIRA Dashboard is Rendering Slowly on JIRA 4.x

Symptoms

Users are experiencing slow dashboard loading when using JIRA 4.0 or higher.

Cause

JIRA 4.x dashboards use Opensocial gadgets. Gadgets are using a lot more JavaScript and AJAX. This has two repercussions:
  1. AJAX means more network activity.
  2. More JavaScript means browsers with poor JavaScript performance are more impacted. The performance of JavaScript varies dramatically from browser to browser, with some being tens or even hundreds of times faster than others
If your dashboards are taking a long time to load, its more likely that this is caused due to poor browser performance or slow network.

Diagnosis

To diagnose if the problem is on the server or the client,
Enable JIRA Profiling. Check how long it takes JIRA to load the dashboard. This is what a normal dashboard page request looks like:
2010-03-15 21:25:18,959 TP-Processor35 DEBUG WS8099 77073x34577x1 USER jira/secure/Dashboard.jspa
[atlassian.util.profiling.UtilTimerStack] [990ms] \- /jira/secure/Dashboard.jspa
As opposed to a slow server request:
2010-03-15 21:25:18,959 TP-Processor35 DEBUG WS8099 77073x34577x1 USER /jira/secure/Dashboard.jspa
[atlassian.util.profiling.UtilTimerStack] [45103ms] \- /jira/secure/Dashboard.jspa

Workaround

Slow Server Request
If, from the above diagnostics, you notice the Dashboard.jspa taking a long time, see Crashes and Performance Issues Troubleshooting. This is a sign of a more general performance problem.
Slow Client Rendering
If, from the above diagnostics, the client is taking a long time:
  1. Ensure that you are on the latest browser. Avoid IE6 and old browsers.
  2. Try using different browsers such as FireFox 4 or Chrome.

Resolution

Please track JRA-19511 for a permanent solution.
Read Full[..]

Gadgets do not Display when Failing to Access XML Specification

Symptom

When integrating JIRA 4.x with a proxy server, the Dashboard Gadget can't be dsiplayed with the below exception thrown in Gadget:
org.apache.shinding.gadgets.GadgetException: Unable to retrieve gadget xml. HTTP error 500.

Cause

JIRA 4.0 Gadget applies the extensible REST Plugin Module framework, which provides access to resources via URI paths. The JIRA self-generated outgoing url fails to access the requested spec XML. This failure can be caused by:
  • A loop-back bug of JIRA 4.0. See Gadgets do not display correctly after upgrade to JIRA 4.0
  • A firewall restriction for JIRA self-generated outgoing request
  • A mismatched domain and port in JIRA self-generated outgoing request
  • A mismatched request scheme in JIRA self-generated outgoing request
  • A URL domain of JIRA self-generated outgoing request can't be detected in JIRA

Resolution

  1. If you're using JIRA 4.0, please upgrade to the version above JIRA 4.0.1 or later, which includes the fix for proxy loop-back bug
  2. If there's a firewall between the proxy and JIRA's application server which has a restriction, remove that restriction.
  3. Edit <JIRA_Installation_Home>/conf/server.xml (Standalone), or <Catalina_Home>/conf/server.xml for Ear-War deployment. Specify scheme/proxyName/proxyPort attributes in JIRA Connector, e.g.
    <Connector port="8080"
      ...
      scheme="your_request_scheme"
      proxyName="your_proxy_name"
      proxyPort="your_proxy_port"
    />
    notes: scheme should be either http or https, which's consistent with the request scheme used to access proxy (instead of JIRA application server).
  4. test if domain name of proxy server can be detected on JIRA application server; for example
    wget https://support.atlassian.com:443/rest/gadgets/1.0/g/com.atlassian.jira.gadgets:assigned-to-me-gadget/gadgets/assigned-to-me-gadget.xml
    If the proxy's domain can't be detected on JIRA application server, adjust the hosts file or DNS to fix it.
Read Full[..]

Gadgets do not Display with the 'Http status 404' Error

Symptom

After upgrading to JIRA 4.*, the gadget can't be displayed in Dashboard with the below exception shown in Gadgets on Dashboard:
Http status 404 - /plugins/servlet/gadgets/ifr

Cause

As one of reasons, we found this problem is caused by the incorrect JIRA home setting, and typically when JIRA home is set as same as "appBase" of Tomcat Host.

Resolution

  1. Shutdown JIRA
  2. Follow Setting your JIRA Home Directory to change the JIRA Home Directory. The JIRA Home directory should be different than the installation directory, or where the webapp is deployed.
  3. Restart JIRA
Read Full[..]

Gadgets do not Display Correctly when Using SSL and Proxy Server

Symptoms

After upgrading to JIRA 4.0.1 or later, gadgets may not render over https://www.mycompany.com/jira or https://jira.mycompany.com, but work fine over http.
You may see errors in the logs similar to this:
2010-02-12 13:12:25,881 http-17000-3 ERROR anonymous 47545x3x1 asaintprix /plugins/servlet/gadgets/dashboard-diagnostics [dashboard.internal.diagnostics.DiagnosticsServlet] DIAGNOSTICS: FAILED
com.atlassian.gadgets.dashboard.internal.diagnostics.UrlSchemeMismatchException: Detected URL scheme, 'http', does not match expected scheme 'https'
    at com.atlassian.gadgets.dashboard.internal.diagnostics.Diagnostics.checkExpectedScheme(Diagnostics.java:58)
    at com.atlassian.gadgets.dashboard.internal.diagnostics.Diagnostics.check(Diagnostics.java:30)

Cause

JIRA sits behind a reverse proxy or load balancer and doesn't know the URL scheme, hostname or port to connect to Tomcat. Gadgets therefore cannot resolve their path.

Resolution

Note that an SSL connection between Apache and Tomcat is usually unnecessary. That is, the SSL connection can be terminated at Apache Web Server, and the connection to Tomcat can run over HTTP.
Make sure you have properly configured the Tomcat connector port attributes as described in Integrating JIRA with Apache using SSL or Integrating JIRA with Apache. Note that an SSL connection between Apache and Tomcat is usually unnecessary. If you choose this option, you should change the attribute in your Tomcat Connector in conf/server.xml (if using stand-alone) or jira.xml (if using EAR/WAR) from secure="true" to secure="false".

Standard Connector Port where Tomcat handles SSL encryption
Notice in this example which shows our default connector port information secure="true". This is used when Tomcat is handling traffic over https. If Tomcat is not handling encryption, you'll need secure="false" as shown above.
<Connector port="8443" maxHttpHeaderSize="8192"
maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
enableLookups="false" disableUploadTimeout="true" useBodyEncodingForURI="true"
acceptCount="100" scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS" />
Read Full[..]

Gadgets do not display correctly after upgrade to JIRA 4.0


This issue has been resolved in JIRA 4.0.1
Atlassian recommends upgrading to JIRA 4.0.1 or later. Refer to JIRA Dashboard and Gadgets Troubleshooting.
 Expand to see archived documentation for JIRA 4.0 only

Symptoms

The following errors may appear when using gadgets:
GadgetUrlBuilder: could not parse spec at rest/gadgets/1.0/g/com.atlassian.jira.gadgets:admin-gadget/gadgets/admin-gadget.xml
2009-10-07 21:44:25,201 http-9443-Processor23 ERROR anonymous 78259x3x3 17drnf0 https://www.example.com/secure/Dashboard.jspa [renderer.internal.http.HttpClientFetcher] Unable to retrieve response
org.apache.http.conn.ConnectTimeoutException: Connect to www.example.com/100.100.100.100:443 timed out

Cause

Before displaying a dashboard, JIRA will make http requests to retrieve all the gadget specs for that dashboard. If the URL of the gadget spec is an absolute URL this error message could be a normal occurrence because the gadget spec is simply not being hosted any longer.
However if the URL is a relative URL as in the error above, JIRA is having issues retrieving gadget specs it's hosting itself. Eventually JIRA will no longer retrieve gadget specs via a HTTP request back to itself and make an API call instead. This has not been implemented as of this writing.
The problem is caused if JIRA is setup behind a proxy (such as Apache) or if there are issues with SSL certificates. Here's a detailed list of all reported configurations that can cause this problem so far:
  1. JIRA sits behind a reverse proxy or load balancer and doesn't know the URL scheme, hostname or port that it's actually being accessed on.
  2. JIRA is running under SSL with a certificate that is self-signed or signed by a CA that is not in Java's cacerts file. You will probably see a message like javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated in your log file.
  3. Apache is mapping vhosts by IP address, and the hostname used in the URL resolves to a different IP on the server than it does in the rest of the network (e.g., because it's mapped to 127.0.0.1 in /etc/hosts). The symptom here is 404s coming from Apache and Tomcat not getting hit at all when requesting gadget specs.
  4. JIRA is setup with Apache enforcing access via basic auth. When JIRA makes a request for gadget specs via apache, the request fails with 401 since JIRA doesn't handle the basic auth challenge.
  5. The JIRA server is not able to communicate with itself using the host given in the request.
    1. A user has entered an entry in the hosts file on a different machine to the JIRA server for the server machine. When a request from this machine hits the server, the server wont know how to resolve the host used in the request.
    2. The host cannot communicate with itself using the IP resovled from the request (e.g. firewall or routing configuration).
  6. JIRA is setup behind a firewall that doesn't allow outgoing requests back to itself (Shindig requests to fetch gadget specs timeout).
  7. The Gliffy Plugin for JIRA version 2.1.0 is installed. This version contains classes that conflict with JIRA 4's dashboard. An updated version 2.1.1 is available for download from the Gliffy website.
Full Size
${macroBean.alt}

Resolution

If you are using Apache, please follow the documentation about setting up JIRA with Apache exactly:
Also ensure that outgoing requests are allowed by your firewall back to JIRA itself. If you're using iptables to redirect port 80 to 8080 then also ensure that you redirect any OUTGOING requests back to port 8080:
iptables -t nat -A OUTPUT -p tcp -d a.b.c.d --dport 80 -j DNAT --to a.b.c.d:8080
If you're suffering from the hosts file problem, make an entry in the JIRA server's hosts file for the hostname your JIRA instance is using.
The basic auth problem can be solved by not enforcing basic auth for requests from JIRA back to itself. E.g. all that needs to be excluded is calls to /jira/rest. This could perhaps be further limited to only exclude requests from the server's IP:
<Location "/jira/rest">
  Satisfy Any
  Order allow,deny
  Allow from all
</Location>
 
<Location "/jira">
  AuthName "Jira"
  AuthType Basic
  AuthUserFile /etc/apache2/passwords/passwords
  require valid-user
</Location>
If you are using SSL with a self signed certificate or signed by a CA that is not in Java's cacerts file you will need to import that certificate into the java trust store (cacerts file).
For a self signed certificate
  • export the certificate to a temporary location, for example
    keytool -exportcert -alias tomcat -file /home/user1/temp/tomcat.cert
  • import the certificate to the trust store
    sudo keytool -importcert -file /home/user1/temp/tomcat.cert -alias tomcat  -keystore $JAVA_HOME/jre/lib/security/cacerts
For a CA that is not in Java's cacerts file you need to import the CA's root certificate.
Download the Dashboard Diagnostic Plugin for more detailed logs and attach them to your JIRA case.
Read Full[..]

Deleting a JIRA Dashboard Redirects Users to the Login Screen

Symptoms

When you attempt to delete a dashboard (create or edit one as well) you are redirected to the login page.
No errors are logged in the atlassian-jira.log.

Cause

This is due to the user not having the a part of the 'Jira Users' global permission. For example, the user belongs to the 'jira-administrators' group and does not belong to the 'jira-users' group, and only the 'jira-users' group.

Resolution

Ensure that the user is a member of a group that has the "JIRA Users" global permission. See Managing Global Permissions.
Read Full[..]

JIRA Dashboard Fails to Display with Cannot Forward after Response has Been Committed Error

Symptoms

The follow error appears when displaying the dashboard:
java.lang.IllegalStateException: Cannot forward after response has been committed
       at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:312)
       at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:302)
       at com.atlassian.jira.web.dispatcher.JiraServletDispatcher.service(JiraServletDispatcher.java:251)
       at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)

Cause

This error usually starts appearing after JIRA has upgraded (especially in EAR/WAR instances), due to JIRA still referencing cached data in the old work directory. It is important to make sure that when uprading, JIRA is installed in a clean environment.

Resolution

  1. Stop JIRA
  2. Remove the work directory
    • JIRA standalone the work directory can be found in <install directory>/atlassian-jira-enterprise-4.1.2-standalone/work
    • EAR/WAR the work directory will be unique to your specific applications server.
  3. Restart JIRA.
JIRA will generate a new work directory upon startup. Make sure to set up a clean instance as outlined in Upgrading JIRA guide.
Read Full[..]

JIRA Dashboard Fails after Upgrading or Importing

Symptoms

After upgrading to a version of JIRA that's 4.0 or higher, users trying to access the dashboard encounter an error message like the following (which also appears in the logs):
...
java.lang.RuntimeException: java.lang.NullPointerException
at com.atlassian.jira.dashboard.permission.JiraGadgetPermissionManager.hasProjectsPermission(JiraGadgetPermissionManager.java:164)
at com.atlassian.jira.dashboard.permission.JiraGadgetPermissionManager.voteOn(JiraGadgetPermissionManager.java:147)
at com.atlassian.jira.dashboard.permission.JiraGadgetPermissionManager.filterGadgets(JiraGadgetPermissionManager.java:70)
at com.atlassian.jira.web.action.Dashboard.getCurrentDashboardState(Dashboard.java:182)
...

Diagnosis

Another way to know if you may be affected by this problem is to run the following query:
select count(*) from schemepermissions where perm_type in ('reportercreate','assigneeassignable');
If that query returns a number greater than zero, then you'll need to follow the instructions in the "Resolution" section of the document to avoid permission errors when running JIRA 4.0 or higher.

Cause

Before the upgrade or restore, JIRA was confiugured to allow either the Current Reporter Browse Project Permission or the similar permission that allows users to browse projects in which they're assigned issues. These two permission types are commented out by default since they can cause some fairly serious issues if used incorrectly.

Resolution

  1. Edit the permission-types.xml file which is located in <JIRA_install>/atlassian-jira/WEB-INF/classes/ directory and uncomment the following section:
    <!--  Uncomment & use this permission to show only projects where the user has create permission and issues within that where they are the reporter. -->
        <!--  This permission type should only ever be assigned to the "Browse Projects" permission. -->
        <!--  Other permissions can use the "reporter" or "create" permission type as appropriate. -->
        <!--
        <type id="reportercreate" enterprise="true">
            <class>com.atlassian.jira.security.type.CurrentReporterHasCreatePermission</class>
        </type>
        -->
         <!--  Uncomment & use this permission to show only projects where the user has the assi\
    gnable permission and issues within that where they are the assignee -->
         <!--  This permission type should only ever be assigned to the "Browse Projects" permis\
    sion. -->
         <!--  Other permissions can use the "reporter" or "create" permission type as appropria\
    te. -->
        <!--
         <type id="assigneeassignable" enterprise="true">
             <class>com.atlassian.jira.security.type.CurrentAssigneeHasAssignablePermission</cla\
    ss>
         </type>
        -->
    That portion of the file should look something like this after the modification:
    <!--  This permission type should only ever be assigned to the "Browse Projects" permission. -->
        <!--  Other permissions can use the "reporter" or "create" permission type as appropriate. -->
        <type id="reportercreate" enterprise="true">
            <class>com.atlassian.jira.security.type.CurrentReporterHasCreatePermission</class>
        </type>
         <!--  Uncomment & use this permission to show only projects where the user has the assi\
    gnable permission and issues within that where they are the assignee -->
         <!--  This permission type should only ever be assigned to the "Browse Projects" permis\
    sion. -->
         <!--  Other permissions can use the "reporter" or "create" permission type as appropria\
    te. -->
         <type id="assigneeassignable" enterprise="true">
             <class>com.atlassian.jira.security.type.CurrentAssigneeHasAssignablePermission</cla\
    ss>
         </type>
  2. Restart your JIRA instance before the change will take effect.
Read Full[..]

"The Gadget Dashboard bundled plugin is not available" Error When Accesing JIRA

Symptoms

The user logs in JIRA: suddenly an error exception is thrown on the screen. It says that the Gadget Dashboard plugin (the one responsible for load that user dashboard) is not available. Although you be able to see this plugin really disabled on administration section, it cannot be re-enabled because a non-specified web fragment is also disabled.
The following error is thrown in the screen:
ERROR
The Gadget Dashboard bundled plugin is not available. Please contact an administrator to ensure the Gadget Dashboard plugin is enabled!
 
Perhaps you need to log in to see the page.
If you think this message is wrong, please consult your administrators about getting the necessary permissions.

Cause

The Gadget Dashboard is a bundled plugin of JIRA and must keep up always enabled. The condition in which this won't occurs is when there is some data corruption under its respective folder ($JIRA_HOME/plugins/.osgi-plugins) as well as when a third-party plugin is disturbing the instance operation (not so usual).

Resolution

  1. Delete the directory $JIRA_HOME/plugins/.osgi-plugins and start JIRA up in order to it re-extract the plugins.
  2. If it doesn't work, disable all third party plugins and systematically re-enable these until you find the culprit.
Read Full[..]

'Internal Server Error java.lang.NoClassDefFoundError Could not initialize class org.jfree.chart.JFreeChart' when Viewing Chart Gadget

Symptoms

An Internal Server Error message appears in a chart-based gadget.
The following appears in the atlassian-jira.log:
SEVERE: Internal server error
java.lang.NoClassDefFoundError: Could not initialize class org.jfree.chart.JFreeChart
    at org.jfree.chart.ChartFactory.createStackedBarChart(ChartFactory.java:679)
    at com.atlassian.jira.charts.jfreechart.StackedBarChartGenerator.generateChart(StackedBarChartGenerator.java:48)
    at com.atlassian.jira.charts.RecentlyCreatedChart.generateChart(RecentlyCreatedChart.java:91)

Cause

Generally, a NoClassDefFoundError occurs when a plugin is compiled against a JIRA version, then deployed against a different JIRA version that lacks a specific class definition.
In some cases, the versions may be correct, and an environment classloading issue has caused the error.

Resolution

  1. Restart JIRA. This will correct the environmental class-loading issue.
  2. Check that the Charting Plugin is compatible with the installed version of JIRA.
Read Full[..]

'Gadgets not Rendering due to java.lang.NoClassDefFoundError com.atlassian.jira.portal.PortalPageImpl' Due to Incompatible Plugin

Symptoms

JIRA is unable to display a gadget and the following errors are thrown the logs:
2010-07-29 15:07:44,339 http-8082-11 ERROR hevans 907x327x2 12fy3le 94.193.81.193,127.0.0.1 /rest/gadget/1.0/issueTable/filter [atlassian.plugin.servlet.DefaultServletModuleManager] Unable to create filter
com.atlassian.plugin.servlet.util.LazyLoadedReference$InitializationException: java.lang.NoClassDefFoundError: com/atlassian/jira/portal/PortalPageImpl
    at com.atlassian.plugin.servlet.util.LazyLoadedReference.get(LazyLoadedReference.java:94)
    at com.atlassian.plugin.servlet.DefaultServletModuleManager.getFilter(DefaultServletModuleManager.java:321)
...

Cause

The gadget is referencing a third-party plugin, which is using the old com.atlassian.jira.portal.PortalPageImpl class. This class has deprecated since JIRA 4.1.x.
For similar cases, check if the class exists in the current JIRA version's directory e.g. <jira-installation>/atlassian-jira/WEB-INF/classes/com/atlassian/jira/portal.

Resolution

Remove the third party plugin that's using this deprecated class. Unfortunately, there's no good way to determine the root of the issue, so to find out which one, try removing installed plugins one at a time until the error stops.
Read Full[..]

JIRA Login Gadget and Dashboard Does not Work when Running behind a Load Balancer

Symptoms

  • After upgrading to JIRA 4.4, users are not able to login via login gadget.
  • Dashboard does not render after user logs in via login page.
  • The following appears in the atlassian-jira.log:
    2011-08-30 08:47:00,552 http-8180-7 ERROR anonymous 527x1499x1 1frwtec 192.168.13.5 /plugins/servlet/gadgets/dashboard-diagnostics [dashboard.internal.diagnostics.DiagnosticsServlet] DIAGNOSTICS: FAILED
    com.atlassian.gadgets.dashboard.internal.diagnostics.UrlSchemeMismatchException: Detected URL scheme, 'http', does not match expected scheme 'https'
    at com.atlassian.gadgets.dashboard.internal.diagnostics.Diagnostics.checkExpectedScheme(Diagnostics.java:59)
    at com.atlassian.gadgets.dashboard.internal.diagnostics.Diagnostics.check(Diagnostics.java:31)
    at com.atlassian.gadgets.dashboard.internal.diagnostics.DiagnosticsServlet.executeDiagnostics(DiagnosticsServlet.java

Diagnosis

  • The following settings appear in server.xml
    <Connector port="8080"
     maxThreads="150"
     minSpareThreads="25"
     maxSpareThreads="75"
     connectionTimeout="20000"
     enableLookups="false"
     maxHttpHeaderSize="8192"
     protocol="HTTP/1.1"
     useBodyEncodingForURI="true"
     redirectPort="8443"
     acceptCount="100"
     disableUploadTimeout="true"/>
     <Connector port="8443" protocol="org.apache.coyote.http11.Http11Protocol"
     maxHttpHeaderSize="8192" SSLEnabled="true"
     maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
     enableLookups="false" disableUploadTimeout="true"
     acceptCount="100" scheme="https" secure="true"
     clientAuth="false" sslProtocol="TLS" useBodyEncodingForURI="true"/>

Cause

  • JIRA is running behind a load balancer with SSL Termination configured.
  • JIRA is expecting https scheme while http is detected.

Resolution

Comment out https setting in the server.xml and follow the "Alternative configuration if HTTPS is terminated on the proxy server" section in this guide. For example:
<Connector port="8080"
 maxThreads="150"
 minSpareThreads="25"
 maxSpareThreads="75"
 connectionTimeout="20000"
 enableLookups="false"
 maxHttpHeaderSize="8192"
 protocol="HTTP/1.1"
 useBodyEncodingForURI="true"
 redirectPort="8443"
 acceptCount="100"
 disableUploadTimeout="true"
 <!-- The below are new lines to add - the above is untouched -->
 scheme="https"
 proxyName="<proxy_server>"
 proxyPort="443"
/>
<!--
 <Connector port="8443" protocol="org.apache.coyote.http11.Http11Protocol"
 maxHttpHeaderSize="8192" SSLEnabled="true"
 maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
 enableLookups="false" disableUploadTimeout="true"
 acceptCount="100" scheme="https" secure="true"
 clientAuth="false" sslProtocol="TLS" useBodyEncodingForURI="true"/>
-->
Read Full[..]

Unable to Load a Particular JIRA Dashboard

Symptoms

Trying to load a dashboard page throws the following exception:
java.lang.IndexOutOfBoundsException: Index: 1, Size: 1
    at java.util.ArrayList.RangeCheck(ArrayList.java:546)
    at java.util.ArrayList.get(ArrayList.java:321)
    at com.atlassian.jira.portal.AbstractPortalPageImpl$ConfigInfo.putInColumn(AbstractPortalPageImpl.java:365)
    at com.atlassian.jira.portal.AbstractPortalPageImpl$ConfigInfo.setPortletConfigurations(AbstractPortalPageImpl.java:291)
    at com.atlassian.jira.portal.AbstractPortalPageImpl.setPortletConfigurations(AbstractPortalPageImpl.java:162)
    at com.atlassian.jira.dashboard.JiraDashboardStateStoreManager$2.get(JiraDashboardStateStoreManager.java:89)

Cause

Some of the gadgets in the dashboard are set in a column that the dashboard layout does not contain. For instance, a gadget is set in the second column of a single column layout.

Resolution

Always back up your data before performing any modification to the database. If possible, try your modifications on a test server.
Update the database directly. You can identify the gadget and dashboard causing the problem with the following SQL:
select PC.ID as gadget_id,
       PP.ID as portlet_id
from portletconfiguration PC,
     portalpage PP
where PC.PORTALPAGE = PP.ID AND
      column_number > length(layout) -1;
Info This example works with MySQL. Similar queries can be formed for other databases.
Read Full[..]

Passed List Had More than One Value when Calling JIRA Dashboard

Symptoms

Users trying to access the dashboard will encounter a System Error page containing an exception like the following:
java.lang.IllegalArgumentException: Passed List had more than one value.
at org.ofbiz.core.entity.EntityUtil.getOnly(EntityUtil.java:58)
at com.atlassian.jira.portal.OfBizPortalPageStore.getPortalPageByOwnerAndName(OfBizPortalPageStore.java:135)
at com.atlassian.jira.portal.CachingPortalPageStore.getPortalPageByOwnerAndName(CachingPortalPageStore.java:160)
at com.atlassian.jira.portal.DefaultPortalPageManager.getPortalPageByName(DefaultPortalPageManager.java:152)
at com.atlassian.jira.bc.portal.AbstractPortalPageService.validateForUpdate(AbstractPortalPageService.java:401)
at com.atlassian.jira.dashboard.permission.JiraPermissionService.isWritableBy(JiraPermissionService.java:63)
at com.atlassian.jira.dashboard.permission.JiraGadgetPermissionManager.filterGadgets(JiraGadgetPermissionManager.java:54)
...
Application logs also contain the following ERROR report:
...
2010-04-12 16:58:19,140 http-8080-Processor24 ERROR f97048 61099x220x1 hn6601 http://localhost:8080/secure/Dashboard.jspa [500ErrorPage.jsp] Exception caught in 500 page Passed List had more than one value.
java.lang.IllegalArgumentException: Passed List had more than one value.
    at org.ofbiz.core.entity.EntityUtil.getOnly(EntityUtil.java:58)
    at com.atlassian.jira.portal.OfBizPortalPageStore.getPortalPageByOwnerAndName(OfBizPortalPageStore.java:135)
    at com.atlassian.jira.portal.CachingPortalPageStore.getPortalPageByOwnerAndName(CachingPortalPageStore.java:160)
...

Diagnosis

Further proof can be determined with the following query, as any resulting user will be affected by the problem:
SELECT username, pagename, count(pagename) FROM portalpage GROUP BY username,pagename HAVING count(pagename) > 1;

Cause

The portalpage table is used to store user's dashboard. Normally, it should contain one different pagename for each user. It should not contain names of duplicated pages per user. If there are duplicates, the "Passed List had more than one value" exception will occur.
Here is the code from OfBizPortalPageStore, where the application is expecting a single value from the underlying database:
final GenericValue pageGV = EntityUtil.getOnly(delegator.findByAnd(Table.NAME, EasyMap.build(Column.USERNAME, owner.getName(), Column.PAGENAME, name), DEFAULT_ORDER_BY_CLAUSE));

Resolution

Remove the duplicate tuples from the portalpage table by using the username and pagename column. Use the diagnosis section above for reference.
Read Full[..]

JIRA Dashboard Displays JavaScript Error if Accessed via Internet Explorer

Symptoms

Internet Explorer shows an exclamation mark Warning to indicate there is JavaScript error.

Diagnosis

There is no error thrown by any gadgets.
Turning on the JavaScript debugging will show:
Webpage error details
User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; MDDC; InfoPath.2; .NET4.0C; OfficeLiveConnector.1.5; OfficeLivePatch.1.3)
Timestamp: Thu, 12 Aug 2010 15:06:52 UTC
Message: Invalid character
Line: 1
Char: 1
Code: 0
URI: >/rest/api/1.0/shortcuts/531/c76e82fdebd816afbcdfca788344f04c/shortcuts.js
https://<BASE_URL
Saving the shortcuts.js file will show that the GET return Content-Encoding: , gzip instead of Content-Encoding: gzip

Cause

GZIP compression is enabled in JIRA.

Resolution

Turn off the Use gzip compression via Administration >> Global Settings >> General Configuration.
Read Full[..]