I'm getting the below exception when the JAXWS Java consumer stub constructor is invoked. When I try via. SOAPUI everything is working fine and able to get correct response. It is a web server to multiple app server (Websphere 7.x clustered) setup. Consumer code looks fine. Provider code is fine, since it works in SOAPUI. There is some problem with Web Server and web server may respond with a HTML rather then XML. App Server doesn't get the request when trying via Java consumer and no logs are there. We tested in local app server without web server setup, it works. Don't know where the problem lies? Anybody can help? I'm using Axis2 that comes with WebSphere for hosting web service. Web Sphere reads annotations in implementation class to deploy web service. Generate WSDL automatically. WSDL Location I've not specified in implementation file, if it specified not works. No configuration file (web.xml, etc.,) i provide. It is not an HTTPS web service. I'm able to telnet to the web service server and get the WSDL via telnet.
javax.xml.ws.WebServiceException: javax.wsdl.WSDLException: WSDLException: faultCode=PARSER_ERROR: Problem parsing 'http://ip:port/AppName/ServiceName'.: (http://ip:port/AppName/ServiceName%27.:) org.xml.sax.SAXParseException: The markup in the document following the root element must be well-formed.
at org.apache.axis2.jaxws.ExceptionFactory.createWebServiceException(ExceptionFactory.java:175)
at org.apache.axis2.jaxws.ExceptionFactory.makeWebServiceException(ExceptionFactory.java:70)
at org.apache.axis2.jaxws.ExceptionFactory.makeWebServiceException(ExceptionFactory.java:128)
at org.apache.axis2.jaxws.util.WSDL4JWrapper.loadDefinition(WSDL4JWrapper.java:754)
at org.apache.axis2.jaxws.util.WSDL4JWrapper.getDefinition(WSDL4JWrapper.java:670)
at org.apache.axis2.jaxws.util.WSDL4JWrapper.commonPartsURLConstructor(WSDL4JWrapper.java:224)
at org.apache.axis2.jaxws.util.WSDL4JWrapper.<init>(WSDL4JWrapper.java:156)
at org.apache.axis2.jaxws.description.impl.ServiceDescriptionImpl.setupWsdlDefinition(ServiceDescriptionImpl.java:1191)
at org.apache.axis2.jaxws.description.impl.ServiceDescriptionImpl.<init>(ServiceDescriptionImpl.java:245)
at org.apache.axis2.jaxws.description.impl.ServiceDescriptionImpl.<init>(ServiceDescriptionImpl.java:168)
at org.apache.axis2.jaxws.description.impl.DescriptionFactoryImpl.createServiceDescription(DescriptionFactoryImpl.java:142)
at org.apache.axis2.jaxws.description.impl.DescriptionFactoryImpl.createServiceDescription(DescriptionFactoryImpl.java:79)
at org.apache.axis2.jaxws.description.DescriptionFactory.createServiceDescription(DescriptionFactory.java:76)
at org.apache.axis2.jaxws.spi.ServiceDelegate.<init>(ServiceDelegate.java:212)
at org.apache.axis2.jaxws.spi.Provider.createServiceDelegate(Provider.java:71)
at javax.xml.ws.Service.<init>(Service.java:67)
at somepackage.servicename.<init>(servicename.java:42)...more are here hidden to maintain confidential
Caused by:
javax.wsdl.WSDLException: WSDLException: faultCode=PARSER_ERROR: Problem parsing 'http://ip:port/AppName/ServiceName'.: (http://ip:port/AppName/ServiceName%27.:) org.xml.sax.SAXParseException: The markup in the document following the root element must be well-formed.
at com.ibm.wsdl.xml.WSDLReaderImpl.getDocument(WSDLReaderImpl.java:2315)
at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(WSDLReaderImpl.java:2390)
at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(WSDLReaderImpl.java:2356)
at org.apache.axis2.jaxws.util.WSDL4JWrapper$13.run(WSDL4JWrapper.java:745)
at org.apache.axis2.java.security.AccessController.doPrivileged(AccessController.java:132)
at org.apache.axis2.jaxws.util.WSDL4JWrapper.loadDefinition(WSDL4JWrapper.java:742)
... 70 more
Caused by:
org.xml.sax.SAXParseException: The markup in the document following the root element must be well-formed.
at org.apache.xerces.parsers.DOMParser.parse(Unknown Source)
at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(Unknown Source)
at com.ibm.wsdl.xml.WSDLReaderImpl.getDocument(WSDLReaderImpl.java:2305)
... 75 more </pre>
I'm not sure what's going wrong with wsdl retrieval for you, but if you can extract the wsdl (and any files it imports) from the remote service and just package them with your client directly, that will avoid retrieving the wsdl from the remote service for each invocation, which besides not working in your case, also degrades performance. Your client wsdllocation would change to file:///(something). If you're using a developer tool like RAD or WDT, it has an option to automatically retrieve the wsdl and package it with the client.
Related
I'm trying the consume a web services built using Axis2, so I have followed this example for creating client code.
I have the endpoint and I'm able to access it through the browser. But trying to generate the client code with:
WSDL2Java.bat -uri <<endpoint>> -o client
throws the exception below:
Exception in thread "main" org.apache.axis2.wsdl.codegen.CodeGenerationException: Error parsing WSDL
at org.apache.axis2.wsdl.codegen.CodeGenerationEngine.(CodeGenerationEngine.java:181)
at org.apache.axis2.wsdl.WSDL2Code.main(WSDL2Code.java:35)
at org.apache.axis2.wsdl.WSDL2Java.main(WSDL2Java.java:24)
Caused by: java.net.ConnectException: Connection timed out: 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 com.sun.net.ssl.internal.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:570)
at com.sun.net.ssl.internal.ssl.BaseSSLSocketImpl.connect(BaseSSLSocketImpl.java:141)
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.protocol.https.HttpsClient.(HttpsClient.java:272)
at sun.net.www.protocol.https.HttpsClient.New(HttpsClient.java:329)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.getNewHttpClient(AbstractDelegateHttpsURLConnection.java:172)
at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:923)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:158)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1195)
at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:379)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:318)
at org.apache.axis2.wsdl.codegen.CodeGenerationEngine.(CodeGenerationEngine.java:99)
... 2 more
What could be the reason for this error?
If you can access the WSDL from a browser but not from the tool in command line then it's possible that your browser uses a HTTP proxy for it's connection while wsdl2java goes straight for the address.
Try setting some JVM parameters for using a proxy, as described in Java Networking and Proxies and if that fails, there is always the option to download the WSDL with the browser and run wsdl2java with the locally downloaded file.
now I have this new problem. I´m using Glassfish 3.1.2.2 to host an application that has a Web Service to communicate with another application outside the server, mainly a swing desktop application. Every thing works fine, but (always a but), if we need to restart the glassfish for some reason, the destop application didn't find the ws, so we need to redeploy the application in the Glassfish and every thing works fine again.
At the begining we thought that was a problem in the desktop client, so we refresh the connection to the web service, nothing. After that, we tested the web service from the netbeans option to do that and we get this warning:
The solution that we found was to redeploy the application, as you guest, when the application will be in production this is not a aceptable solution.
My application is build with jdk 7.0.21, using Netbeans 7.3, JSF 2.0, PrimeFaces 3.5, JPA 2.0, the web service was constructed following this tutorial.
This is the message received in the log of the desktop test application:
Exception in thread "AWT-EventQueue-0" com.sun.xml.internal.ws.client.ClientTransportException: The server sent HTTP status code 404: Not Found
at com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.checkStatusCode(HttpTransportPipe.java:296)
at com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.createResponsePacket(HttpTransportPipe.java:245)
at com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.process(HttpTransportPipe.java:203)
at com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.processRequest(HttpTransportPipe.java:122)
at com.sun.xml.internal.ws.transport.DeferredTransportPipe.processRequest(DeferredTransportPipe.java:95)
at com.sun.xml.internal.ws.api.pipe.Fiber.__doRun(Fiber.java:626)
at com.sun.xml.internal.ws.api.pipe.Fiber._doRun(Fiber.java:585)
at com.sun.xml.internal.ws.api.pipe.Fiber.doRun(Fiber.java:570)
at com.sun.xml.internal.ws.api.pipe.Fiber.runSync(Fiber.java:467)
at com.sun.xml.internal.ws.client.Stub.process(Stub.java:308)
at com.sun.xml.internal.ws.client.sei.SEIStub.doProcess(SEIStub.java:146)
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:129)
at com.sun.proxy.$Proxy30.hello(Unknown Source)
at com.spontecorp.testws.TestWSFrame.invokeWSButtonActionPerformed(TestWSFrame.java:137)
at com.spontecorp.testws.TestWSFrame.access$100(TestWSFrame.java:14)
at com.spontecorp.testws.TestWSFrame$2.actionPerformed(TestWSFrame.java:62)
at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:2018)
at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2341)
at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:402)
at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:259)
at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:252)
at java.awt.Component.processMouseEvent(Component.java:6505)
at javax.swing.JComponent.processMouseEvent(JComponent.java:3321)
at java.awt.Component.processEvent(Component.java:6270)
at java.awt.Container.processEvent(Container.java:2229)
at java.awt.Component.dispatchEventImpl(Component.java:4861)
at java.awt.Container.dispatchEventImpl(Container.java:2287)
at java.awt.Component.dispatchEvent(Component.java:4687)
at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4832)
at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4492)
at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4422)
at java.awt.Container.dispatchEventImpl(Container.java:2273)
at java.awt.Window.dispatchEventImpl(Window.java:2719)
at java.awt.Component.dispatchEvent(Component.java:4687)
at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:729)
at java.awt.EventQueue.access$200(EventQueue.java:103)
at java.awt.EventQueue$3.run(EventQueue.java:688)
at java.awt.EventQueue$3.run(EventQueue.java:686)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:87)
at java.awt.EventQueue$4.run(EventQueue.java:702)
at java.awt.EventQueue$4.run(EventQueue.java:700)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:699)
at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:242)
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:161)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:146)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:138)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:91)
My question is:
- Do I need to setup something in Glassfish after deployment an application that serves a web service?, if so, where?
Had the same problem after refractoring, had to create a new webservice at server (and then just copy the old code), after that I re-imported the new WSDL and made the right changes to the code (to the new name of the webservice).
Problem was, for me at least, that after refractoring I couldn't call
com.package.class.MyWebService_Service service;
Dont know why, and there is probably a better solution for this instead of "recreating".
I don't know if this helps you in your case, but at least the tutorial didn't work for me either out-of-the-box. The error I got was the same: "com.sun.xml.internal.ws.client.ClientTransportException: The server sent HTTP status code 404: Not Found".
I managed to get the web service client working by re-creating the reference to the web service. The problem was that it referred to http://localhost:8080/FlowerAlbumService/FlowerService?wsdl but the service was running on http://localhost:8080/FlowerServiceService/FlowerService?wsdl (you can see this by testing the web service).
So I deleted the web service in the Client's Web Service References node, created a new web service client, and specified http://localhost:8080/FlowerServiceService/FlowerService?wsdl as the WSDL URL. Perhaps this helps to solve your problem, too.
I would like to ask which would be the correct jar files needed to a functional ws client to an authenticated weblogic JAX-RPC.
Situation:
I created the same WS client on Jdeveloper and on OEPE. When I run in the IDE, my client only works on Jdeveloper. Then I generated a Jar file from Jdeveloper and the same error from OEPE ocurrs when I run that jar.
I suppose this happens because there are some libs missing. I really need help! After putting many libs on the classpath, this is the mistake:
"Exception in thread "main" javax.xml.rpc.ServiceException: Failed to
parse WSDL htp://url?WSDL weblogic.wsee.wsdl.WsdlException: Failed to
read wsdl file from url due to -- java.net.ConnectException:
Connection refused: connect
at weblogic.wsee.jaxrpc.ServiceImpl.throwServiceException(ServiceImpl.java:185)
at weblogic.wsee.jaxrpc.ServiceImpl.loadWsdlDefinition(ServiceImpl.java:492)
at weblogic.wsee.jaxrpc.ServiceImpl.(ServiceImpl.java:126)
at br.com.scopus.teste.ServicoAssinaturaImplService_Impl.(ServicoAssinaturaImplService_Impl.java:21)
at br.com.scopus.teste.Client.main(Client.java:26) Caused by: weblogic.wsee.wsdl.WsdlException: Failed to read wsdl file from url d
ue to -- java.net.ConnectException: Connection refused: connect
at weblogic.wsee.wsdl.WsdlReader.getDocument(WsdlReader.java:313)
at weblogic.wsee.wsdl.internal.WsdlDefinitionsImpl.parse(WsdlDefinitions
Impl.java:432)
at weblogic.wsee.wsdl.internal.WsdlDefinitionsImpl.parse(WsdlDefinitions
Impl.java:417)
at weblogic.wsee.wsdl.WsdlFactory.parse(WsdlFactory.java:81)
at weblogic.wsee.wsdl.WsdlFactory.parse(WsdlFactory.java:68)
at weblogic.wsee.jaxrpc.ServiceImpl.loadWsdlDefinition(ServiceImpl.java:
483)
... 3 more"
Maybe Important information:
These are the jar I am using: wlfullclient.jar wsclient.jar adf-config.xml weblogic.jar wseeclient.jar wsclient_extended.jar glassfish.jaxws.rt_1.2.0.0_2-1-5.jar
Weblogic version: 10.3.5
Thanks!
This is probably not a library issue.
You are getting "java.net.ConnectException: Connection refused". So the web service stack managed to perform the call to the WSDL URL but couldn't get through. One reason could be that your URL is incorrect, referring the incorrect interface (localhost rather than actual hostname or vice versa) or anything else.
Try to copy-paste the URL it is telling you it can't access in a web-browser and you should see the same problem.
I have tested my web services (wsdl/soap) with soapui. and i have the errors :
http/log : error 400 BAD REQUEST.
What can be the error please with my wsdl ?
error/log :
un Jun 05 14:10:37 CEST 2011:ERROR:javax.wsdl.WSDLException: WSDLException (at /html): faultCode=INVALID_WSDL: Expected element '{http://schemas.xmlsoap.org/wsdl/}definitions'.
javax.wsdl.WSDLException: WSDLException (at /html): faultCode=INVALID_WSDL: Expected element '{http://schemas.xmlsoap.org/wsdl/}definitions'.
at com.ibm.wsdl.xml.WSDLReaderImpl.checkElementName(Unknown Source)
at com.ibm.wsdl.xml.WSDLReaderImpl.parseDefinitions(Unknown Source)
at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source)
at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source)
at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source)
at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source)
at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source)
at com.eviware.soapui.impl.wsdl.support.wsdl.WsdlInterfaceDefinition.load(WsdlInterfaceDefinition.java:48)
at com.eviware.soapui.impl.wsdl.support.wsdl.WsdlContext.loadDefinition(WsdlContext.java:66)
at com.eviware.soapui.impl.wsdl.support.wsdl.WsdlContext.loadDefinition(WsdlContext.java:30)
at com.eviware.soapui.impl.support.definition.support.AbstractDefinitionContext.cacheDefinition(AbstractDefinitionContext.java:264)
at com.eviware.soapui.impl.support.definition.support.AbstractDefinitionContext.access$400(AbstractDefinitionContext.java:44)
at com.eviware.soapui.impl.support.definition.support.AbstractDefinitionContext$Loader.construct(AbstractDefinitionContext.java:230)
at com.eviware.soapui.support.swing.SwingWorkerDelegator.construct(SwingWorkerDelegator.java:46)
at com.eviware.soapui.support.swing.SwingWorker$2.run(SwingWorker.java:140)
at java.lang.Thread.run(Thread.java:637)
definitions is a root element of WSDL so it looks like you are not loading WSDL.
Edit:
I tested it and it looks like the whole problem is with your web server. Your web server returns WSDL to browser but it doesn't return it to any tool because these tools are using very minimalistic HTTP requests without many HTTP headers. One of missing headers is Accept. Once this header is not included in the request your server throws HTTP 400 Bad request.
The easy approach to continue is opening WSDL in the browser, save the wsdl to a file and import that file to soapUI instead of the WSDL from URL.
Another possibility is that you need to add ?wsdl at the end of your service url for SoapUI.
That one got me as I'm used to WCFClient which didn't need it.
You can try opening the wsdl in web browser and saving with .wsdl extension. And set the WSDL in SOAP UI project to this .wsdl file.
This really works.
yes, first ensure you added "?wsdl" to your "http......whatever.svc" link.
That didn't fix my problem, though. I had to create a new WCF project from the beginning and manually copy the code. That fixed it. Good luck.
And most important!!!
When you change a namespace in your code, also make sure you change it in web.config!
I faced the same exception while trying to test my web-services deployed to WSO2 ESB.
WSO2 generated both wsdl and wsdl2. I tried to pass a wsdl2 URL and got the above exception. Quick googling showed me, that one of differences between wsdl1.1 and wsdl2.0 is replacing 'definitions' element with 'description'. Also, I found out, that SoapUI does not support wsdl2.
Therefore, for me the solution was to use wsdl1 url instead of wsdl2.
A likely possibility is that your browser reaches your web service through a proxy, and SoapUI is not configured to use that proxy. For example, I work in a corporate environment and while my IE and FireFox can access external websites, my SoapUI can only access internal web services.
The easy solution is to just open the WSDL in a browser, save it to a .xml file, and base your SoapUI project on that. This won't work if your WSDL relies on external XSDs that it can't get to, however.
For anyone hitting this issue in the future: the specific situation here ("the server isn't sending back the WSDL properly") may or may not always be relevant, but two key aspects should always be:
The message faultCode=INVALID_WSDL: Expected element '{http://schemas.xmlsoap.org/wsdl/}definitions' means that the actual content returned is not XML with a base element of "definitions" in the WSDL namespace.
The message WSDLException (at /html) tells you an important clue about what it did find — for this example, /html strongly implies that a normal webpage was returned, rather than a WSDL. Another common situation is seeing something like /soapenv:Reason, which would indicate that the server was trying to treat it as a SOAP call — for example, this can happen if your URL is for the "base" service URL rather than the WSDL.
I had the same problem, and the solution (for me) was to:
open SoapUI Preferences
click on SSL Settings
clear out the KeyStore and KeyStore Password text boxes
untick the bottom checkbox for Client Authentication, requires client authentication.
On AspNet services with .svc endding you must terminate URL as "?wsdl".
Otherwise, SoapUI will try to read the land page HTML of the Service (that is not a WSDL, right?)
Eg.:
http://localhost:1234/WebServices/WsBlahBlahBlah.svc?wsdl
I've a web service, which is basically a #Stateless EJB annotated with #WebService, and other JAX-WS related annotations. I can deploy this bean on my machine's glassfish instance, and see its WSDL through Glassfish's administrative GUI. I can also call its methods without any problems, from a SE client.
When I deploy this web service to a server instance in any other machine, I can no longer browse its WSDL through glassfish, and the client fails to connect to the server. The message displayed is:
Invalid WSDL request: http://ip:port/context/serviceEndpoint?wsdl
The HTTP error returned by Glassfish on such request is 405 (method not allowed).
I browsed around, and couldn't get anything directly related to glassfish v3. There are issues open on Glassfish's bugzilla for version 2, meaning they're old and have been labelled as CLOSED/FIXED already.
Anyone ran into this before? Any help or any clues about what could be happening here?
Thanks in advance!
For the sake of those who might come across this problem one day: I had OpenSSO on the target server. And by many obvious reasons, it was a classpath clashing problem that prevented the WSDL to be generated by glassfish.
Once OpenSSO has been removed of the equation, everything worked as it was supposed too. So, even if you're not an OpenSSO user, check your classpath for multiple Metro instances, or any other JAX related library that might be conflicting with glassfish's own on your domain.