-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
+1 for a SenderFault AND also for a ReceiverFault classe as that eases
users requiring to understand SOAP Fault codes and Axis2 fault processing ;)
Chinthaka
Glen Daniels wrote:
> 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]
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGgelcjON2uBzUhh8RAvFEAJ0Qyt09L7dvRDohcTLVIg69y9fK1QCgl2mI
5wuY2N/LkmBaBfzogmIYfj0=
=N3zd
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
