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
