Yes, Axis2 injects the detail into the AxisFault there, but I had to add that
detail via setFaultMessage() in TestServiceSkeleton before throwing the fault.
Skeleton:
EmployeeNotFoundException e =
new EmployeeNotFoundException("Could not find employee: " +
getEmployeeIdRequest.getFullname());
EmployeeNotFoundFault msg = new EmployeeNotFoundFault();
msg.setRetryable(false);
msg.setSeverity("Fatal");
e.setFaultMessage(msg);
throw e;
MessageReceiver
} catch (EmployeeNotFoundException e) {
msgContext.setProperty(org.apache.axis2.Constants.FAULT_NAME,
"EmployeeNotFoundFault");
org.apache.axis2.AxisFault f = createAxisFault(e);
if (e.getFaultMessage() != null) {
f.setDetail(toOM(e.getFaultMessage(), false));
}
throw f;
}
private org.apache.axis2.AxisFault createAxisFault(java.lang.Exception e) {
org.apache.axis2.AxisFault f;
Throwable cause = e.getCause();
if (cause != null) {
f = new org.apache.axis2.AxisFault(e.getMessage(), cause);
} else {
f = new org.apache.axis2.AxisFault(e.getMessage());
}
return f;
}
private org.apache.axiom.om.OMElement toOM(
com.mathworks.bat.webservices.test.EmployeeNotFoundFault param,
boolean optimizeContent) throws org.apache.axis2.AxisFault {
try {
return param
.getOMElement(
com.mathworks.bat.webservices.test.EmployeeNotFoundFault.MY_QNAME,
org.apache.axiom.om.OMAbstractFactory
.getOMFactory());
} catch (org.apache.axis2.databinding.ADBException e) {
throw org.apache.axis2.AxisFault.makeFault(e);
}
}
EmployeeNotFoundFault.getOMElement() which is where things get set up for an
eventual call to serialize(). serialize() is where all the nitty-gritty
happens.
-Eric
From: Manuel Darveau [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 18, 2008 12:31 PM
To: [email protected]
Subject: Re: AXIS2-3239, 3443
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]<mailto:[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]<mailto:[EMAIL PROTECTED]>]
Sent: Tuesday, November 18, 2008 10:10 AM
To: [email protected]<mailto:[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]<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: [email protected]<mailto:[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]<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: [EMAIL PROTECTED]<mailto:[EMAIL PROTECTED]>
