Well, how are you constructing the server side of this service?  One of 
the simplest ways it to simply have your service method throw an AxisFault 
containing all of the Fault details.  The AxisEngine will handle returning 
this information to the client.    There are at least a couple of samples 
provided within the Axis2 distribution (samples/servicelifecycle and 
samples/userguide) that contain some examples that might be done.  In 
these cases, the server side throws an AxisFault and the client side 
catches it and then displays the information.





"Slepecki, Willie" <[EMAIL PROTECTED]> 

07/11/2008 12:31 PM
Please respond to
axis-user@ws.apache.org



To
axis-user@ws.apache.org
cc

Subject
RE: returning meaningful errors for bad xml






Ok, so how do i set it up so in my example below i tell the client exactly 
what went wrong, not just the famous microsoft "there was an error" 
message.


-----Original Message-----
From: Wally Dennis [mailto:[EMAIL PROTECTED]
Sent: Fri 7/11/2008 12:24 PM
To: axis-user@ws.apache.org
Subject: Re: returning meaningful errors for bad xml

Are you using SOAP 1.1 or 1.2?  I couldn't find specific mention of this
in the 1.2 spec, but according to section 6.2 of the SOAP 1.1 spec
(http://www.w3.org/TR/2000/NOTE-SOAP-20000508/#_Toc478383507), "In case of
a SOAP error while processing the request, the SOAP HTTP server MUST issue
an HTTP 500 "Internal Server Error" response and include a SOAP message in
the response containing a SOAP Fault element (see section 4.4) indicating
the SOAP processing error"

This basically means that whenever you return a SOAP Fault, in order to
conform to the specifications it MUST be done with an HTTP 500.





"Slepecki, Willie" <[EMAIL PROTECTED]>

07/11/2008 11:49 AM
Please respond to
axis-user@ws.apache.org



To
axis-user@ws.apache.org
cc

Subject
returning meaningful errors for bad xml






im building a web service using axis2 with jibx as the data binder.

what i need to do is return meaningful messages when i receive a bad xml
document or a doc that doesn't comply with the rules of the schema (values
not included in the enumerations, etc).  i just spent the past 3 days
chasing down classloader issues related to trying to get
weblogic-axis2-jibx working together.  now, it receives the requests
correctly and if something is wrong, it simply returns to the client a 500
error and logs to the log4j something like this

2008-07-11 11:13:20,406 [ACTIVE] ExecuteThread: '0' for queue:
'weblogic.kernel.Default (self-tuning)' ERROR
org.apache.axis2.engine.AxisEngine - Invalid date format
org.apache.axis2.AxisFault: Invalid date format
        at
com.jpmc.paycare.its.web.ITSMessageReceiverInOut.fromOM(ITSMessageReceiverInOut.java:307)
        at
com.jpmc.paycare.its.web.ITSMessageReceiverInOut.invokeBusinessLogic(ITSMessageReceiverInOut.java:157)
        at
org.apache.axis2.receivers.AbstractInOutMessageReceiver.invokeBusinessLogic(Abst
bla bla bla bla

i would like it to send to the client, a valid http 200, and then i guess
a soap fault that indicates what exactly was wrong with the xml that was
sent.  so the above would return something like:

soap:body
soap:fault
Invalid date format on field systemtime
soap:fault
soap:body

second, using the axis-jibx system, how do i get it to validate the
incoming xml with the schema first to make sure that the request fully
complies before it tries to parse it out?




The information contained in this e-mail and any accompanying documents 
may contain information that is confidential or otherwise protected from 
disclosure. If you are not the intended recipient of this message, or if 
this message has been addressed to you in error, please immediately alert 
the sender by reply e-mail and then delete this message, including any 
attachments. Any dissemination, distribution or other use of the contents 
of this message by anyone other than the intended recipient is strictly 
prohibited. All messages sent to and from this e-mail address may be 
monitored as permitted by applicable law and regulations to ensure 
compliance with our internal policies and to protect our business. E-mails 
are not secure and cannot be guaranteed to be error free as they can be 
intercepted, amended, lost or destroyed, or contain viruses. You are 
deemed to have accepted these risks if you communicate with us by e-mail.







The information contained in this e-mail and any accompanying documents may 
contain information that is confidential or otherwise protected from 
disclosure. If you are not the intended recipient of this message, or if this 
message has been addressed to you in error, please immediately alert the sender 
by reply e-mail and then delete this message, including any attachments. Any 
dissemination, distribution or other use of the contents of this message by 
anyone other than the intended recipient is strictly prohibited. All messages 
sent to and from this e-mail address may be monitored as permitted by 
applicable law and regulations to ensure compliance with our internal policies 
and to protect our business. E-mails are not secure and cannot be guaranteed to 
be error free as they can be intercepted, amended, lost or destroyed, or 
contain viruses. You are deemed to have accepted these risks if you communicate 
with us by e-mail. 


Reply via email to