Java Web服务客户端可以'；当SoapUI可以

我经历了以下错误，在对一些类似问题进行广泛研究后，似乎没有任何帮助

我的错误：

    com.sun.xml.internal.ws.client.ClientTransportException: HTTP transport error: java.net.ConnectException: Connection refused: connect
    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 com.sun.proxy.$Proxy33.onboardPerson(Unknown Source)
    at com.paychex.corp.fileloader.FileloaderMain.callWebService(FileloaderMain.java:202)
    at com.paychex.corp.fileloader.FileloaderMain.main(FileloaderMain.java:104)
Caused by: java.net.ConnectException: Connection refused: connect
    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:366)
    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:411)
    at sun.net.www.http.HttpClient.openServer(HttpClient.java:525)
    at sun.net.www.http.HttpClient.<init>(HttpClient.java:208)
    at sun.net.www.http.HttpClient.New(HttpClient.java:291)
    at sun.net.www.http.HttpClient.New(HttpClient.java:310)
    at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:987)
    at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:966)
    at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:841)
    at sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:1031)
    at com.sun.xml.internal.ws.transport.http.client.HttpClientTransport.getOutput(HttpClientTransport.java:109)

如上所述，SoapUI可以发送相同的测试信息，并从服务获得完全有效的请求。所有信息都相同。我已经挖掘了一段时间，确认没有代理，它们都是相同的位（在本例中为32/64），服务名和WSDL都是正确的，对象的命名也正确，我做了进一步的调试，试图绕过这个看起来没有可用信息的可怕错误代码，并使用wireshark将SoapUI请求与java请求进行比较，发现SoapUI使用的是POST，java客户机使用的是get，这让我现在认为这是一般拒绝连接错误的根源

该服务使用BPEL运行，并且是使用BPEL创建的，因此所有代码基本上都是生成的。我现在会查看Get/post查找结果，但我很怀疑这可能是原因，所以我想将其发布出来

非常感谢您的帮助。如果我忘记了我可以分享的任何关键信息，请告诉我

编辑 我想补充的是，我能够从我用来尝试连接到BPEL服务的机器访问web浏览器中的端点URL。问题似乎只存在于我使用wsimport为服务的WSDL获取的WSDL存根生成的客户机上

编辑2：发展/进展

---

问题似乎是，即使将qname设置为正确的地址，客户端仍在向本地主机发送响应。我现在正试图找出本地主机的设置位置。任何关于这一发展的想法都将不胜感激。

已经有一段时间了，但我相信这句话：

URL=newurl（“http://correctserviceurl?WSDL");

需要阅读：
URL URL=newurl（“http://correctserviceurl");
K！我相信这是BPEL的一个问题。相当令人沮丧。显然，在以下行中初始化服务之后：

URL url = new URL("http://serviceaddresshere?WSDL");
        QName qname = new QName("http://servicelocationaddress","NameOfService");
        CorporateEmployeeOnboardingService service = new CorporateEmployeeOnboardingService(url, qname);

        CorporateEmployeeOnboardingProcess process = service.getICorporateEmployeeOnboardingProcess();

BPEL使用服务WSDL和正确的地址获取请求。然而，BPEL似乎认为“O？你想要这个服务，我给你，只有你想要的WSDL是包装器，所以这里才是真正的WSDL。”用简单的英语，你会得到它认为是服务的BPEL WSDL，其中有Localhost地址。现在，我尝试更改此WSDL中的地址，但BPEL在wazzoo中出现了错误。因此，在流程变量make:（AKA the FIX）之后，在这一行中添加了变通方法

基本上，在创建流程后再次设置端点，因为BPEL会覆盖您第一次发送的内容。这当然是一种变通方法，但现在这个过程很好。如果您能想出一种方法来绕过这一工作，动态地修复服务，这样当我们将ti转移到新环境（如开发人员等）时，就不必不断地更改服务WSDL。我洗耳恭听。谢谢，我将一如既往地阅读评论以获取建议。=）
 您可以使用bpel配置计划在环境之间切换

建议使用配置计划来制作特定于环境的复合材料

有效地使用配置计划可以大大减少每个流程所需的工作

可以从composite.xml文件生成配置计划

请考虑以下链接：
谢谢您的回复。这并没有解决这个问题，但它肯定必须与URL联系起来。我会把答案贴出来。很快我昨天就忙着通过哈哈来解决这个问题。我会调查的。实际上，我并不是团队中编码/设置BPEL方面的人。看了之后我会更新答案。谢谢你的回复。
URL url = new URL("http://serviceaddresshere?WSDL");
        QName qname = new QName("http://servicelocationaddress","NameOfService");
        CorporateEmployeeOnboardingService service = new CorporateEmployeeOnboardingService(url, qname);

        CorporateEmployeeOnboardingProcess process = service.getICorporateEmployeeOnboardingProcess();

((BindingProvider) process).getRequestContext().put(Dispatch.ENDPOINT_ADDRESS_PROPERTY, "http://the serviceaddress");