I like the intention of this. I think we are all sick of reading these error messages. However, I think there may be a better way to deal with this.
The fact is, cleanString has no business being used in SOAPException at all. The only reason cleanString ever needs to be called is that the information in SOAPException *may* eventually be sent as part of a SOAP fault. I think cleanString processing should be removed from SOAPException entirely and put into the marshalling code for a Fault. Does anyone know of a reason why this is not a good direction? Scott Nichol ----- Original Message ----- From: "Pavel Ausianik" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, October 18, 2002 8:21 AM Subject: [PATCH] Allow to disable "CleanString" usage for clients > Hello, > > We have a problem with our client application, when a SOAP exception occurs, > because of server error (like it returns 500 or other error, with HTML > instead of XML. When we log the exception to the file, the text is > unreadable see below > > Unsupported response content type "text/html; charset=ISO-8859-1", > must be: "text/xml". Response was: > <head><title>Document moved</title></head> > > To solve this propose having a public static variable , true by default, > which allows to disable conversion of message to valid XML text. I expect > most clients application will want to do this, while server application most > probably often need a conversion. > > See patch attached. > > Thanks, > Pavel > > ------------------------------------------------------------------------ -------- > -- > To unsubscribe, e-mail: <mailto:soap-dev-unsubscribe@;xml.apache.org> > For additional commands, e-mail: <mailto:soap-dev-help@;xml.apache.org> -- To unsubscribe, e-mail: <mailto:soap-dev-unsubscribe@;xml.apache.org> For additional commands, e-mail: <mailto:soap-dev-help@;xml.apache.org>
