Return-Path: Delivered-To: apmail-jakarta-tomcat-dev-archive@apache.org Received: (qmail 7829 invoked from network); 22 Jan 2002 09:07:30 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 22 Jan 2002 09:07:30 -0000 Received: (qmail 27796 invoked by uid 97); 22 Jan 2002 09:07:35 -0000 Delivered-To: qmlist-jakarta-archive-tomcat-dev@jakarta.apache.org Received: (qmail 27768 invoked by uid 97); 22 Jan 2002 09:07:34 -0000 Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Tomcat Developers List" Reply-To: "Tomcat Developers List" Delivered-To: mailing list tomcat-dev@jakarta.apache.org Received: (qmail 27757 invoked from network); 22 Jan 2002 09:07:33 -0000 Message-ID: <007001c1a324$70f35570$a301a8c0@tzida.fhkarlsruhe.de> From: "Andreas Junghans" To: "Tomcat Developers List" Cc: References: Subject: Re: HttpServletResponseWrapper error. Date: Tue, 22 Jan 2002 10:08:33 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Hi Jay, > This works with Resin. However, in Tomcat, when I wrap the response, I > "commit" the original response object and can not forward to a thank you > page. I catch a "java.lang.IllegalStateException: Cannot forward after > response has been committed". In my debug tests, the response is committed > during the RequestDispatchers forward method. I've had a similar case. The problem is that Tomcat calls flushBuffer() on the response, which seems to be completely "legal" regarding the Servlet spec. Calling flushBuffer() commits the response, and after that, no forward is possible. If Resin behaves differently, this is probably due to a different buffer size or different buffer handling. Perhaps Resin doesn't call flushBuffer() at all, which (in my understanding) is just as spec compliant as Tomcat's behaviour. What you have to do is override flushBuffer() in your response wrapper to prevent HttpServletResponseWrapper from passing the flush to the original response. In my case, I simply added an empty flushBuffer() method to the wrapper, and it worked. However, you should note that some containers _might_ rely on the side effects of the original flushBuffer() (e.g. that exceptions are raised when calling methods like sendRedirect() afterwards). Although this is highly unlikely, you have to "simulate" these effects in your wrapper if you want to be _absolutely_ sure your application runs in every container. Regards Andreas Junghans -- To unsubscribe, e-mail: For additional commands, e-mail: