I went a different route and tried doing things top-down from the WSDL (see attached) and things worked as expected:
Request: <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"; xmlns:test="http://test.webservices.bat.mathworks.com";> <soapenv:Header/> <soapenv:Body> <test:getEmployeeIdRequest> <test:fullname>Bogus</test:fullname> </test:getEmployeeIdRequest> </soapenv:Body> </soapenv:Envelope> Returned Fault: <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";> <soapenv:Body> <soapenv:Fault> <faultcode>soapenv:Server</faultcode> <faultstring>EmployeeNotFoundException</faultstring> <detail> <ns2:EmployeeNotFoundFault xmlns:ns2="http://test.webservices.bat.mathworks.com";> <ns2:severity>Cataclysmic</ns2:severity> <ns2:retryable>false</ns2:retryable> </ns2:EmployeeNotFoundFault> </detail> </soapenv:Fault> </soapenv:Body> </soapenv:Envelope> Whatever name you give the message becomes the type of exception that the service method throws; whatever element that message refers to is the type that eventually appears in the details. More reasons to stick to the top-down approach. If the attachments don't get through, let me know and I'll in-line them. -Eric From: Manuel Darveau [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 18, 2008 10:10 AM To: axis-user@ws.apache.org Subject: Re: AXIS2-3239, 3443 Hi, I digged in the code and I think the fix should be around org.apache.axis2.util.MessageContextBuilder:614 or directly on AxisFault.makeFault(). I have a workaround that consist of injecting the detail on the generated AxisFault. For example, if my operation's wsdl is: ... <xs:schema attributeFormDefault="qualified" elementFormDefault="unqualified" targetNamespace="http://ws.ACME.com";> <xs:complexType name="Exception"> <xs:sequence> <xs:element minOccurs="0" name="Exception" nillable="true" type="xs:anyType"/> </xs:sequence> </xs:complexType> <xs:element name="UnauthorizedAccessException"> <xs:complexType> <xs:sequence> <xs:element minOccurs="0" name="UnauthorizedAccessException" nillable="true" type="ax21:UnauthorizedAccessException"/> </xs:sequence> </xs:complexType> </xs:element> </xs:schema> ... <wsdl:operation name="getSomething"> <wsdl:input message="ns:getSomethingRequest" wsaw:Action="urn:getSomething"/> <wsdl:output message="ns:getSomethingResponse" wsaw:Action="urn:getSomethingResponse"/> <wsdl:fault message="ns:UnauthorizedAccessException" name="UnauthorizedAccessException" wsaw:Action="urn:getSomethingUnauthorizedAccessException"/> </wsdl:operation> ... I can do in my service: AxisFault af = AxisFault.makeFault(new UnauthorizedAccessException()); af.setDetail(new OMElementImpl("UnauthorizedAccessException", new OMNamespaceImpl("http://ws.ACME.com";, "whatever_alias"), new OMDOMFactory())); throw af; Note that I can't write a generic exception handler that will trap any exception and inject the details since I don't know how to determine the namespace used when defining the exception in the WSDL. I *think* it will always be the service namespace but I am not sure. Also, I don't this the "new OMDOMFactory()" part is really clean... Any other solution? Manuel On Tue, Nov 18, 2008 at 9:44 AM, Eric Decosta <[EMAIL PROTECTED]<mailto:[EMAIL PROTECTED]>> wrote: I'm interested in a fix as well; it seems that part of the issue is that AxisFault.makeFault() doesn't fill-in the Detail element of the Fault. Following this example: : http://svn.apache.org/viewvc/webservices/axis2/trunk/java/modules/integration/test/org/apache/axis2/engine/util/FaultThrowingService.java?view=markup You can generate just about anything you want for a Fault, but I'd expect that if I specified something in the soap:fault for the service that Axis2 handle things automatically. I'm just making some guesses here as I haven't spent much time rummaging around in the Axis2 code base. -Eric From: Manuel Darveau [mailto:[EMAIL PROTECTED]<mailto:[EMAIL PROTECTED]>] Sent: Monday, November 17, 2008 4:21 PM To: axis-user@ws.apache.org<mailto:axis-user@ws.apache.org> Subject: AXIS2-3239, 3443 Hi all, I known this is a tough question (and most probably better suited for axis-dev) but do you have any idea when bug 3239 (and eventually 3443) will be fixed. Do you have a target? In short, the bug is about custom exception handling in the code first approach. When you develop a service that throws custom exception(s), the WSDL is correctly created including the custom faults but the resulting implementation always convert custom exceptions into AxisFault. This make it difficult/impossible for clients to catch custom/specific exception. This is not a show stopper but definitely an annoyance for me. I know you will say: "it's open source, you can propose a patch" but I would like to know if a fix is already in progress. Do you have any pointer for me on where to look for a fix? Thank you! Manuel
TestService.wsdl
Description: TestService.wsdl
TestServiceSkeleton.java
Description: TestServiceSkeleton.java
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
