We Keep Coding

Different result/output for same wsdl in Postman, SOAP UI, jdeveloper Http Analyzer

I have a wsdl url which is giving different result when I am testing with Postman, SOAP UI, Jdeveloper Http Analyzer even tough passing same request header and body in all tools.
In Postman, Jdeveloper Http Analyzer it's wsdl returning same 500-Internal server error.
In SOAP UI, it's returning correct result.
I have created Custom Java client application in jdeveloper to consume webservice, in that I am getting below error
The Error
Exception in thread "main" com.sun.xml.internal.ws.server.UnsupportedMediaException: Unsupported Content-Type: application/xml Supported ones are: [text/xml]
at com.sun.xml.internal.ws.encoding.StreamSOAPCodec.decode(StreamSOAPCodec.java:220)
at com.sun.xml.internal.ws.encoding.StreamSOAPCodec.decode(StreamSOAPCodec.java:151)
at com.sun.xml.internal.ws.encoding.SOAPBindingCodec.decode(SOAPBindingCodec.java:299)
at com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.createResponsePacket(HttpTransportPipe.java:268)
at com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.process(HttpTransportPipe.java:217)
at com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.processRequest(HttpTransportPipe.java:130)
at com.sun.xml.internal.ws.transport.DeferredTransportPipe.processRequest(DeferredTransportPipe.java:95)
at com.sun.xml.internal.ws.api.pipe.Fiber.__doRun(Fiber.java:1121)
at com.sun.xml.internal.ws.api.pipe.Fiber._doRun(Fiber.java:1035)
at com.sun.xml.internal.ws.api.pipe.Fiber.doRun(Fiber.java:1004)
at com.sun.xml.internal.ws.api.pipe.Fiber.runSync(Fiber.java:862)
at com.sun.xml.internal.ws.client.Stub.process(Stub.java:448)
at com.sun.xml.internal.ws.client.sei.SEIStub.doProcess(SEIStub.java:178)
at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:93)
at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:77)
at com.sun.xml.internal.ws.client.sei.SEIStub.invoke(SEIStub.java:147)
at com.sun.proxy.$Proxy36.getService(Unknown Source)
at someClient.SomeClient.main(WaselClient.java:23)
How can i solve this issue?

When I am importing wsdl into SOAPUI request payload is loading without spaces in the header parameter.
for eg., content-type=”text/xml;charset=utf-8”(check there is no gap between xml; and charset),
where as in postman and jdeveloper http analyzer request payload is loading with spaces in the header parameter. content-type=”text/xml; charset=utf-8”(check there is a gap between xml; and charset).
Due to this it was giving different result.

Apache Camel received Status 400 Bad Request from AWS VPC Endpont

I have a Java application which was built with Apache Camel. The application uses Apache Camel to construct an HTTP request to AWS VPC Endpoint.
When the Java application sends out an HTTP request, it receives HTTP Status Code 400 (Bad Request). The VPC Flow Log can be found with the traffic (correct source and destination IP addresses).
On the other hand, if we use curl command to send the same HTTP request, it turns back 200 OK.
What is a possible cause? Is there any configuration in Apache Camel to see what is the exact HTTP content or raw HTTP header/message sent out?

You could check if Content-Type and other mandatory request headers are available at Exchange.in.headers. Just log in.headers within camel-simple tag. I think 400 happening because improper content-type or bad payload.

It might be that you are sending headers that are not allowed by the API since Camel maps message headers automatically to HTTP headers.
Camel's camel-http4 component uses Apache HttpClient 4.x library and you can configure it to log raw http requests.
For instance with log4j you would add to properties:
log4j.logger.org.apache.http=DEBUG
Detailed logging options can be seen from here: https://hc.apache.org/httpcomponents-client-4.5.x/logging.html

How do i consume the w3schools tempCnvertor webservice from the wsdl with netbeans?

