Development Panel missing and Workflow triggers not working

Related content

  • No related content found

Still need help?

The Atlassian Community is here for you.

Ask the community

Problem

  • The Development Panel is not appearing when viewing an Issue in JIRA
    • The Source tab appears on JIRA View Issue page instead
  • Workflow triggers are not working. For example you'll get the response "JIRA is unable to communicate with Stash" when attempting to add a Workflow Trigger in JIRA.

The following appears in the atlassian-jira.log with additional DEBUG logging (see the Diagnosis section below for more details): 

Case1: 

2015-01-21 15:53:26,681 NavLink RestCapabilitiesClient:thread-1 DEBUG anonymous     [menu.client.capabilities.RestCapabilitiesClient] Stacktrace: 
javax.net.ssl.SSLException: hostname in certificate didn't match: <*.atlassian.com> != <unknown>
	at org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:227)
	at org.apache.http.conn.ssl.BrowserCompatHostnameVerifier.verify(BrowserCompatHostnameVerifier.java:54)
	at org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:147)
	at org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:128)
	at org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:437)
	at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:180)
	at org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:294)
	at org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:644)
	at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:479)
	at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906)
	at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:1138)
	at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:1076)
	at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:1050)
	at com.atlassian.plugins.navlink.consumer.http.HttpRequest.executeRequest(HttpRequest.java:26)
	at com.atlassian.plugins.navlink.consumer.http.HttpRequestFactoryImpl.executeGetRequest(HttpRequestFactoryImpl.java:65)
	at com.atlassian.plugins.navlink.consumer.menu.client.capabilities.RestCapabilitiesClient.submitRequest(RestCapabilitiesClient.java:78)
	at com.atlassian.plugins.navlink.consumer.menu.client.capabilities.RestCapabilitiesClient$1.call(RestCapabilitiesClient.java:63)
	at com.atlassian.plugins.navlink.consumer.menu.client.capabilities.RestCapabilitiesClient$1.call(RestCapabilitiesClient.java:56)
	at java.util.concurrent.FutureTask.run(Unknown Source)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)

or 

Case2:

2015-11-25 11:12:28,833 NavLink RestCapabilitiesClient:thread-1 DEBUG anonymous     [menu.client.capabilities.RestCapabilitiesClient] Stacktrace: 
javax.net.ssl.SSLException: Received fatal alert: protocol_version
	at sun.security.ssl.Alerts.getSSLException(Alerts.java:208)
	at sun.security.ssl.Alerts.getSSLException(Alerts.java:154)
	at sun.security.ssl.SSLSocketImpl.recvAlert(SSLSocketImpl.java:2023)
	at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1125)
	at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1375)
	at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1403)
	at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1387)
	at org.apache.http.conn.ssl.SSLConnectionSocketFactory.createLayeredSocket(SSLConnectionSocketFactory.java:290)
	at org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:259)
	at org.apache.http.impl.conn.HttpClientConnectionOperator.connect(HttpClientConnectionOperator.java:125)
	at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:319)
	at org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:363)
	at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:219)
	at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:195)
	at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:86)
	at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:108)
	at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184)

 

Diagnosis

  • Application Link between JIRA and Stash is SSL encrypted.

  • Enabling DEBUG logging for the following packages reveal that there is a mismatch in hostname and the FQDN in SSL certificate(at this time the logging level for these packages do not show the errors by default):

    • com.atlassian.plugins.navlink.consumer.menu.client.capabilities.RestCapabilitiesClient
    • com.atlassian.applinks.core.auth.ApplicationLinkRequestFactoryFactoryImpl
    • com.atlassian.plugins.navlink.consumer.menu.services.CachingRemoteNavigationLinkServiceImpl

  • Once DEBUG logging is enabled there are multiple ways we can trigger JIRA to send a request for the capabilities to Stash:

    • Attempting to add a Workflow Trigger should send the capabilities request
    • Viewing the Development Tools page in JIRA when managing a project and clicking 'Refresh' should send the capabilities request

    (info) See how to Change logging levels in Jira Server / Data Center

Cause

During communication between JIRA and Stash, JIRA will send a request to confirm Stash is capable of handling Workflow Triggers and displaying the Development Panel. 

  • Case1: The link is not working because the hostname does not match the FQDN(Fully Qualified Domain Name) configured in the SSL certificate. 
  • Case2: The link is not working because the remote Host can't accept TLS/SSL version requested by JIRA. Eg. remote host supports TLSv1 only, JIRA asks TLSv1.2. 

Resolution

  • Case1: Ensure the FQDN(Fully Qualified Domain Name) in SSL certificate matches JIRA and Stash hostnames.
  • Case2: Configure environment settings something like -Dhttps.protocols=TLSv1 -Djdk.tls.client.protocols=TLSv1, see also JRA-59406 - Getting issue details... STATUS

    (info) Unable to locate Jira server for this macro. It may be due to Application Link configuration. tracks the work to better handle any mismatch in hostnames by the Application Link.

Last modified on May 24, 2016

Was this helpful?

Yes
No
Provide feedback about this article

Related content

  • No related content found
Powered by Confluence and Scroll Viewport.