I am trying to implement a simple client for a webservice, the only problem I am facing with the webservice is, it has a generic endpoint: http://myserver3333.com:8080/ws/services and the way you lookup for web services deployed is via SOAP header.
So, for example, if you try to hit the service vis SOAP UI,
the endpoint I specify is: http://myserver3333.com:8080/ws/services
In the SOAP headers I specific the following:
SERVICE-NAME = MyAwesomeService
OPERATION-NAME = makeMeMoreAwesome
So, how can I do the same thing using apache cxf client?
My current code:
URL wsdlLocation = new URL("http://myserver3333.com:8080/ws/service");
MyAwesomeService service = new MyAwesomeService(wsdlLocation);
MyAwesomeServicePort port = service.getMyAwesomeServiceSOAPPort();
List<Header> headers = new ArrayList<Header>();
Header operationNameHeader = new Header(new QName("OPERATION-NAME"), "makeMeMoreAwesome",
new JAXBDataBinding(String.class));
Header serviceNameHeader = new Header(new QName("SERVICE-NAME"), "MyAwesomeService",
new JAXBDataBinding(String.class));
headers.add(operationNameHeader);
headers.add(serviceNameHeader);
BindingProvider bindingProvider = (BindingProvider)port;
bindingProvider.getRequestContext().put(Header.HEADER_LIST, headers);
MakeMeMoreAwesomeRequest request = new MakeMeMoreAwesomeRequest();
MakeMeMoreAwesomeResponse response = port.makeMeMoreAwesome(request);
System.out.println(response.getAck());
But when I run this, I get this error:
Exception in thread "main" com.sun.xml.ws.wsdl.parser.InaccessibleWSDLException: 2 counts of InaccessibleWSDLException.
java.io.IOException: Server returned HTTP response code: 500 for URL: http://myserver3333.com:8080/ws/services
java.io.IOException: Server returned HTTP response code: 500 for URL: http://myserver3333.com:8080/ws/services?wsdl
Which is correct because there is no WSDL at that location, it need to follow the soap header to get the service.
Update:
After two points from #Daniel Kulp I am here:
I added a new line: bindingProvider.getRequestContext().put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY, "http://myserver3333.com:8080/ws/services");
And now I get this error:
org.apache.cxf.binding.soap.SoapFault: "http://www.myserver.com/ws/services", the namespace on the "errorMessage" element, is not a valid SOAP version.
at org.apache.cxf.binding.soap.interceptor.ReadHeadersInterceptor.readVersion(ReadHeadersInterceptor.java:115)
at org.apache.cxf.binding.soap.interceptor.ReadHeadersInterceptor.handleMessage(ReadHeadersInterceptor.java:141)
at org.apache.cxf.binding.soap.interceptor.ReadHeadersInterceptor.handleMessage(ReadHeadersInterceptor.java:60)
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:263)
at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:771)
My assumption is, this error is same as this one. But I am not using ?wsdl. So, any suggestions?
2 comments:
1) You aren't picking up CXF. Check your classpath to make sure CXF is there and not the Sun/Oracle implementation. com.sun.xml.ws.wsdl.parser.InaccessibleWSDLException shows you are picking up the Sun implementation.
2) The URL passed into MyAwesomeService(wsdlLocation) MUST be a URL to the WSDL, not the endpoint itself.
Related
I'm trying to access an old SOAP based system written in C# from a Java backend service. This C# application is looking for an AddressHeader to be populated with a specific value on every request. I'm using Apache CXF to create the requests to this service. Unfortunately, for the life of me, I cannot find out how to add this address header to each of the requests. Does anyone know what the equivalent in Java is and how to add it using Apache CXF?
The address header is the same as the SOAP header, hence we only need to add a particular SOAP header to every request so that be capable of making a successful call.
Here is an example I found on the internet.
ClientProxyFactoryBean factory = new JaxWsProxyFactoryBean();
factory.setServiceClass(singz.ws.cxf.sample.SampleServiceInterface.class);
factory.setAddress("http://xxx.xxx.com/services/SampleService/v1");
SampleServiceInterface serviceClient = (SampleServiceInterface) factory.create();
Client proxy = ClientProxy.getClient(serviceClient);
List<Header> headersList = new ArrayList<Header>();
Header testSoapHeader1 = new Header(new QName("uri:singz.ws.sample", "soapheader1"), "SOAP Header Message 1", new JAXBDataBinding(String.class));
Header testSoapHeader2 = new Header(new QName("uri:singz.ws.sample", "soapheader2"), "SOAP Header Message 2", new JAXBDataBinding(String.class));
headersList.add(testSoapHeader1);
headersList.add(testSoapHeader2);
proxy.getRequestContext().put(Header.HEADER_LIST, headersList);
Please refer to the below links, wish it is useful to you.
https://dzone.com/articles/apache-cxf-how-add-custom-soap-0
How do you add a Soap Header defined in a wsdl to a web service client in CXF?
https://dzone.com/articles/apache-cxf-how-add-custom-soap
Feel free to let me know if there is anything I can help with.
I'm using jersey-client 1.19.4 to test my web application.
If I test with postman, I can find the cookie "JSESSIONID" after 'send' action. And I can find 'jsessionid=...' in ClientResponse.toString(), But ClientResponse.getCookies() returns nothing.
WebResource webResource = client.resource(someUrl);
FormDataMultiPart formData = new FormDataMultiPart();
formData.bodyPart(new FormDataBodyPart("userId", userId));
formData.bodyPart(new FormDataBodyPart("uPasswd", uPasswd));
ClientResponse response = webResource.accept("*/*").type(MediaType.MULTIPART_FORM_DATA_TYPE).post(ClientResponse.class, formData);
System.out.println("response: " + response.toString()); // 'jsessionid' found here
List<NewCookie> cookies = response.getCookies();
System.out.println("# of cookies: " + cookies.size()); // prints "# of cookies: 0"
How can I get "JSESSIONID" from ClientResponse?
JSESSIONID can be set in few different ways. As per
JSR-000315 Java Servlet 3.0 Final Release, chapter 7.1 Session Tracking Mechanisms, following can be used:
Cookies
SSL Sessions
URL Rewriting
In your case it appears that URL Rewriting is being used. The two most common reasons being:
The server is configured not to issue cookies
Your client doesn't support cookies
Since you get the cookie while using Postman it most likely means that your Jersey Client doesn't handle cookies. One way to integrate it with Apache HttpClient using jersey-apache-client as per this answer.
From the mailing list:
http://jersey.576304.n2.nabble.com/Session-Handling-not-working-with-Jersey-Client-td4519663.html
The Jersey client by default uses HttpURLConnection that does not
support cookie management (and thus sessions).
You need to switch to using the Apache HTTP client support.
Then set the following property to true: PROPERTY_HANDLE_COOKIES
DefaultApacheHttpClientConfig config = new
DefaultApacheHttpClientConfig(); config
.setProperty("com.sun.jersey.impl.client.httpclient.handleCookies",
true);
ApacheHttpClient c = ApacheHttpClient.create(config);
Plus you can also use authorization with the Apache HTTP client
integration.
DefaultApacheHttpClientConfig config = new DefaultApacheHttpClientConfig();
config.getState().setCredentials(null, null, -1, "foo", "bar");
ApacheHttpClient c = ApacheHttpClient.create(config);
WebResource r = c.resource("http://host/base");
String s = r.get(String.class);
s = r.post(String.class, s);
I've created a set of proxy classes in NetBeans for a SOAP web service.
I'd like to add an HTTP header to the outgoing request.
Map<String, Object> requestHeaders = new HashMap<>();
requestHeaders.put("X-Header", header);
AccountManagementService service = new AccountManagementService();
AccountManagementServiceSoap soap = service.getAccountManagementServiceSoap();
GetMembershipSummaryResponse.GetMembershipSummaryResult membershipSummary = soap.getMembershipSummary("mikeb#foobar.com");
I saw a bunch of JAX-WS header examples for when you are getting the individual port from the service. Is there an easier way? Can I just add the header to some collection on service or soap object?
after some digging I found this post: jax-ws change Content-type to Content-Type because server is hyper sensitive
which isn't really a full answer, so I am going to post the full answer here:
AccountManagementService service = new AccountManagementService();
AccountManagementServiceSoap soap = service.getAccountManagementServiceSoap();
((BindingProvider)soap).getRequestContext().put(MessageContext.HTTP_REQUEST_HEADERS,
Collections.singletonMap("X-Header",Collections.singletonList(header)));
GetMembershipSummaryResponse.GetMembershipSummaryResult membershipSummary = soap.getMembershipSummary("mikeb#foobar.com");
I have a RESTful Java web service that I built using Jersey. The client for it defines a resource with the following method:
#Override
public String saveWidget(Widget widget) {
return webResource.path("user").type(MediaType.APPLICATION_JSON).entity(widget).post(String.class, Widget.class);
}
Then, a driver using this client:
public class Driver {
public static void main(String[] args) {
WidgetClient client;
WidgetClientBuilder builder = new WidgetClientBuilder();
client = builder.withUri("http://localhost:8080/myapi").build();
Widget w = getSomehow();
String widgetUri = client.getWidgetResource().saveWidget(w);
System.out.println("Widget was saved URI was returned: " + widgetUri);
}
}
When I run this I get:
Exception in thread "main" com.sun.jersey.api.client.UniformInterfaceException: POST http://localhost:8080/myapi/widget returned a response status of 400 Bad Request
at com.sun.jersey.api.client.WebResource.handle(WebResource.java:688)
at com.sun.jersey.api.client.WebResource.access$200(WebResource.java:74)
at com.sun.jersey.api.client.WebResource$Builder.post(WebResource.java:570)
at com.my.myapi.WidgetResource.saveWidget(WidgetResource.java:27)
at com.my.myapi.Driver.main(Driver.java:32)
I know the service endpoint is valid because I can hit it from another (non-Java) web client without issues. This means that either my Widget instance is malformed or that there is something with my Java client method (saveWidget). I ruled out my w Widget being bad by serializing it into JSON, and then copying it into my non-Java web client and POSTing to the same endpoint (no issues arose). So this tells me I have the client method configured wrong. Any ideas?
This is regarding making a call POST call using Jersey client.
For jersey client, default client configuration uses ChunkedEncoding and gzip. This can be checked in request headers for POST call. Content length of payload (JSON String or any object mapper pojo) and request headers received by post call i.e. header name CONTENT-LENGTH, CONTENT-ENCODING. If there is difference, POST call might return 400 bad request. (Something like unable to process JSON). To solve this, you can disable ChunkedEncoding, gzip encoding. Code snippet for the same:
clientConfiguration.setChunkedEncodingEnabled(false);
clientConfiguration.setGzipEnabled(false);
Client client = (new JerseyClientBuilder(environment)).using(clientConfiguration).using(environment).build("HTTP_CLIENT");
WebTarget webTarget = client.target(endpoint);
Response response = webTarget.path(path).request(MediaType.APPLICATION_JSON).post(Entity.json(jsonString));
.post(String.class, Widget.class);
You appear to be posting a Class object, not a Widget object.
I use Netbeans to generate web service client code, client-style JAX-WS, so i can invoke a web service API.
However, when I invoke the web service API, I get the exception:
com.sun.xml.internal.ws.client.ClientTransportException: The server sent HTTP status code 307: Temporary Redirect
Why do I get this? What is the workaround? I know the problem isn't with the web service itself, because I can get responses fine via soapUI and .Net.
Faced the same problem about a month ago.
Web service client classes were generated using Apache CXF and web service returned HTTP
status 307, which led to the same exception.
Invocation of the same web service method using soapUI with property Follow Redirects set to true was successful and returned needed data.
After googling awhile, it looked like there is no property to enable following redirects in the JAX-WS for this.
So, below is the code which is currently working, though I'm not sure it is compliant with any standards:
Supposing generated client classes looks like:
// generated service class
public class MyWebServiceClient extends javax.xml.ws.Service {
// ...
private final QName portName = "...";
// ...
public RetrieveMyObjects getRetrieveMyObjects() {
return super.getPort(portName, RetrieveMyObject.class);
}
// ...
}
// generated port interface
// annotations here
public interface RetrieveMyObjects {
// annotations here
List<MyObject> getAll();
}
Now, upon executing following code:
MyWebServiceClient wsClient = new MyWebServiceClient("wsdl/location/url/here.wsdl");
RetrieveMyObjectsPort retrieveMyObjectsPort = wsClient.getRetrieveMyObjects();
wsClient should return instance which is both instance of RetrieveMyObjects & javax.xml.ws.BindingProvider interfaces. It is not stated anywhere on the surface of JAX-WS, but it seems that a lot of code is based on that fact. One can re-assure him\herself by executing something like:
if(!(retrieveMyObjectsPort instanceof javax.xml.ws.BindingProvider)) {
throw new RuntimeException("retrieveMyObjectsPort is not instance of " + BindingProvider.class + ". Redirect following as well as authentication is not possible");
}
Now, when we are sure that retrieveMyObjectsPort is instance of javax.xml.ws.BindingProvider we can send plain HTTP POST request to it, simulating SOAP request (though it looks incredibly incorrect & ugly, but this works in my case and I didn't find anything better while googling) and check whether web service will send redirect status as a response:
// defined somewhere before
private static void checkRedirect(final Logger logger, final BindingProvider bindingProvider) {
try {
final URL url = new URL((String) bindingProvider.getRequestContext().get(ENDPOINT_ADDRESS_PROPERTY));
logger.trace("Checking WS redirect: sending plain POST request to {}", url);
final HttpURLConnection connection = (HttpURLConnection) url.openConnection();
connection.setInstanceFollowRedirects(true);
connection.setRequestMethod("POST");
connection.setRequestProperty("Content-Type", "text/html; charset='UTF-8'");
connection.setDoOutput(true);
if(connection.getResponseCode() == 307) {
final String redirectToUrl = connection.getHeaderField("location");
logger.trace("Checking WS redirect: setting new endpoint url, plain POST request was redirected with status {} to {}", connection.getResponseCode(), redirectToUrl);
bindingProvider.getRequestContext().put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY, redirectToUrl);
}
} catch(final Exception e) {
logger.warn("Checking WS redirect: failed", e);
}
}
// somewhere at the application start
checkRedirect(logger, (BindingProvider) retrieveMyObjectsPort);
Now, what this method does is: it takes BindingProvider.ENDPOINT_ACCESS_PROPERTY of retrieveMyObjectsPort i.e. the url to which this port method will be sending SOAP requests and sends plain HTTP POST request as described above. Then it checks whether response status is 307 - Temporary Redirect (other statuses like 302 or 301 may also be included) and if it is, gets the URL to which web service is redirecting and sets new endpoint for the specified port.
In my case this checkRedirect method is called once for each web service port interface and then everything seems to work fine:
Redirect is checked on url like http://example.com:50678/restOfUrl
Web service redirects to url like https://example.com:43578/restOfUrl (please note that web service client authentication is present) - endpoint of a port is set to that url
Next web service requests executed via that port are successful
Disclaimer: I'm quite new to webservices and this is what I managed to achieve due to the lack of solutions for this questions, so please correct me if something is wrong here.
Hope this helps
Yes I know this post is old, but I've had similar errors, and thought maybe somebody would benefit from my solution.
the one that plagued me the most was:
com.sun.xml.ws.client.ClientTransportException: The server sent HTTP status code 200: OK
Which turns out to mean an incomplete response header. Apparently jax-ws does some kind of validation that includes validating the HTTP headers as well. And the server I was using was just sending an empty header.
It worked like a charm after adding 'application/soap+xml' to the Content-Type header.