Hi Amila,
For some exceptions it works fine. I'm getting 500 HTTP header for most or all
the exceptions but sometimes, the client doesn't get the reason of the
exception.
Attached file contains two exceptions received in the client. First one is a
null pointer exception. When client receives this one, it receives the
exception as a Remote Exception, and if it does e.getMessage(), the message
printed is: "unknown".
If it does e.printStackTrace(), the message printed is:
org.apache.axis2.AxisFault: unknown
at
org.apache.axis2.util.Utils.getInboundFaultFromMessageContext(Utils.java:486)
at
org.apache.axis2.description.OutInAxisOperationClient.handleResponse(OutInAxisOperation.java:343)
at
org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:389)
at
org.apache.axis2.description.OutInAxisOperationClient.executeImpl(OutInAxisOperation.java:211)
at org.apache.axis2.client.OperationClient.execute(OperationClient.java:163)
at client.Medici_LinkStub.validate(Medici_LinkStub.java:1044)
at client.ClientUtilities.validateTest(ClientUtilities.java:57)
at client.Client.main(Client.java:72)
As you can see in the message, there is a header describing the action and it
is this:
<wsa:Action>urn:validateDataAccessException</wsa:Action>
Why is it sending that action??
In services.xml, defined exceptions are:
<faultActionMapping
faultName="ValidationException">urn:validateValidationException</faultActionMapping>
<faultActionMapping
faultName="DataAccessException">urn:validateDataAccessException</faultActionMapping>
In second case I'm building a ValidationException in the service like this:
public static ValidationException buildValidationException(String _message,
Logger _logger){
if(_logger!=null)
_logger.error(_message);
ValidationException exception=new ValidationException("Validation
Fault");
ValidationFault fault=new ValidationFault();
fault.setDescription(_message);
exception.setFaultMessage(fault);
return exception;
}
but actions in SOAP message are those of DataAccessException. So it seems that
it's not working fine.
Client does:
System.out.println("AN EXCEPTION OCURRED: "+e.getMessage()+":
"+e.getFaultMessage().getDescription());
And the message printed is:
AN EXCEPTION OCURRED: ValidationException: SYSTEM NOT VALIDATED. YOU MUST
VALIDATE BEFORE INVOKING A METHOD.
So the client can see the exception OK but the SOAP message is not built
correctly.
Thanks,
Jorge Fernández
Amila Suriarachchi <[EMAIL PROTECTED]> escribió:
On 8/31/07, Geoff Peart <[EMAIL PROTECTED]> wrote: Took me until
now to upgrade to 1.3, and I agree, the error's are better now they zero in on
the one line of the exception that does matter:
< faultstring > org.apache.axis2.databinding.ADBException: Unexpected
subelement CategoryId </ faultstring >
this means ADB parser has encountered an in valid element. The reason for this
most of the time is the request
does not contain a requried element value.
eg lets take this element
<xsd:element name="TestElement">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="param1" type="xsd:string"/>
<xsd:element name="param2" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
here both param1 and param2 are requried elements since they have the default
minOccurs=1 value.
a valid request for this elements is
<TestElement>
<param1>test</param1>
<param2>test</param2>
</TestElement>
but if it receives a reqeust without param1 i.e.
<TestElement>
<param2>test</param2>
</TestElement>
Now after reading TestElement adb parser expects the param1 since it is a
required element. but it gets param2 which is an unexpected element.
So it throws an excpetion saying unexcpeted subelement param2.
To debug this first locate the CategoryID and check it has received the correct
element before that.
You can use the -Eosv option to let adb thinks every element is optional.
Amila.
But it doesn't really say where in the message that value was out of place, or
why its wrong, as in the case:
< faultstring > For input string: "2320asdf" </ faultstring >
Where now I have the element in the correct location, but with an invalid
value (mixed text instead of a numerical value.)
So I'm at an impasse, do I rewrite my API to expect virtually any value, but
at least in a rigid structure, and do my validation in code, or leave my 3rd
parties with obscure error messages?
I'm hoping there is a 3rd choice I've missed?
Thanks
---------------------------------
From: Jorge Fernandez [mailto:[EMAIL PROTECTED]
Sent: Friday, August 10, 2007 6:00 PM
To: [email protected]; Geoff Peart
Subject: RE: Improved Error Response for Bad Requests on ADB
This is a known bug in Axis2 1.2 but seems to be resolved in 1.3.
Regards,
Jorge Fernández
Geoff Peart <[EMAIL PROTECTED]> escribió:
Using the default Data Binding, a badly formed request gets meaningless
runtime exceptions making it difficult for a client to develop and debug
their application. Is there a way to either override this behaviour, or
plug-in better error handling? I don't want to get in and edit the
generated code, but even if the runtime errors held more information
like why its failing would be a step in the right direction?
Any help would be great.
Thanks
G
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------
Sé un Mejor Amante del Cine
¿Quieres saber cómo? ¡Deja que otras personas te ayuden! .
--
Amila Suriarachchi,
WSO2 Inc.
---------------------------------
Sé un Mejor Viajero
¿Quieres saber cómo? ¡Deja que otras personas te ayuden! .
HTTP/1.1 500 Error Interno del Servidor
Server: Apache-Coyote/1.1
Content-Type: application/soap+xml;
action="urn:validateDataAccessException";charset=UTF-8
Transfer-Encoding: chunked
Date: Fri, 31 Aug 2007 11:01:01 GMT
Connection: close
b36
<?xml version='1.0' encoding='UTF-8'?>
<soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope";
xmlns:wsa="http://www.w3.org/2005/08/addressing";>
<soapenv:Header>
<wsa:Action>urn:validateDataAccessException</wsa:Action>
<wsa:RelatesTo>urn:uuid:578695F1A346B244751188558061265</wsa:RelatesTo>
</soapenv:Header>
<soapenv:Body>
<soapenv:Fault>
<soapenv:Code>
<soapenv:Value>soapenv:Receiver</soapenv:Value>
</soapenv:Code>
<soapenv:Reason>
<soapenv:Text xml:lang="en-US">unknown</soapenv:Text>
</soapenv:Reason>
<soapenv:Detail>
<Exception>org.apache.axis2.AxisFault
 at
org.apache.axis2.AxisFault.makeFault(AxisFault.java:417)
 at
medici_link.Medici_LinkMessageReceiverInOut.invokeBusinessLogic(Medici_LinkMessageReceiverInOut.java:388)
at
org.apache.axis2.receivers.AbstractInOutSyncMessageReceiver.invokeBusinessLogic(AbstractInOutSyncMessageReceiver.java:42)
at
org.apache.axis2.receivers.AbstractMessageReceiver.receive(AbstractMessageReceiver.java:96)
at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:145)
 at
org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:275)
at
org.apache.axis2.transport.http.AxisServlet.doPost(AxisServlet.java:120)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
 at
javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
 at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.c
atalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:228)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:216)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:634)
at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445)
 at