I have been trying to consume the w3schools tempConvertor webservice from
https://www.w3schools.com/xml/tempconvert.asmx?WSDL
it gives me this warning messages just before generating the client classes
parsing WSDL...
[WARNING] SOAP port "TempConvertSoap12": uses a non-standard SOAP 1.2
binding. line 147 of
file:/C:/Users/Bigesta/Documents/NetBeansProjects/JavaebServiceDemo/xml-resources/web-service-references/tempconvert/wsdl/www.w3schools.com/xml/tempconvert.asmx.wsdl
[WARNING] Port "TempConvertHttpPost" is not a SOAP port, it has no
soap:address line 150 of
file:/C:/Users/Bigesta/Documents/NetBeansProjects/JavaebServiceDemo/xml-resources/web-service-references/tempconvert/wsdl/www.w3schools.com/xml/tempconvert.asmx.wsdl
[WARNING] port "TempConvertHttpPost": not a standard SOAP port. The
generated artifacts may not work with JAX-WS runtime. line 150 of
file:/C:/Users/Bigesta/Documents/NetBeansProjects/JavaebServiceDemo/xml-resources/web-service-references/tempconvert/wsdl/www.w3schools.com/xml/tempconvert.asmx.wsdl
Generating code...
https\www_w3schools_com\xml\CelsiusToFahrenheit.java
https\www_w3schools_com\xml\CelsiusToFahrenheitResponse.java
https\www_w3schools_com\xml\FahrenheitToCelsius.java
https\www_w3schools_com\xml\FahrenheitToCelsiusResponse.java
https\www_w3schools_com\xml\ObjectFactory.java
https\www_w3schools_com\xml\TempConvert.java
https\www_w3schools_com\xml\TempConvertHttpPost.java
https\www_w3schools_com\xml\TempConvertSoap.java
https\www_w3schools_com\xml\package-info.java Copying 9 files to
C:\Users\Bigesta\Documents\NetBeansProjects\JavaebServiceDemo\build\generated-sources\jax-ws
BUILD SUCCESSFUL (total time: 8 seconds)
When ever i try to call the service i get this exceptions
Exception in thread "main"
com.sun.xml.internal.ws.client.ClientTransportException: The server
sent HTTP status code 301: Moved Permanently at
com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.checkStatusCode(HttpTransportPipe.java:310)
at
com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.createResponsePacket(HttpTransportPipe.java:259)
at
com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.process(HttpTransportPipe.java:217)
at
com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.processRequest(HttpTransportPipe.java:130)
at
com.sun.xml.internal.ws.transport.DeferredTransportPipe.processRequest(DeferredTransportPipe.java:95)
at com.sun.xml.internal.ws.api.pipe.Fiber.__doRun(Fiber.java:1121)
at com.sun.xml.internal.ws.api.pipe.Fiber._doRun(Fiber.java:1035) at
com.sun.xml.internal.ws.api.pipe.Fiber.doRun(Fiber.java:1004) at
com.sun.xml.internal.ws.api.pipe.Fiber.runSync(Fiber.java:862) at
com.sun.xml.internal.ws.client.Stub.process(Stub.java:448) at
com.sun.xml.internal.ws.client.sei.SEIStub.doProcess(SEIStub.java:178)
at
com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:93)
at
com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:77)
at
com.sun.xml.internal.ws.client.sei.SEIStub.invoke(SEIStub.java:147)
at com.sun.proxy.$Proxy31.fahrenheitToCelsius(Unknown Source) at
javaebservicedemo.JavaebServiceDemo.fahrenheitToCelsius(JavaebServiceDemo.java:26)
at
javaebservicedemo.JavaebServiceDemo.main(JavaebServiceDemo.java:19)
How can i make it work?

When the WSDL is parsed the warnings are stating that the WSDL is not following SOAP 1.2 binding conventions in particular: SOAP port has no soap:address. This WSDL maybe trying to support both SOAP 1.1 and 1.2
The response you are getting is 301: Moved Permanently which is trying to redirect you.
There is an example here: https://www.w3schools.com/xml/tempconvert.asmx?op=FahrenheitToCelsius
However, when I use the post example I get a 500 server error which isn't a good sign.
To save time I recommend using a tool like SOAPUI to test and validate the service is working before creating your demo. You could try and use a different service such as http://www.webservicex.net/ConvertTemperature.asmx?WSDL

What is expected response when server throws application exception like IllegalArgrumentException?

When I make a rest request and server throws an application exception like IllegalArgumentException, I get response with http status 404.
Wouldn't a response with http status 500 be better?
Or what would actually be the expected response when an application exception is thrown? Is there some default behaviour in resteasy, spring or tomcat itself?
I know I can use an ExceptionMapper for resteasy, but is this really best practice or is there a better alternative?
I'm using following setup:
spring
resteasy
tomcat 7
Update:
The problem I'm facing is that I have 2 web applications, one is returning http status 500 and the other is returning http status 400 when an IllegalArgumentException is thrown. I can't figure out why they behave different. It seems to me, that both web application have the same spring and resteasy configuration.
When I'm debugging, I see that resteasy is transforming the IllegalArgumentException to a org.jboss.resteasy.spi.UnhandledException, but the response and the response status code, respectively, is not touched.
So besides not knowing which http status code would be the expected one (400, as Jon Skeet and Stefano Cazzola already pointed out), I didn't know either why the 2 web applications behaves different.
I couldn't find any resteasy ExceptionMapper in both web application.
So is there some default behavior in resteasy, spring or tomcat, which is mapping an IllegalArgumentException to http status 404 or http status 500? Or how can this happen?

The response code is correlated to the error happened in the server. If the error is related to an invalid input received from the client, then the formally correct response status is 400 (Bad Request). The difference with 500 is that returning 400 is the correct behaviour for the server: means, the server processed correctly and responded with an error because the request was wrong. If the same request will ever be resubmitted, it will receive the same error response. The server is not supposed to correct this error, it is up to the client.
You can take this link as a reference

Issue with Connecting to WCF Service using Metro - HTTP Works, HTTPS does not

I am connecting to a WCF web service with a Java client I am constructing. Someone else has already successfully built WCF clients to connect to this service. The WSDL available via HTTP provides Message Level Security. The WSDL available via HTTPS uses both TLS and Message Level Security. I understand that using TLS on top of Message Level Security is basically dual-encrypting, but that is a key requirement.
Since I can connect to the HTTP service correctly, I believe I have all the trust store and key store issues resolved.
I am connecting to the service using Metro 2.1.1. I have built the client in both Eclipse and Netbeans. I fetch the WSDL from the HTTP site, and using wsimport (with the -extensions flag) I build and execute the clients successfully.
When I fetch the WSDL using the HTTPS site I can again build both clients successfully. But when I execute them - I get the following error:
Exception in thread "main" javax.xml.ws.soap.SOAPFaultException: An error occurred when verifying security for the message.
at com.sun.xml.ws.fault.SOAP12Fault.getProtocolException(SOAP12Fault.java:225)
at com.sun.xml.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:122)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:119)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:89)
at com.sun.xml.ws.client.sei.SEIStub.invoke(SEIStub.java:140)
at $Proxy43.request(Unknown Source)
The only difference between the two WSDLs (the one fetched via HTTP and the other via HTTPS) is the reference in the WSDL to HTTPS:// vs. HTTP://.
I do not have easy access to the WCF service logs - normally there is a 3-6 hour delay between when I request a set of logs and when I can view them.
My question is has anyone encountered a similar circumstance - and is there something I am blatantly missing here? Is there something in a NetMon or Wireshark trace I can look for to see that the issue is? I have been struggling with this for days - any help would be most appreciated.

If you have access to the service configuration try disabling security context on the endpoint you're using:
<message establishSecurityContext="False" clientCredentialType="UserName"/>
You can read more about security context token (SCT):
Security Context Token
Message security knobs
Java client for WCF service with wsHttpBinding over SSL