Hi all!
Comments inline.
Eran Chinthaka wrote:
* Further debugging showed me Axis2 defaults to FaultCode Sender if
the faultcode is null and if the there isn't a SOAPEnvelope (line 484-
MessageContextBuilder), which is the exact case when throwing an
exception from the messageReceiver...
Yes this I did intentionally. The reason is that if there is no fault
code, what will be the default fault code? When I was writing this code
I searched this in SOAP 1.2 spec[1] and WS-I BP also but couldn't find one.
So I assumed whatever the service implementation is always correct and
it is client that is always wrong if there is a problem :). Well you
have to make either the sender or receiver guilty if you have to guess
at one point. So I selected to make sender guilty.
I'm not sure it's a huge deal, but I think this was the wrong decision.
The Sender fault code indicates to the sender that there's a good chance
that if they were to fix some problem in their message and try again,
the request might succeed. In the case of a random fault thrown by some
component in the Axis2 processing chain, I don't think we have any such
knowledge. There are really two issues here - one is that we SHOULD
make it easier to be more clear about whether a fault is due to sender
error or a server problem. The second is what we should do when we
really have no idea. I think this is exactly equivalent to what Tomcat
or Apache have to do when a generic exception is caught - the answer
there is typically an HTTP 500 "General Server Error" or the like. The
SOAP equivalent is not a Sender fault, but a Receiver one, so I think
that should be our default.
As for the issue of ease-of-use, perhaps we should consider extending
AxisFault with a "SenderFault" class (which would set the fault code
explicitly to Sender), and then custom exceptions which had to do with
bad data could extend or throw that? I.e.
class MyMessageReceiver {
public invokeBusinessLogic() {
if (value > max) throw new SenderFault("Out of range!");
if (somethingElseBad) throw new AxisFault("Failed");
}
}
* Then in the AxisServlet (line 385) when using SOAP12 we are setting
the response http status code to BAD_REQUEST(400) if the FaultCode is
sender which was the result of the SOAPFault with http-400...
According to RFC2616 HTTP 400 is the correct HTTP status code if the
fault is with the client. Also according to SOAP 1.2 HTTP binding[2]
status code should be 400 when the fault code is Sender
+1
* Axis2 client does not process the body of the message if the http
status code is 400...
I think this can be a bug in Axis2 code as status code 400 doesn't mean
it should not process this.
+1, we should definitely be looking for SOAP faults unless there's a
known code like 404. But we need to make sure we handle HTML responses
from servers too if at all possible.
Thanks,
--Glen
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
