Thanks Eric. I check the code generated usin wsdl2java -ss -uri TestService.wsdl. The catch(EmployeeNotFoundException) in TestServiceMessageReceiverInOut.invokeBusinessLogic does the job of injecting the detail in the axis fault. This is done in a somewhat complicated way and it depends on generated constants in EmployeeNotFoundException.
When you use the bottom up approach, the Exception (in this case EmployeeNotFoundException) will not be filled with axis stuff so it is not that easy to convert it back to XML. I guess I will have to did again in axis code to see how an Object is converted into XML and simply convert my exception and put the result (which should be a OMElement) in the detail of the AxisFault. Any axis dev has advice on how to convert my exception into a OMElement? Manuel On Tue, Nov 18, 2008 at 11:33 AM, Eric Decosta <[EMAIL PROTECTED]>wrote: > 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:* [email protected] > *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]> > 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] > *Sent:* Monday, November 17, 2008 4:21 PM > *To:* [email protected] > *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 > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] >
