JAX WS com.sun.xml.internal.ws.client.ClientTransportException: HTTP transport error: java.net.ConnectException: Connection refused

Question

I am new to JAX-WS. I am trying to access a web service on a remote machine within the company.

I used wsimport tool to generate JAVA classes from the WSDL resource which is present on our intranet. Java files have been successfully created.

I tried sending a request through SOAPUI, I get a valid response. But when I try to run my code it throws Connection refused.

Here is my code.

URL url = new URL("https://xmattersqa.com/api/services/xmatters-4.1.7?wsdl");

QName qname = new QName("http://www.xmatters.com/webservices/schema#4.1.7", "xmatters-   4.1.7");

FindWhoIsOnDuty f = new FindWhoIsOnDuty();  
Xmatters417 cdoubleprime = new Xmatters417(url,qname);

Xmatters417PortType port = cdoubleprime.getXmatters417SOAP11PortHttp();

FindWhoIsOnDutyReturn fresponse = port.findWhoIsOnDuty("fmsopsqa","fmsopsqa", "", "", "",   "Default Company", "Test Grp 1","23/02/2013 0:00:00 AM", "24/02/2013 0:00:00 AM", false);

Later I tried adding this piece of code , and it still doesnt work.

Authenticator.setDefault(new ProxyAuthenticator("fmsopsqa","fmsopsqa"));
System.setProperty("http.proxHost","sprdxmaws401.corp.net");
System.setProperty("http.proxyPort", "8081");

This is what I get

com.sun.xml.internal.ws.client.ClientTransportException: HTTP transport error:    java.net.ConnectException: Connection refused
at      com.sun.xml.internal.ws.transport.http.client.HttpClientTransport.getOutput(HttpClientTransport.java:121)
at com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.process(HttpTransportPipe.java:142)
at com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.processRequest(HttpTransportPipe.java:83)
at com.sun.xml.internal.ws.transport.DeferredTransportPipe.processRequest(DeferredTransportPipe.java:105)
at com.sun.xml.internal.ws.api.pipe.Fiber.__doRun(Fiber.java:587)
at com.sun.xml.internal.ws.api.pipe.Fiber._doRun(Fiber.java:546)
at com.sun.xml.internal.ws.api.pipe.Fiber.doRun(Fiber.java:531)
at com.sun.xml.internal.ws.api.pipe.Fiber.runSync(Fiber.java:428)
at com.sun.xml.internal.ws.client.Stub.process(Stub.java:211)
at com.sun.xml.internal.ws.client.sei.SEIStub.doProcess(SEIStub.java:124)
at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:98)
at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:78)
at com.sun.xml.internal.ws.client.sei.SEIStub.invoke(SEIStub.java:107)
at $Proxy32.findWhoIsOnDuty(Unknown Source)
at FindDuty.main(FindDuty.java:76)
Caused by: java.net.ConnectException: Connection refused
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:351)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:213)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:200)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:432)
at java.net.Socket.connect(Socket.java:529)
at java.net.Socket.connect(Socket.java:478)
at sun.net.NetworkClient.doConnect(NetworkClient.java:163)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:388)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:523)
at sun.net.www.http.HttpClient.<init>(HttpClient.java:227)
at sun.net.www.http.HttpClient.New(HttpClient.java:300)
at sun.net.www.http.HttpClient.New(HttpClient.java:317)
at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:970)
at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:949)
at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:836)
at sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:1014)
at com.sun.xml.internal.ws.transport.http.client.HttpClientTransport.getOutput(HttpClientTransport.java:109)

Service Endpoint links seem to be set correctly.

@WebServiceClient(name = "xmatters-4.1.7", targetNamespace = "http://www.xmatters.com/webservices/schema#4.1.7", wsdlLocation = "https://xmattersqa.com/api/services/xmatters-4.1.7?wsdl")

Swansdown

You're attempting to connect to an SSL secured webservice like you would a regular http service. It doesn't work that way. Look at this example for direction – Gibbous

ok, Thanks I will try that. why did soapUI not need any certificates? – Swansdown

I can't satisfactorily explain that myself, but my best guess is soapUI may be able to automatically negotiate the SSL connection via native windows processing which you're not doing in code yet – Gibbous

awesome, the link was really useful..it worked thanks! – Swansdown

Answer 1

I guess this is way too late but maybe this solution will help others facing the same issue. I just ran into the same problem and found that my proxy-stub-object was calling another URL than I had given to the service object.

java.net.URL wsdlURL = new URL("http://myServiceHost.com/online/myService?wsdl");
Service serviceWebClient = new ServiceWebClient(wsdlURL, new QName("my/namespace", "MyServiceName"));

My debugger showed me then that my service did not try to access the given URL but an internal IP-Address that was inside the projected wsdl on this URL under the service tag.

<service name="MyServiceName">
  <port name="MyServicePort" binding="tns:MyServiceBindingBinding">
    <soap:address location="http://192.168.3.20:9443/online/myService/"/>
  </port>
</service>

so the stub pointed to the endpoint at 192.168.3.20 but my service was not on the same machine and therefore it could obiously not be reached. In order to fix that you have to correct the URL on the stub like this

MyService myService = serviceWebClient.getPort(MyService.class);
BindingProvider bindingProvider = (BindingProvider) myService;
bindingProvider.getRequestContext().put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY, wsdlURL.toString());

this fixed the issue for me

Compete

Thanks - mine was a similar fix - but the ENDPOINT_ADDRESS_PROPERTY needed to be the URL (without the ?WSDL suffix) – Adham

Answer 2

Other than firewall whitelisting as a possible cause, it may not even have that service method available if you get "HTTP status code 404: Processed".

Flabellum

Answer 3

This might be dumb, I have a situation where I defined two port biding on get and update operation, acutally they meant the same thing. After removing duplicate, issue fixed. Just in case it may help any one.

Shanna

Answer 4

As this is the top search result, when searching for this error message. You'll also get the "connection refused" error message, if you're specifying a wrong port number. For me, it was as simple as that. Double check to make sure.

Gumshoe