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:[EMAIL PROTECTED] 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 <[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: 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 <[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! <http://us.rd.yahoo.com/mail/es/tagline/beabetter/*http:/advision.webevents.yahoo.com/reto/entretenimiento.html> . -- Amila Suriarachchi, WSO2 Inc.
