I was trying to call Webservice on JBoss(A) from another JBoss server(B).
I can invoke Webservice deployed on JBoss(A) nicely from the Webservice Client which I created with source code made by "wsimport".
But when I deploy this client onto JBoss(B) and called from Servlet, the client threw exception.
Root of the exception is
Caused by: javax.xml.ws.WebServiceException: Could not find service named {http://searchrequest}HotelSearchWebService in wsdl http://xxxxxx:8080/schedule_jsf/HotelSearchWebService?wsdl
I double checked urls and names, nothing is wrong.(I mean same names and addresses with local client which works fine)
I was thinking simply deploy Websevice Client on Server and it will work happy forever.
But it seems like some specific configuration needed.
Does someone have any idea?
Or if somebody knows any example source code on the web.
I will be happy with any information.
I have solved the problem.
Somehow my pojo parameters that created by jaxb had empty element name.
When I added annotation attribute, it worked fine.
Now everything is OK, my server is working beautiful.
Thanks for your visit and have a nice day, everyone.
Related
We have deployed our webservice in liberty server.Earlier it was on IBM WAS. After deploying in liberty, we came to know that Webservices is running on CXF webservice framework. In WAS, it was Axis framework.
Another difference is that , changes happened in wsdl url & content. The old wsdl url is http://localhost:8080/Hello/HelloServices/Helloservices.wsdl and it contains xsd schema definition.
In the liberty server above wsdl url is not working and throwing file not found. But if we try to invoke http://localhost:8080/Hello/HelloServices?wsdl it's working.
Could anyone tell why old url is not working in New server. Is it due to server or inbuilt cxf framework in server.
Another team is using wsdl url to consume this webservice, with this new url they are not able to achieve it.
Any thoughts or suggestions are appreciated..
Thanks in Advance
The main reason for this is the change in the JAX-WS implementations used by the different WebSphere profiles. CXF, unfortunately, hard codes the WSDL url to append ?wsdl in several locations and so this is something that is not possible to change in configuration. The easiest solution would to add a ServletFilter to check the incoming request url for http://localhost:8080/Hello/HelloServices/Helloservices.wsdl and then redirect the request to http://localhost:8080/Hello/HelloServices/Helloservices?wsdl.
There's a good SO post that shows how to write a ServletFilter to redirect here:
How to use a servlet filter in Java to change an incoming servlet request url?
The other option would be to have the client side update either their code or configuration to account for the change to the WSDL URL.
Hi I have a problem for quite some time that I can not solve. When I run my application on STS spring with spring run boot command, everything works fine. But if I try to deploy application on tomcat, everything works except the addition of a namespace to a soap message that reject the call to the soap service.
I insert below correct soap message on spring boot and follow the wrong message on tomcat.
SPING BOOT SUCCESS SOAP MSG:
<RetrieveDocumentSetRequest
xmlns="urn:ihe:iti:xds-b:2007"
xmlns:ns2="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0"
xmlns:ns3="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0"
xmlns:ns4="urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0"
xmlns:ns5="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0">
<DocumentRequest>
<RepositoryUniqueId>2.16.840.1.113883.2.9.2.999.4.5.113883</RepositoryUniqueId>
<DocumentUniqueId>2.16.840.1.113883.2.9.2.999.4.4^123456</DocumentUniqueId></DocumentRequest>
</RetrieveDocumentSetRequest>
TOMCAT 7 FAIL SOAP MSG:
<ns6:RetrieveDocumentSetRequest
xmlns:ns2="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0"
xmlns:ns3="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0"
xmlns:ns4="urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0"
xmlns:ns5="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0"
xmlns:ns6="urn:ihe:iti:xds-b:2007">
<DocumentRequest><RepositoryUniqueId>2.16.840.1.113883.2.9.2.999.4.5.113883</RepositoryUniqueId>
<DocumentUniqueId>2.16.840.1.113883.2.9.2.999.4.4^123456</DocumentUniqueId>
</DocumentRequest>
</ns6:RetrieveDocumentSetRequest>
As you can see messages are almost same except for n6 namespace. I can't understand why and if there is a wrong Jar on tomcat respect to springboot sever.
I have solved my problem.
The generator classes specified in the pom.xml of spring boot, using JAXB to generate classes from the interface WSDL, while the Jar that use and release of tomcat, using jax-ws library for generations of classes starting from WSDL.
The first library, JAXB, insert the annotation regarding the namespace, both on classes properties and inner classes of the generated classes. All this does not happen when using jax-ws, but only for some classes. This thing even if at first sight irrelevant, creates an answer rejected by the validator server side, the SOAP request sent.
I hope it will help someone in the future.
I am new in the area of SOAP Based web services. I am using TomEE server. The server is a bit customized according to my organization's need.
Few days back, when I was trying to run the web services example from TomEE website, I was able to generate the wsdl and calling the web service by a client.
Now, when I need to use the customized version of TomEE plus (by the organization), I can see that the request does reach to the server and hence there is a log entry also but my #WebMethod is not getting executed.
Does any one has any idea about any configuration which can prevent the request from reaching to the webservice method? Is there any pointer around how can I debug further to reach out to the root cause of this issue?
Without further information about what is customized it's like fishing in the dark.
I would guess that perhaps the global web.xml or the server.xml of tomee server is changed so that some URI context mappings are not forwarded or ignored. But it's only a lucky tip.
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'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.