You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@axis.apache.org by Geoff Peart <ge...@quickplay.com> on 2007/08/10 17:29:19 UTC
Improved Error Response for Bad Requests on ADB
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: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
Re: Improved Error Response for Bad Requests on ADB
Posted by Amila Suriarachchi <am...@gmail.com>.
On 8/31/07, Geoff Peart <ge...@quickplay.com> wrote:
>
>
>
> I guess my problem is that the error message isn't really clear, I'm in a
> situation of putting an API out there to third parties, and so I've gone
> with a pretty strict API to make message validation easier, but I'm finding
> ADB error messages to be rather terse and uninformative.
>
yes, I agree. Please log a jira.
So I'm kind of curious if there is a hooking point where I can extend the
> ADB layer to return a more meaningful message, something akin to what you
> would get out of validating the request against the schema. In my example
> the absence, or misplacement of that categoryId field returns an error
> indicating that it is categoryId that is broken, but it is possible for
> there to many instances of category id so with out a reference to which one,
> or a line number, or even a more clear error message a user is sort of left
> with an uneasy feeling on exactly what went wrong.
>
I don't think it is possible with out changing the templates.
One simple improvement is to and another part saying "but expected an <<
expected element name>>"
And use fully qualified names with namesapce. please see the
ADBBeanTemplate.xsl.
Amila.
Has anyone else tackled complex validation scenario's?
>
>
>
>
> ------------------------------
>
> *From:* Amila Suriarachchi [mailto:amilasuriarachchi@gmail.com]
> *Sent:* Friday, August 31, 2007 12:13 AM
> *To:* axis-user@ws.apache.org
> *Subject:* Re: Improved Error Response for Bad Requests on ADB
>
>
>
>
>
> On 8/31/07, *Geoff Peart* <ge...@quickplay.com> 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:informaticu007-pfc@yahoo.es]
> *Sent:* Friday, August 10, 2007 6:00 PM
> *To:* axis-user@ws.apache.org; 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 <ge...@quickplay.com>* 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: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
>
>
>
> ------------------------------
>
>
> Sé un Mejor Amante del Cine
> ¿Quieres saber cómo? ¡Deja que otras personas te ayuden!
> <http://us.rd.yahoo.com/mail/es/tagline/beabetter/*http:/advision.webevents.yahoo.com/reto/entretenimiento.html>
> .
>
>
>
>
> --
> Amila Suriarachchi,
> WSO2 Inc.
>
--
Amila Suriarachchi,
WSO2 Inc.
RE: Improved Error Response for Bad Requests on ADB
Posted by Geoff Peart <ge...@quickplay.com>.
I guess my problem is that the error message isn't really clear, I'm in a situation of putting an API out there to third parties, and so I've gone with a pretty strict API to make message validation easier, but I'm finding ADB error messages to be rather terse and uninformative. So I'm kind of curious if there is a hooking point where I can extend the ADB layer to return a more meaningful message, something akin to what you would get out of validating the request against the schema. In my example the absence, or misplacement of that categoryId field returns an error indicating that it is categoryId that is broken, but it is possible for there to many instances of category id so with out a reference to which one, or a line number, or even a more clear error message a user is sort of left with an uneasy feeling on exactly what went wrong.
Has anyone else tackled complex validation scenario's?
________________________________
From: Amila Suriarachchi [mailto:amilasuriarachchi@gmail.com]
Sent: Friday, August 31, 2007 12:13 AM
To: axis-user@ws.apache.org
Subject: Re: Improved Error Response for Bad Requests on ADB
On 8/31/07, Geoff Peart <ge...@quickplay.com> 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:informaticu007-pfc@yahoo.es]
Sent: Friday, August 10, 2007 6:00 PM
To: axis-user@ws.apache.org; 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 <ge...@quickplay.com> 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: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
________________________________
Sé un Mejor Amante del Cine
¿Quieres saber cómo? ¡Deja que otras personas te ayuden! <http://us.rd.yahoo.com/mail/es/tagline/beabetter/*http:/advision.webevents.yahoo.com/reto/entretenimiento.html> .
--
Amila Suriarachchi,
WSO2 Inc.
Re: Improved Error Response for Bad Requests on ADB
Posted by Jorge Fernandez <in...@yahoo.es>.
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 <am...@gmail.com> escribió:
On 8/31/07, Geoff Peart <ge...@quickplay.com> 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:informaticu007-pfc@yahoo.es]
Sent: Friday, August 10, 2007 6:00 PM
To: axis-user@ws.apache.org; 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 <ge...@quickplay.com> 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: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
---------------------------------
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! .
Re: Improved Error Response for Bad Requests on ADB
Posted by Amila Suriarachchi <am...@gmail.com>.
On 8/31/07, Geoff Peart <ge...@quickplay.com> 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:informaticu007-pfc@yahoo.es]
> *Sent:* Friday, August 10, 2007 6:00 PM
> *To:* axis-user@ws.apache.org; 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 <ge...@quickplay.com>* 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: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
>
>
>
> ------------------------------
>
>
> Sé un Mejor Amante del Cine
> ¿Quieres saber cómo? ¡Deja que otras personas te ayuden!
> <http://us.rd.yahoo.com/mail/es/tagline/beabetter/*http:/advision.webevents.yahoo.com/reto/entretenimiento.html>
> .
>
--
Amila Suriarachchi,
WSO2 Inc.
RE: Improved Error Response for Bad Requests on ADB
Posted by Geoff Peart <ge...@quickplay.com>.
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>
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:informaticu007-pfc@yahoo.es]
Sent: Friday, August 10, 2007 6:00 PM
To: axis-user@ws.apache.org; 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 <ge...@quickplay.com> 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: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
________________________________
Sé un Mejor Amante del Cine
¿Quieres saber cómo? ¡Deja que otras personas te ayuden! <http://us.rd.yahoo.com/mail/es/tagline/beabetter/*http:/advision.webevents.yahoo.com/reto/entretenimiento.html> .
RE: Improved Error Response for Bad Requests on ADB
Posted by Jorge Fernandez <in...@yahoo.es>.
This is a known bug in Axis2 1.2 but seems to be resolved in 1.3.
Regards,
Jorge Fernández
Geoff Peart <ge...@quickplay.com> 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: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
---------------------------------
Sé un Mejor Amante del Cine
¿Quieres saber cómo? ¡Deja que otras personas te ayuden!.