Application link not working with the error java.lang.NullPointerException: null

Related content

Still need help?

The Atlassian Community is here for you.

Ask the community


Platform notice: Server and Data Center only. This article only applies to Atlassian products on the Server and Data Center platforms.

Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.

*Except Fisheye and Crucible

    

Summary

Application link between Jira and external Atlassian application can successfully be created. However, when editing the applink configuration, you are receiving java.lang.NullPointerException: null, instead of a working configuration. The same behaviour is seen when editing the applink configuration from the other application

Below error is seen in the UI

Network error

We couldn't connect to <Application> at <URL>. This might have been caused by a network error or another configuration error.

java.lang.NulPointerException: null


Diagnosis

  • Jira and the external application might be hosted on AWS
  • Jira is able to reach the other application and vice versa
  • When creating the application link, Jira is able to detect the correct Base URL and vice versa
  • When there is a mismatch in applink configuration (one application has impersonation but the other doesn't), Jira is able to identify this and give the relevant warning message

  • Below is seen in the application logs atlassian-jira.log when you load the configuration page for this applink

    2022-05-10 15:49:34,489+0200 http-nio-8080-exec-4 url: /rest/applinks/3.0/status/123ab456-7c89-8de7-654f-g321h23ijk45; user: admin DEBUG admin 949x51873x2 17soe1t 123.456.78.910,10.0.200.30 /rest/applinks/3.0/status/123ab456-7c89-8de7-654f-g321h23ijk45 [c.a.a.i.migration.remote.RemoteActionHandler] java.lang.IllegalArgumentException: Illegal base64 character 5f
    	at java.base/java.util.Base64$Decoder.decode0(Base64.java:746)
    	at java.base/java.util.Base64$Decoder.decode(Base64.java:538)
    	at java.base/java.util.Base64$Decoder.decode(Base64.java:561)
2022-05-10 15:49:34,489+0200 http-nio-8080-exec-4 url: /rest/applinks/3.0/status/123ab456-7c89-8de7-654f-g321h23ijk45; user: admin DEBUG admin 949x51873x2 17soe1t 123.456.78.910,10.0.200.30 /rest/applinks/3.0/status/123ab456-7c89-8de7-654f-g321h23ijk45 [c.a.applinks.core.DefaultApplinkStatusService] Unrecognized error trace for '123ab456-7c89-8de7-654f-g321h23ijk45'
java.lang.NullPointerException
	at com.atlassian.plugins.rest.module.jersey.JerseyEntityHandler.unmarshall(JerseyEntityHandler.java:192)
	at com.atlassian.plugins.rest.module.jersey.JerseyResponse.getEntity(JerseyResponse.java:40)
	...

  • Configure the connection to use OAuth without impersonation. Then, with org.apache.http set to DEBUG, the following is seen in the logs (note that this example is when Jira is linked to Bitbucket)

    [o.apache.http.wire] http-outgoing-12479 >> "GET /rest/applinks/latest/applicationlink/123ab456-7c89-8de7-654f-g321h23ijk45/authentication/provider HTTP/1.1[\r][\n]"
[o.apache.http.wire] http-outgoing-12479 >> "Accept: application/json[\r][\n]"
[o.apache.http.wire] http-outgoing-12479 >> "X-Atlassian-Token: no-check[\r][\n]"
[o.apache.http.wire] http-outgoing-12479 >> "Authorization: OAuth oauth_token="", oauth_consumer_key="jira%3A0a26fc23-d46c-4a60-831f-6cea284b9ac7", oauth_signature_method="RSA-SHA1", oauth_timestamp="1653040359", oauth_nonce="a1b23456-cd78-912e-fgh3-4567ijk8lm91_234567891234567", oauth_version="1.0", oauth_signature="LDUjS3SWHjc45AWh44t84xuV5%2HwK45HIFZpwRpIZ%2Hq0xFiUDFunYXmF9tsHdLX%2HCLFC4%2HC6iVrjtdfPCOMFqZHH4JSkCRHSrWItZ2DKDpVyqlZwqRNHl2d5RHImdL0%2FLVXIfF0VKZZoHNZtKHVRMMiU3%2HC1LvDlIHOHA1DRzHXAHXhmvNyrpxwZOkpu4YF8iRPud9%2F2PW%2HH1fvZulvHOYZrDT0UvSyVdD4ICuA4WHU4HwlIKIM4PqYqOj%2FYmsxm39HINLZL2rYZccIIptFisH4IyCs%2F824HKZc6SCXVAiZYT4DjPC6OVca8cY%2Fit5dNdTzStDK3Id0%2FIi3rZ8lhtWA%3D%3D"[\r][\n]"
[o.apache.http.wire] http-outgoing-12479 >> "Host: internal-hostname:8080[\r][\n]"
[o.apache.http.wire] http-outgoing-12479 >> "Connection: Keep-Alive[\r][\n]"
[o.apache.http.wire] http-outgoing-12479 >> "User-Agent: Apache-HttpClient/4.5.13 (Java/1.8.0_292)[\r][\n]"
[o.apache.http.wire] http-outgoing-12479 >> "Accept-Encoding: gzip,deflate[\r][\n]"
[o.apache.http.wire] http-outgoing-12479 >> "[\r][\n]"
[o.apache.http.wire] http-outgoing-12479 << "HTTP/1.1 200 OK[\r][\n]"
[o.apache.http.wire] http-outgoing-12479 << "Date: Fri, 20 May 2022 09:52:39 GMT[\r][\n]"
[o.apache.http.wire] http-outgoing-12479 << "Content-Type: text/plain[\r][\n]"
[o.apache.http.wire] http-outgoing-12479 << "Content-Length: 3893[\r][\n]"
[o.apache.http.wire] http-outgoing-12479 << "Connection: keep-alive[\r][\n]"
[o.apache.http.wire] http-outgoing-12479 << "Accept: application/json[\r][\n]"
[o.apache.http.wire] http-outgoing-12479 << "Accept-Encoding: gzip,deflate[\r][\n]"
[o.apache.http.wire] http-outgoing-12479 << "Authorization: OAuth oauth_token="", oauth_consumer_key="jira%3A0a26fc23-d46c-4a60-831f-6cea284b9ac7", oauth_signature_method="RSA-SHA1", oauth_timestamp="1653040359", oauth_nonce="a1b23456-cd78-912e-fgh3-4567ijk8lm91_234567891234567", oauth_version="1.0", oauth_signature="LDUjS3SWHjc45AWh44t84xuV5%2HwK45HIFZpwRpIZ%2Hq0xFiUDFunYXmF9tsHdLX%2HCLFC4%2HC6iVrjtdfPCOMFqZHH4JSkCRHSrWItZ2DKDpVyqlZwqRNHl2d5RHImdL0%2FLVXIfF0VKZZoHNZtKHVRMMiU3%2HC1LvDlIHOHA1DRzHXAHXhmvNyrpxwZOkpu4YF8iRPud9%2F2PW%2HH1fvZulvHOYZrDT0UvSyVdD4ICuA4WHU4HwlIKIM4PqYqOj%2FYmsxm39HINLZL2rYZccIIptFisH4IyCs%2F824HKZc6SCXVAiZYT4DjPC6OVca8cY%2Fit5dNdTzStDK3Id0%2FIi3rZ8lhtWA%3D%3D"[\r][\n]"
[o.apache.http.wire] http-outgoing-12479 << "breadcrumbId: ID-ip-10-120-30-140-eu-central-1-compute-internal-1122334455667-1-203040[\r][\n]"
[o.apache.http.wire] http-outgoing-12479 << "User-Agent: Apache-HttpClient/4.5.13 (Java/1.8.0_292)[\r][\n]"
[o.apache.http.wire] http-outgoing-12479 << "X-Amzn-Trace-Id: Root=1-234567a8-9b123cd456e7fg891h23ij45[\r][\n]"
[o.apache.http.wire] http-outgoing-12479 << "X-Atlassian-Token: no-check[\r][\n]"
[o.apache.http.wire] http-outgoing-12479 << "X-Forwarded-For: 10.0.30.40[\r][\n]"
[o.apache.http.wire] http-outgoing-12479 << "X-Forwarded-Port: 8080[\r][\n]"
[o.apache.http.wire] http-outgoing-12479 << "X-Forwarded-Proto: https[\r][\n]"
[o.apache.http.wire] http-outgoing-12479 << "[\r][\n]"
[o.apache.http.wire] http-outgoing-12479 << "java.lang.IllegalArgumentException: Illegal base64 character 5f[\n]"
[o.apache.http.wire] http-outgoing-12479 << "[0x9]at java.base/java.util.Base64$Decoder.decode0(Base64.java:746)[\n]"
[o.apache.http.wire] http-outgoing-12479 << "[0x9]at java.base/java.util.Base64$Decoder.decode(Base64.java:538)[\n]"
[o.apache.http.wire] http-outgoing-12479 << "[0x9]at java.base/java.util.Base64$Decoder.decode(Base64.java:561)[\n]"
...
...
...

Cause

When loading the configuration page, Jira would perform some requests to the other application and is expecting some standard responses. In this case, when performing request against /rest/applinks/latest/applicationlink/<appId>/authentication/provider, it should actually receive a HTTP 401 response when using OAuth without impersonation. Below is the trace with org.apache.http set to DEBUG for a working application link

[o.apache.http.wire] http-outgoing-130 >> "GET /b7210/rest/applinks/latest/applicationlink/6512344c-f442-3dd1-88ba-1f3c655962ae/authentication/provider HTTP/1.1[\r][\n]"
[o.apache.http.wire] http-outgoing-130 >> "Accept: application/json[\r][\n]"
[o.apache.http.wire] http-outgoing-130 >> "X-Atlassian-Token: no-check[\r][\n]"
[o.apache.http.wire] http-outgoing-130 >> "Authorization: OAuth oauth_token="", oauth_consumer_key="jira%3A9d4bdb40-b08d-41c2-85ae-d36f5d1fe861", oauth_signature_method="RSA-SHA1", oauth_timestamp="1653046017", oauth_nonce="d85b5cfe-0960-4135-aa88-38c506d8e493_14565012798176", oauth_version="1.0", oauth_signature="OnOXpQFuswynLrwm6cQAPeqkmLhbReIqRGbmZ3l9jdF6RZeLrI0zKnmKh8zNLgiA3dyseI1zgJuGMweHnbPKgzJCF4030fN2KtyitRQZwDPh4GyugnZU7338dUI06tMnw0fJCueIf5aGxIWRAXQNM%2BqRxcY8PICOOU2IXXoqJFoBmNg0dMTocCIE0Z3MJkdIKlTIwNpfQSogVDtYbJUyKXaSmvH6OFAatbbOCNZ8iMdqD89IOaDAvL4XqXaDaV7w6yvtlTDfctCbs6zjvZIedcDbt8US2SfZCwm%2BehfjKskocrW858aSTbAMXu4QcdSxFy6wIC2UhycrqMfYHJ8mEA%3D%3D"[\r][\n]"
[o.apache.http.wire] http-outgoing-130 >> "Host: localhost:27210[\r][\n]"
[o.apache.http.wire] http-outgoing-130 >> "Connection: Keep-Alive[\r][\n]"
[o.apache.http.wire] http-outgoing-130 >> "User-Agent: Apache-HttpClient/4.5.13 (Java/11.0.12)[\r][\n]"
[o.apache.http.wire] http-outgoing-130 >> "Accept-Encoding: gzip,deflate[\r][\n]"
[o.apache.http.wire] http-outgoing-130 >> "[\r][\n]"
[o.apache.http.wire] http-outgoing-130 << "HTTP/1.1 401 [\r][\n]"

However, due to network configuration issues (or network layer related bugs), the request doesn't even reach the external application but Jira receives a HTTP 200 response instead. Jira is unable to handle this unexpected response thus throws this error in the logs and UI

Solution

In this particular case, it was a code bug caused by other configured route at Apache ESB layer (ESB has several other applications using it). However, this error could be caused by any other software/configuration in the network. You will need to debug your network to identify the point of failure.



Last modified on Sep 8, 2022

Was this helpful?

Yes
No
Provide feedback about this article

Related content

Powered by Confluence and Scroll Viewport.