Application link not working due to "ManifestNotFoundException"
- An Application Link is configured to go through a proxy and Application Link is not working.
- An Application Link is attempting to be established in one of our applications and is failing.
- When attempting to create an Application Link, it will not automatically identify the target application and steps must be entered manually.
The following appears in the
2013-01-08 07:11:24,502 ajp-bio-8009-exec-22 ERROR thetusadmin 431x5138x1 fdkc4n 10.1.11.121 /rest/applinks/1.0/applicationlinkForm/manifest.json [core.rest.ui.CreateApplicationLinkUIResource] ManifestNotFoundException thrown while retrieving manifest com.atlassian.applinks.spi.manifest.ManifestNotFoundException at com.atlassian.applinks.core.manifest.AppLinksManifestDownloader.download1(AppLinksManifestDownloader.java:181) at com.atlassian.applinks.core.manifest.AppLinksManifestDownloader.access$000(AppLinksManifestDownloader.java:41) at com.atlassian.applinks.core.manifest.AppLinksManifestDownloader$1$1.<init>(AppLinksManifestDownloader.java:83) at com.atlassian.applinks.core.manifest.AppLinksManifestDownloader$1.apply(AppLinksManifestDownloader.java:76) at com.atlassian.applinks.core.manifest.AppLinksManifestDownloader$1.apply(AppLinksManifestDownloader.java:73) at com.google.common.collect.ComputingConcurrentHashMap$ComputingValueReference.compute(ComputingConcurrentHashMap.java:355)
When an Application Link is attempted to be created in an Atlassian application, it will attempt to connect to the target application's manifest. This manifest contains some important information such as the id, name, type, version, application link version and authentication types of the target application. If that information cannot be retrieved the application link will not be successfully created.
It is possible to create an AppLink without the manifest, however it will not fully function.
When attempting to establish application links, the following HTTP requests are made:
- The source application will query its own
applicationlinkForm, for example
- The source then establishes a HTTP connection to the manifest of the target application - in this example https://confluence.atlassian.com/rest/applinks/1.0/manifest.json.
This is typically where the
ManifestNotFoundExceptionis thrown as JIRA cannot connect to Confluence due to network-layer problems.
- And the source will then query its own manifest, for example
If any of those network routings fail, the entire application link process can fail. If anything gets in the way of that network request and/or the request is not routed correctly, or the manifest cannot be downloaded, the AppLink will throw the
ManifestNotFoundException as per the example above. The most common failures are:
- Proxies - both outbound and reverse - incorrectly routing traffic.
- DNS configurations - for example something that forces network traffic to route through an authentication protocol such as Kerberos or NTLM.
There is also a known problem raised as an improvement request that obscures certain HTTP responses (those under 300 and over 400) that cause the AppLink to fail as tracked in - APLDEV-175Getting issue details... STATUS .
- If using an outbound proxy (as per How to Configure an Outbound HTTP and HTTPS Proxy for JIRA applications) ensure that the target is defined in the
- Disable any proxies between the target and source server, for example revert the changes in How to Configure an Outbound HTTP and HTTPS Proxy for JIRA applications and/or Integrating JIRA with Apache using SSL. This will also need to be done on the target applications.
- After updating the Base URLs of the target and the source to the IP:port, attempt to establish the application links using the IP:port number of the source and target instances in an attempt to bypass the proxy configurations.
server.xmlhas been configured to use
schemesettings as per our recommended proxy docs this will not be possible, as it will redirect back to the proxy. For Bitbucket Server 5.0+ the equivalent properties are
schemewhich are configured in
Verify the connection can be established from the target to the source server on the command-line using curl (installed in *nix by default) as per the below example. Replace
potatobakewith the hostname of the target.
curl -H "Accept: application/json" http://potatobake:8090/rest/applinks/1.0/manifest -v
This will return something such as the below:
* About to connect() to potatobake port 8090 * Trying 10.65.157.92... connected * Connected to potatobake (10.65.157.92) port 8090 > GET /rest/applinks/1.0/manifest HTTP/1.1 > User-Agent: curl/7.15.5 (x86_64-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5 > Host: potatobake:8090 > Accept: application/json > < HTTP/1.1 401 Unauthorized < Set-Cookie: FESESSIONID=1cf1ueey5icc41u9g62sb3blkd;Path=/;HttpOnly < WWW-Authenticate: Negotiate < WWW-Authenticate: Ntlm < WWW-Authenticate: Basic realm="OHYEAH.EXAMPLE.COM" < Content-Type: text/html;charset=ISO-8859-1 < Cache-Control: must-revalidate,no-cache,no-store < Content-Length: 1397 < Server: Jetty(8.1.10.v20130312) <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"/> <title>Error 401 Unauthorized</title> </head> <body><h2>HTTP ERROR 401</h2> <p>Problem accessing /rest/applinks/1.0/manifest. Reason: <pre> Unauthorized</pre></p><hr /><i><small>Powered by Jetty://</small></i><br/> ... * Connection #0 to host potatobake left intact * Closing connection #0
In this example we can see a HTTP 401 is being returned when attempting to connect to a FishEye server, which is caused by NTLM. This is causing the application link to fail as it cannot connect to the server successfully. This needs to be resolved by the administrators who configured NTLM.
Identify the problem with the network layer and correct it, as per the above troubleshooting steps.