axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Decosta <Eric.Deco...@mathworks.com>
Subject RE: AXIS2-3239, 3443
Date Tue, 18 Nov 2008 19:03:09 GMT
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:manueldarveau@gmail.com]
Sent: Tuesday, November 18, 2008 12:31 PM
To: axis-user@ws.apache.org
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 <Eric.Decosta@mathworks.com<mailto:Eric.Decosta@mathworks.com>>
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:manueldarveau@gmail.com<mailto:manueldarveau@gmail.com>]
Sent: Tuesday, November 18, 2008 10:10 AM

To: axis-user@ws.apache.org<mailto: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 <Eric.Decosta@mathworks.com<mailto:Eric.Decosta@mathworks.com>>
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:manueldarveau@gmail.com<mailto:manueldarveau@gmail.com>]
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



---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org<mailto:axis-user-unsubscribe@ws.apache.org>
For additional commands, e-mail: axis-user-help@ws.apache.org<mailto:axis-user-help@ws.apache.org>


Mime
View raw message