[ 
http://issues.apache.org/jira/browse/AXIS2-917?page=comments#action_12426933 ] 
            
Richard Gruet commented on AXIS2-917:
-------------------------------------

I'm having exactly the same problem as Derek with WSDL2Java w/ XmlBeans data 
binding. A XxxFault is generated for my custom fault detail. But WS operations 
declared as throwing this fault are mapped to a method throwing another 
exception (xxxFaultException,  defined as an inner class of the implementation 
skeleton, as pointed out in AXIS2-198). This is understandable since an 
XxxFault is a document, not a Java exception, so it needs to be wrapped. It 
could have been into an AxisFault, but having a custom Exception is arguable 
too (it is more specialized). But it seems that the generated xxxFaultException 
has no room for a SOAP faultString or faultCode (while the AxisFault has), so 
one may wonder at this stage how this information can be returned. 

It is possible to assign a XxxFault document instance to the xxxFaultException 
instance via setFaultMessage(), and then throw the XxxFaultException from the 
implementation. But when I follow this strategy (raising a xxxFaultException ), 
I get an error in my client test case: Expected a XxxFaultException, received: 
org.apache.axiom.om.OMException: java.lang.IllegalStateException.

I'm currently evaluating Axis2 for my company (vs XFire), and handling faults 
correctly is critical for me (and in any serious framework, IMO). I hope that 
this problem will be adressed urgently... because I have to make my decision in 
a few days :(

Richard



> User guide should give explanation and examples of fault handling
> -----------------------------------------------------------------
>
>                 Key: AXIS2-917
>                 URL: http://issues.apache.org/jira/browse/AXIS2-917
>             Project: Apache Axis 2.0 (Axis2)
>          Issue Type: Wish
>          Components: samples, build,site  & docs
>    Affects Versions: 1.0
>            Reporter: Derek Foster
>         Assigned To: Eran Chinthaka
>            Priority: Critical
>
> The Axis2 user guide provides no examples of:
>   1) The WSDL to declare that a fault may be thrown from an operation 
> (suitable for passing into WSDL2Java)
>   2) The server-side code for a fault exception, as generated by WSDL2Java 
> and modified as a user might be expected to modify it.
>   3) The server-side code to throw the fault exception, including a tested 
> example of passing on a custom error message to be transmitted as part of a 
> SOAP fault (in the faultDetail) and received by the client.
>   4) The client-side code for receiving and handling a fault.
> Furthermore, what discussion of faults that there is seems fairly 
> contradictory. For instance, there are various suggestions that throwing an 
> AxisFault exception from a service is the way to issue a fault. However, 
> WSDL2Java does not generate service methods that are declared to throw 
> AxisFault, and there seems to be no way to declare such a fault in WSDL. (at 
> least, none that I can find). Fault generation from a service that was not 
> generated by WSDL2Java should be treated as a separate section, since it is 
> handled in a totally different manner by server code. I think that both kinds 
> of fault handling need to be documented clearly in the user guide.
> I have been trying for weeks to figure out how this is supposed to work, and 
> still haven't gotten it to work quite right (my custom error message included 
> in the thrown fault exception is getting lost somewhere before the SOAP fault 
> is transmitted). This is a basic feature that should be documented clearly.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to