RE: wsdl2java question
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:27 AM To: axis-user@ws.apache.org Subject: Re: wsdl2java question in the template it says /** * xsl:value-of select=@name/.java * * This file was auto-generated from WSDL * by the Apache Axis2 version: #axisVersion# #today# */ I think it has pick a wrong version some where. Amila. On 8/31/07, Lindsey Hess [EMAIL PROTECTED] wrote: Hi, I'm running Axis 1.2.1's wsdl2java against a WSDL, and when I look at the generated code it says: This file was auto-generated from WSDL by the Apache Axis 1.4 Apr 22, 2006 Shouldn't this say Apache Axis 1.2.1? I'm a bit confused... Thank you. Lindsey Shape Yahoo! in your own image. Join our Network Research Panel today! http://us.rd.yahoo.com/evt=48517/*http:/surveylink.yahoo.com/gmrs/yahoo _panel_invite.asp?a=7 -- Amila Suriarachchi, WSO2 Inc.
RE: wsdl2java question
Sorry wrong thread From: Geoff Peart [mailto:[EMAIL PROTECTED] Sent: Friday, August 31, 2007 9:04 AM To: axis-user@ws.apache.org Subject: RE: wsdl2java question From: Amila Suriarachchi [mailto:[EMAIL PROTECTED] Sent: Friday, August 31, 2007 12:27 AM To: axis-user@ws.apache.org Subject: Re: wsdl2java question in the template it says /** * xsl:value-of select=@name/.java * * This file was auto-generated from WSDL * by the Apache Axis2 version: #axisVersion# #today# */ I think it has pick a wrong version some where. Amila. On 8/31/07, Lindsey Hess [EMAIL PROTECTED] wrote: Hi, I'm running Axis 1.2.1's wsdl2java against a WSDL, and when I look at the generated code it says: This file was auto-generated from WSDL by the Apache Axis 1.4 Apr 22, 2006 Shouldn't this say Apache Axis 1.2.1? I'm a bit confused... Thank you. Lindsey Shape Yahoo! in your own image. Join our Network Research Panel today! http://us.rd.yahoo.com/evt=48517/*http:/surveylink.yahoo.com/gmrs/yahoo _panel_invite.asp?a=7 -- Amila Suriarachchi, WSO2 Inc.
RE: Improved Error Response for Bad Requests on ADB
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 param1test/param1 param2test/param2 /TestElement but if it receives a reqeust without param1 i.e. TestElement param2test/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.
RE: Improved Error Response for Bad Requests on ADB
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: faultstringorg.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: faultstringFor 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 .
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Original WSDLs and more information on service.xml
Is there more detailed information available on authoring the service.xml file? What I'm specifically attempting is to include my copies of the WSDL and XSD in the AAR and have them referenced by the ?WSDL and ?XSD request parameters. What further complicates my issue is that my XSD imports a number of other XSD to support my messages, and I wish to expose them, in there original form. Thanks Geoffrey
