On 8/31/07, Geoff Peart <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] > *Sent:* Friday, August 31, 2007 12:13 AM > *To:* [email protected] > *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:* [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! > <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.
