Thilina Mahesh Buddhika http://blog.thilinamb.com
On Mon, Jan 10, 2011 at 11:34 AM, Selvaratnam Uthaiyashankar < [email protected]> wrote: > On Mon, Jan 10, 2011 at 10:42 AM, Amila Jayasekara <[email protected]> > wrote: > > Hi All, > > > > I am having a question related to Error handling. I learn t that there > are 2 > > kinds of errors. > > > > Errors that could occur from calling services (Business errors) > > > > Errors that might occur when executing framework code > > > > Both types of errors are reported as AxisFaults. Thus we apply policy to > > faults also. I am concerned about 2nd types of errors. The issue I am > having > > is best explained using following example, > > > > Say, I have a web service with sign only security policy applied. Thus > > mistakenly I give a wrong keystore alias for server side policy. Now > client > > sends a request and service needs to send a response. But when service > tries > > to sign the response it gets an error. This error is reported as an > > AxisFault. But there is a sign only policy applied, therefore server > again > > tries to sign the error (AxisFault). Again Rampart gets the same error. > > Since Axis2 framework is removing erroneous phases in an AxisFault this > > doesnt goes in a recursive loop. But a HTML page with “HTTP/1.1 500” is > > returned to the client. This behavior is reported as an issue in [1]. > > > > I am not quite sure about the best possible way to handle this kind of > > errors. (Handling framework errors when a policy applied). Also I didnt > find > > specific spec instructions on how to handle framework failures in a this > > kind of scenario. To my understanding we have following options, > > > > Leave the current behavior as it is. i.e. Return a HTTP/1.1 500 error to > > client. > > > > If there is an AxisFault, try to apply policy to AxisFault. If framework > > gets an error while applying policy to AxisFault, return original > AxisFault > > (AxisFault before applying policy) to client. > > +1 for this approach. > > > > > Again this method has a limitation if there is a policy applied in client > > side also. E.g :- If client only accepts signed messages, client will > give > > an error saying that the incoming message (AxisFault) is not signed. > > But, this is ok, since the error is a server side configuration error, > and should never occur. > > > > > Please give feedback on what the best way to resolve this issue. Also if > > there are more suitable options please let us know. > > > AFAIK, in .NET, if you make a configuration mistake, the service will > not get deployed. That is one of the path we also can look into. > > Is there any possibility of validating the policy at the time of > service deployment, and mark them as faulty services? > +1 for the second option. +1. IMO this will be really useful. We can implement something similar to an AxisObserver in Rampart which does the basic validation when deploying a service. I doubt whether we can cover all the possible cases which might lead to to a faulty service, but still this approach can cover a lot of ground. Thanks, Thilina > Regards, > Shankar > > > > > [1] https://issues.apache.org/jira/browse/RAMPART-305 > > > > Thank you > > > > AmilaJ > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
