简体   繁体   中英

jax-ws client problem

I have produced a jax-ws client by executing the command:

C:\wsdl>wsimport -keep -verbose -d generated HealthMobilitySequenceArtifacts.wsdl

The service address in the wsdl file is:

soap:address location="http://localhost:8585/active-bpel/services/HealthMobilitySequence

Well, I have packaged the generated files in a jar ( clentjaxw.jar ) and I'm using it, as imported library, in an eclipse project to make some tests.

The fact is that I'm able to make my tests without problems but when I provide a collegue the clientjaxw.jar he has the following error during the execution:

Exception in thread "main" 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(Unknown Source)
        at com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.process(Unknown Source)
        at com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.processRequest(Unknown Source)
        at com.sun.xml.internal.ws.transport.DeferredTransportPipe.processRequest(Unknown Source)
        at com.sun.xml.internal.ws.api.pipe.Fiber.__doRun(Unknown Source)
        at com.sun.xml.internal.ws.api.pipe.Fiber._doRun(Unknown Source)
        at com.sun.xml.internal.ws.api.pipe.Fiber.doRun(Unknown Source)
        at com.sun.xml.internal.ws.api.pipe.Fiber.runSync(Unknown Source)
        at com.sun.xml.internal.ws.client.Stub.process(Unknown Source)
        at com.sun.xml.internal.ws.client.sei.SEIStub.doProcess(Unknown Source)
        at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(Unknown Source)
        at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(Unknown Source)
        at com.sun.xml.internal.ws.client.sei.SEIStub.invoke(Unknown Source)
        at $Proxy29.bookTreatment(Unknown Source)
        at test.TestJaxWS.main(TestJaxWS.java:32)
    Caused by: java.net.ConnectException: Connection refused: connect
        at java.net.PlainSocketImpl.socketConnect(Native Method)
        at java.net.PlainSocketImpl.doConnect(Unknown Source)
        at java.net.PlainSocketImpl.connectToAddress(Unknown Source)
        at java.net.PlainSocketImpl.connect(Unknown Source)
        at java.net.SocksSocketImpl.connect(Unknown Source)
        at java.net.Socket.connect(Unknown Source)
        at java.net.Socket.connect(Unknown Source)
        at sun.net.NetworkClient.doConnect(Unknown Source)
        at sun.net.www.http.HttpClient.openServer(Unknown Source)
        at sun.net.www.http.HttpClient.openServer(Unknown Source)
        at sun.net.www.http.HttpClient.(Unknown Source)
        at sun.net.www.http.HttpClient.New(Unknown Source)
        at sun.net.www.http.HttpClient.New(Unknown Source)
        at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(Unknown Source)
        at sun.net.www.protocol.http.HttpURLConnection.plainConnect(Unknown Source)
        at sun.net.www.protocol.http.HttpURLConnection.connect(Unknown Source)
        at sun.net.www.protocol.http.HttpURLConnection.getOutputStream(Unknown Source)
        ... 15 more

I don't understand the problem: nevertheless the collegue is able to visualize the service in the browser at that address an also the ping localhost runs. Moreover I have checked he is not behind a proxy.

Have you some ideas about the cause of the problem?


UPDATE: I have to add new details: I have discovered that the collegue is able to access, via browser, to: http://localhost:8585/active-bpel/services/HealthMobilitySequence?wsdl but if he tries to access to:http://127.0.0.1:8585/active-bpel/services/HealthMobilitySequence?wsdl or to the same url with the ip address in place of localhost he fails. On my machine I don't have such problem I'm able to access with all possibilities: localhost, machine name, 127.0.0.1, ipaddress.

So I think this could be the problem I mean I immagine that via java, the url http://localhost:8585/active-bpel/services/HealthMobilitySequence is translated, before opening a java socket connection, in a new one using the ip address (or 127.0.0.1) in place of localhost and the access fails. So it seems that the problem is due to the operative system since we share exactly the same configuration a part the operative system (win xp on my machine, vista on his one).

Some ideas? Thanks


UPDATE: Hi again, for some reason changing the machine (always 64 bit) the collegue has solved the problem I have described. Anyway he has another problem which does not depend from the client since he has experienced the same also by invoking using eclipse web explorer. The exception is the following: java.lang.ClassCastException: com.sun.xml.internal.messaging.saaj.soap.ver1_1.Envelope1_1Impl cannot be cast to java.lang.String

    org.apache.axis.SOAPPart.getAsString(SOAPPart.java:554)

    org.apache.axis.SOAPPart.writeTo(SOAPPart.java:322)

    org.apache.axis.SOAPPart.writeTo(SOAPPart.java:269)

    org.apache.axis.Message.writeTo(Message.java:539)

    org.apache.axis.transport.http.AxisServlet.sendResponse(AxisServlet.java:902)

    org.apache.axis.transport.http.AxisServlet.doPost(AxisServlet.java:777)

    javax.servlet.http.HttpServlet.service(HttpServlet.java:647)

    org.apache.axis.transport.http.AxisServletBase.service(AxisServletBase.java:327)

    javax.servlet.http.HttpServlet.service(HttpServlet.java:729)

Please take care that the web service he is tring to invoke is that one of a bpel process deployed in an ActiveBPEL (version 5.0.2) running in a Tomcat 5.5.27. Moreover its configuration is the following: OP: windows 7, jdk: 1.6, arch:64 bit while the mine is: OP: windows xp, jdk: 1.6, arch: 32 bit. Have you some idea about the problem?

Thanks in advance

I just ran into this issue when building and testing the ActiveBPEL code. My solution was to explicitly map the java.xml.soap.MessageFactory to the Axis implementation. This avoids the incompatibilities between the two SOAP stacks.

The mapping can be done a couple of different ways.

  1. Use a system property -Djavax.xml.soap.MessageFactory=org.apache.axis.soap.MessageFactoryImpl
  2. Include a factory file on the classpath: /META-INF/javax.xml.soap.MessageFactory where the contents of this file is a single line of text: org.apache.axis.soap.MessageFactoryImpl

If you're building the AE source then the latter is the preferred mechanism and could be added to the org.activebpel.rt.axis.bpel project. If you're using the binaries, then you'll likely need to create a custom property on the startup script for your container (Tomcat/Jetty).

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM