Mysterious error in SOAP when JAX-WS receives the response - java

I receive the following error when I'm trying to send a SOAP message.
The thing that has me confused, is that it seems like
Something fails in the C layer, the message "Object reference not set to an instance of an object." is a typical .net message if I recall.
It happens deep in the SOAP handler.
It happens when it receives the response.
It looks to me that it actually fails, trying to create an error message.
I'm using Glassfish 3.1.2.2, with its default SOAP framework (JAX-WS if I recall)
Any pointers on how to trace this error, and possibly get the actual received SOAP response, to see if it is the one to blame?
I have to add that I'm NOT a SOAP expert by any means of the definition. I just have to figure our why this fails. Unfortunately.
Stack trace:
com.sun.xml.ws.fault.ServerSOAPFaultException: Client received SOAP Fault from server: Object reference not set to an instance of an object. Please see the server log to find more detail regarding exact cuase of the failure.
at com.sun.xml.ws.fault.SOAP11Fault.getProtocolException(SOAP11Fault.java:193)
at com.sun.xml.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:134)
at com.sun.xml.ws.client.sei.StubHandler.readResponse(StubHandler.java:247)
at com.sun.xml.ws.db.DatabindingImpl.deserializeResponse(DatabindingImpl.java:177)
at com.sun.xml.ws.db.DatabindingImpl.deserializeResponse(DatabindingImpl.java:256)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:128)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:102)
at com.sun.xml.ws.client.sei.SEIStub.invoke(SEIStub.java:151)

This error is very hard to troubleshoot without any additional information like the SOAP request or the service WSDL.
Some things you can check in your code:
are your objects properly initialized?
do all attributes have the correct type?
check for null values

Related

In case of an exception in webservice is the control returned to to UI with error?

I have a UI page developed using angular js and make a rest webservice call. If an exception is thrown by webservice will the control be returned to the UI with the error?
yes, it will be returned to the client. This is true even if the server timesouts.
But it might not be in a format as you expected. For example, you might have sent a json request and expecting a json response. But you might get an html response if the server has setup a simple html handler for error code. In this case your response parsing will fail. One common example is the authentication failure, which simply redirects you to html login page in many services.
So before parsing the result, check the status code. Check the service rest api docs and study the error handling semantics. Then parse the error accordingly.

Is there a way to know the cause of failure while sending a text message through Twilio

I need to know the cause of failure during sending texts through twilio.
Currently, I do something like this sid = gateway.send(params);
If sid is null I assume that sending failed. Is there a way to know the cause of failure status ?
I saw this : https://www.twilio.com/docs/api/rest/sms#sms-status-values
And reading this, I think it is not possible to know the reason for failure, is it ?
Twilio evangelist here.
So I'm not exactly sure if I understand your question, so I'll give you two possible answers. Both assume you are using the Twilio Java helper library.
1) How do I get the error details when a request to the Twilio REST API fails (eg the API returns a 400 Bad Request response)?
If you make a request to the Twilio API and pass in bad credentials, or bad request parameters, the Java library will throw an exception. You can read more about how to handle exceptions thrown by the Java library here:
https://www.twilio.com/docs/java/install
A list of the errors that Twilio will return is here:
https://www.twilio.com/docs/errors/
2) How to I know if a message that I have asked Twilio to deliver fails to get delivered?
When you call the create method the library will return you an instance of a Message object:
Message sms = messageFactory.create(params);
This basically asked Twilio to send a message to a carrier who will deliver it to a phone. Sometimes we can't get the message to the carrier, and when that happens we set the status of the message to 'Failed'. You can get the status value from the Message object:
http://twilio.github.io/twilio-java/com/twilio/sdk/resource/instance/Message.html
Note that its likely that the initial value of the status parameter may be 'queued'. If thats the case and you still want to be notified if the message failed then I could suggest using the Status Callback feature. This lets you give Twilio a URL that we will request when the message status changes.
Hope that helps.

Transport level information does not match with SOAP Message namespace URI

I'm getting the error "Transport level information does not match with SOAP Message namespace URI". Request you provide the details to fix the issue.
I have set the below in the client side.
HttpTransportProperties.ProxyProperties proxyProperties = new HttpTransportProperties.ProxyProperties();
proxyProperties.setProxyName(proxyAddress);
proxyProperties.setProxyPort(proxyPort);
stub._getServiceClient().getOptions().setProperty(HTTPConstants.CHUNKED,Boolean.FALSE);
stub._getServiceClient().getOptions().setProperty(HTTPConstants.PROXY, proxyProperties);
stub._getServiceClient().getOptions().setProperty(HTTPConstants.HEADER_CONTENT_TYPE,"application/soap+xml");
stub._getServiceClient().getOptions().setProperty("type","application/soap+xml");
stub._getServiceClient().getOptions().setProperty(HTTPConstants.HEADER_SOAP_ACTION, Action_URL);
stub._getServiceClient().getOptions().setProperty ( HTTPConstants.HTTP_PROTOCOL_VERSION, HTTPConstants.HEADER_PROTOCOL_11 ) ;
stub._getServiceClient().getOptions().setProperty ( "Transfer-Encoding", "chunked" ) ;
stub._getServiceClient().getOptions().setProperty(HTTPConstants.REUSE_HTTP_CLIENT, "true");
Can you please help to solve the issue?
That error occurs if there is a mismatch between the content type and the SOAP version (as determined by the namespace URI of the SOAP envelope) of the received message. E.g. if Axis2 receives a SOAP 1.2 message with content type text/xml, it will trigger that error.
Joe - If you are getting this error, then I am assuming that you are trying to access a service that is really old and you might be using Axis that is version 2.0 . You will not be able to call the service by creating client using Axis or CXF. I have spent days trying to figure this out. Eventually I ended up using SAAJ API to create the request WSDL and post it to the service.
It is very easy and keeps you away from trying to figure out RPC/Literal/Document style etc.
See this post - Post

Response code is null while executing Axis2 webservice client in java but webservice executed successfully at the server end

I am working on axis2 webservice in java for insertion of records into database. i am testing the webservice client, it return null response code, actually i return integer value in webservice but i inserted the records in database successfully, i can able to see in my databnase while executing the client but it return null instead of integer response code 100.whenever i see the log file in server side, no exception rises.
I have faced similar issue, i resolved it through message inspector.
Implement message inspector IClientMessageInspector capture and correct your response at AfterReceiveReply
Please provide your response to help you.

Interview Question - How to handle SOAP Based and REST based Exceptions

Can some one provide a very specific and to the point answer for this question ?
I think the basics of it are, with REST you should return the proper http response code and enough information for the client to correct the error, e.g. 404 if the resource can't be found, 400 if they client sent a bad request, 500 if the server generated an exception, etc. With SOAP it looks like you always have to return a 500 Response code and a special SOAP message that says exactly what the error was (according to the SOAP spec).
Here is a blog post comparing the two.

Categories