We just finished upgrading from Jira 4.2.4 to Jira 4.3.3. During the upgrade, the existing fisheye/crucible configuration is converted to application links. In our environment, Jira just hung and threw a bunch of errors in the log saying it couldn't reach our fisheye servers. Once we added the XFire jar file to Jira, these problems went away, so I'm guessing that's what resolved the problem. (I suppose it's possible that the problem was related to some other issue and that it's just a coincidence that it went away after we added the XFire jar file, but it seems like a rather strange coincidence if that's the case).

Dave,

Can you give a concrete example? What plugin in what version of JIRA is attempting to talk over an application link, and what library is it using to do so (XFire? Apache HttpClient? etc)?

This issue really needs to be reopened. When Matt did his investigation, he was only looking at Crowd. Jira needs to be able to talk to other servers behind the firewall as well, however. For example, you can't create an application link to Fisheye/Crucible or Confluence unless you're able to get Jira to recognize the "-Dhttp.nonProxyHosts" setting.

Why the resolution here is not the same than here: http://confluence.atlassian.com/display/JIRAKB/JAVA+Option+%27-Dhttp.nonProxyHosts%27+Does+Not+Work

IMO there's a fix to do in JIRA, replace the jars, that did the trick for me. See https://support.atlassian.com/browse/JSP-76065

Investigation:

In JIRA 4.2

• UPM uses apache HttpClient which looks at http.proxyHost and http.proxyPort. But HttpClient never inspects http.nonProxyHosts so if you set the first two properties, there is no way to stop UPM from using a proxy. NB: no one is complaining about this.
• The Crowd Integration Library in JIRA used XFire to talk SOAP to Crowd, which looks for http.proxyHost and http.proxyPort. But needs xfire-java5.jar in order to inspect http.nonProxyHosts. This is what people are complaining about – if you've set up a proxy for UPM (commonly to punch through a firewall), you commonly don't want to talk to your Crowd in your DMZ via a proxy.

In JIRA 4.3

• The UPM situation is the same.
• The Crowd Integration Library (via Embedded Crowd) uses neither http.proxyHost/http.proxyPort nor http.nonProxyHosts. It looks instead for crowd.property.http.proxy.host and crowd.property.http.proxy.port (or it should, see CWD-2242).
• This means proxies can be set (or absent) independently for UPM and Crowd, which is what people are requesting.

Resolution

• No code changes in either 4.2 or 4.3 with respect to xfire-java5.jar.
• JIRA 4.3 implicitly fixes this problem by using a different proxy config for Crowd.

I agree with Zachary. Is there any reason why this is not included yet? It took us nearly two hours to fix this...
We encountered it while upgrading from 4.1 to 4.2.1.

2011-01-18 11:10:04,848 main ERROR [atlassian.jira.upgrade.UpgradeManagerImpl] Exception thrown during upgrade: java.util.concurrent.ExecutionException: org.codehaus.xfire.XFireRuntimeException: Could not invoke service.. Nested exception is org.codehaus.xfire.fault.XFireFault: Unexpected close tag </H4>; expected </P>.
at [row,col

]: [8,4]

This work around appears to be working for us, but we were dead in the water without it. Would definitely like to see this integrated ASAP.

For others who may be looking for the jar file needed, it's located here:

http://repository.codehaus.org/org/codehaus/xfire/xfire-java5/1.2.6/

The new Universal Plugin Manager won't work for us without this in place. We have Confluence working correctly, so I thought I could just copy the Java options related to proxy settings over to Jira and have everything work. Doing this, however, made Jira unable to talk to Crowd because of the ignored "-Dhttp.nonProxyHosts" setting. Took me about 3.5 hours to figure out what was going on.