I started looking at SOAP a few months ago, that's why I said it. Anyways, what gets put in sendError(code, msg) should be available in your _custom_ error handler by calling req.getAttribute(javax.servlet.error.message).
-Yan -----Original Message----- From: Bill Harrelson [mailto:[EMAIL PROTECTED] Sent: April 16, 2004 18:38 To: Tomcat Users List Subject: RE: Handling SOAP faults Thanks for the interest and reply Yan, but you make assumptions that are incorrect: > Ok, I think what happened here is: the response message is *overwritten* > since you already defined a custom error-page in your deployment descriptor. No, the response message is sent back as the error response message, _not_ as the errorStream. I checked this (as this being the simplest approach) _before_ implementing the custom error- page in the deployment descriptor. Putting an error message into the sendError(error-code, message) call does not return an errorStream. What gets returned in the errorStream in that case is the default html error page. I'm still looking for a way to write to the errorStream directly. Bill > PS. SOAP is a really good idea. I'm not sure why you say this, but ok. SOAP has been a reality in the world I work in for a couple of years now, but it's only recently that people have actually started generating and expecting SOAPfaults. > > -----Original Message----- > From: Bill Harrelson [mailto:[EMAIL PROTECTED] > Sent: April 16, 2004 11:59 > To: Tomcat Users List > Subject: RE: Handling SOAP faults > > > What the SOAP spec says is that a SOAPfault XML document > needs to be returned in the errorStream and a response code of > 500 returned. > > Sending a response 500 is easy, including a response message is > also easy. But, what is included in the response message is not > written to the errorStream. Tomcat seems to write whatever is > generated by the error-page directive in the deployment descriptor > to the error-stream, so I have currently solved the problem by > passing the SOAPfault document through the session variable to > the designated jsp listed in the error-page directive. > > It just seems that this is a hackery way to do it, and my servlet > should be able to write directly to the errorStream of the response, I > just can't see how. > > Any assistance is appreciated. > > Thanks, > > Bill > > > Send reply to: "Tomcat Users List" <[EMAIL PROTECTED]> > From: "Yansheng Lin" <[EMAIL PROTECTED]> > To: "'Tomcat Users List'" <[EMAIL PROTECTED]> > Subject: RE: Handling SOAP faults > Date sent: Fri, 16 Apr 2004 11:21:06 -0600 > > > How about setting the fault on the response? With 500 as status. Or is > > that what you asked for? > > > > -Yan > > > > -----Original Message----- > > From: Bill Harrelson [mailto:[EMAIL PROTECTED] > > Sent: April 15, 2004 19:04 > > To: Tomcat Users List > > Subject: Handling SOAP faults > > > > > > Hello, > > > > I'm using Tomcat 4.2.14, JDK 1.4.1, and I need to be able to return > > a SOAP fault document with a response code of 500. The only > > way I've found to do this seems a bit of a hack, and I was > > wondering if there was a better way. > > > > Currently I'm passing the SOAP fault document in the session > > variable which gets picked up by the error-page handler (a jsp) > > when I issue the sendError(500). This results in the SOAPfault > > message appearing in the error-stream on the client as it should, it > > just seems as though I ought to be able to write to the error-stream > > directly, but I can't find how in the doc, or googling. > > > > Can anyone assist? > > > > Thanks, > > > > Bill > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
