tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: OutputStream cleanup
Date Sat, 15 Apr 2000 21:15:51 GMT
Luc Pardon wrote:

> Costin,
>   While you're tinkering in this area, please have a look at Tomcat bug
> 037. A jsp:included servlet can't use an output stream, because it
> conflicts with the writer from the calling servlet.
>   Craig thinks this is correct, but I think it's not. I'm still  working
> my way through the specs to see if Tomcat (3.1 beta) conforms or not.
> Either way, I don't think I should have to care about the particular
> implementation of the URI that I'm including. In fact, section B.4 in
> JSP 1.1 sayu that "the goal is for jsp:include to be totally transparant
> to how the data is computed".

As the beginning of Appendix B says, it is "not normative" -- the real
issues are what the specific parts of the specs do say about this, as

[JSP Spec, Section 6.1.2, second paragraph] "The initial JspWriter object is
associated with the PrintWriter object of the ServletResponse ..."  In other
words, JSP pages *always* call response.getWriter() somewhere inside the
implementation.  When this happens depends on the buffering you have
requested, but it's guaranteed to happen at some time.

[JSP Spec, Section 2.13.4]  The resource included with <jsp:include> is
subject to the same rules that apply, from the servlet spec, to the resource
you call with RequestDispatcher.include().

[Servlet Spec, 8.2, first paragraph]  "To use a request dispatcher, a
developer needs to call either the include or forward method of the
RequestDispatcher interface, using the request and response arguments that
were passed in via the service method of the Servlet interface."  In other
words, the the outer servlet/JSP has already called getWriter() on this
response object -- as it will do at some point in the case of a JSP page --
the inner servlet/JSP will get an IllegalStateException if it calls
getOutputStream() on that very same response object.

Note that the restrictions about intermixing apply to both servlets and JSP
pages, and it has been this way since request dispatchers were introduced in
servlet API version 2.1.

>   Indeed, the idea of including - in my view - is to insert (merge) the
> byte stream from the included URI into the byte stream that you're
> sending to your requester. The way it is now, the incoming bytes are
> converted into chars and then converted back again on their way out -
> which of course screws up the bytes big time if the encoding isn't
> exactly the same in every link of the chain.

I don't agree with you about the desireability of allowing intermixing,
either.  The two kinds of output are designed for two different purposes --
character (including encoding for internationalization as necessary) and
binary (which may be characters, but that isn't always the case).  The
distinction between kinds of output permeates the entire Java I-O package
hierarchy -- there are always differences between output streams and

But this is really irrelevant to whether or not its OK to change Tomcat in
this way.  See more below.

>   I ran into this because my included servlet was a wrapper for a CGI
> script (IBM's Net.Data to be precise) that retrieves data in several
> languages and various encodings from a database. My calling servlet
> knows which encoding is required by its client, and passes this
> information on to the CGI script as a parameter that the script
> understands. The wrapper servlet uses byte streams so it shouldn't have
> to worry about encoding (I first used a writer and got garbage output
> with the deafult encoding). If I can't use a stream (as it is right now)
> the wrapper servlet must adjust its encoding to the type of request it
> is passing on, instead of being just the go-between. I don't think this
> is right.
>   It is trivial to fix this, by testing if the servlet isIncluded before
> throwing an IllegalStateException. This is especially true if the
> buffering cleanup that you are proposing ensures you can cleanly mix
> stream and writer within the same request.
>   If the current behaviour is correct, the JSP spec should be amended to
> say that an URI can be anything, EXCEPT a servlet that calls
> getOutputStream() on the request. That seems a Bad Thing (n-tm) to me.

For Tomcat as it stands, implementing the current specs (servlet 2.2 and JSP
1.1), it is not OK to change the way this works, because the spec
specifically describes what the required behavior is.  Besides the fact that
Tomcat is the "reference implementation" that other servlet container
providers will use to compare functionality with, the whole point of
specifications is to guarantee a level of portability between
implementations.  If Tomcat chose to ignore this particular requirement, and
every other implementation ignored their own choice of spec requirements
that the developer disagreed with, where would we be?

For the future, what you are suggesting is a change in the specification.
If your suggestion is accepted and acted upon, then all servlet container
providers will be required to conform when they support the new spec
version.  Spec changes happen through the Java Community Process, as
described on the web site.  There is a current process focused on the next
versions of the servlet and JSP specs (2.3 and 1.2 respectively), under Java
Specification Request (JSR) 53 -- You can offer suggestions and feedback to
the spec leads (who will then share it with the expert group) by emailing  This particular suggestion isn't going to get
my vote (for the philosophical reasons described above), but it might gain
support from others.

>  Luc Pardon
>  Skopos Consulting
>  Belgium

Craig McClanahan

View raw message