java.lang.Thread.run(Unknown Source)
Caused by:
java.lang.NullPointerException
 at medici_link.Me
dici_LinkUtilities.getAlias(Medici_LinkUtilities.java:546)
 at
medici_link.Medici_LinkSkeleton.validate(Medici_LinkSkeleton.java:143)
 at
medici_link.Medici_LinkMessageReceiverInOut.invokeBusinessLogic(Medici_LinkMessageReceiverInOut.java:85)
... 19 more
</Exception>
</soapenv:Detail>
</soapenv:Fault>
</soapenv:Body>
</soapenv:Envelope>
0
HTTP/1.1 500 Error Interno del Servidor
Server: Apache-Coyote/1.1
Content-Type: application/soap+xml;
action="urn:getPatientsByTypeDataAccessException";charset=UTF-8
Transfer-Encoding: chunked
Date: Fri, 31 Aug 2007 11:01:01 GMT
Connection: close
323
<?xml version='1.0' encoding='UTF-8'?>
<soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope";
xmlns:wsa="http://www.w3.org/2005/08/addressing";>
<soapenv:Header>
<wsa:Action>urn:getPatientsByTypeDataAccessException</wsa:Action>
<wsa:RelatesTo>urn:uuid:578695F1A346B244751188558062363</wsa:RelatesTo>
</soapenv:Header>
<soapenv:Body>
<soapenv:Fault>
<soapenv:Code>
<soapenv:Value>soapenv:Receiver</soapenv:Value>
</soapenv:Code>
<soapenv:Reason>
<soapenv:Text xml:lang="en-US">Validation Fault</soapenv:Text>
</soapenv:Reason>
<soapenv:Detail>
<ns3:ValidationFault
xmlns:ns3="http://op_messages.medici_link/xsd";>
<ns3:description>SYSTEM NOT VALIDATED. YOU MUST VALIDATE
BEFORE INVOKING A METHOD.</ns3:description>
</ns3:ValidationFault>
</soapenv:Detail>
</soapenv:Fault>
</soapenv:Body>
</soapenv:Envelope>
0
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
