tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jess Holle <>
Subject Fix #43236
Date Wed, 05 Mar 2008 01:14:36 GMT
I belatedly noticed this bug fix in 5.5.26 and 6.0.16.

On the one hand this seems like a nice fix, allowing the following call 
sequences on ServletResponse:

   1. getWriter(), reset(), and then getOutputStream()
   2. getOutputStream(), reset(), and then getWriter()
   3. getWriter(), reset(), setCharacterEncoding(), and then getWriter()

without exceptions and with the effects one would expect if one had not 
reset() or the methods prior to it.

On the other hand, the servlet spec seems to state fairly unequivocally 
that (1) and (2) should result in IllegalStateExceptions and in (3) the 
setCharacterEncoding() call should be silently ignored.

I'm not arguing for the fix to be rolled back, but I am trying to get 
some insight as to whether I'm the only one that reads the spec this way.

I'm interested this in large part as an occasional (and current) author 
of rather complex servlet filters wherein I want to be as general and 
transparent as possible.  In this role I want my filter to emulate 
/standard /ServletResponse behavior as well as possible irrespective of 
the servlet engine in which I'm running.  Behavior like Tomcat's after 
this bug fix makes me wonder which way to head.

For now I've been leaving my filters as per my understanding of the spec 
-- in large part because trying to emulate Tomcat's new behavior makes 
at least my filter a real mess.  Also in practice I don't see a big need 
for the new behavior as JSPWriter's usually delay 
ServletResponse.getWriter() long enough for one to make up one's mind 
and call getOutputStream() instead, for instance.

Jess Holle

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message