Do we need to write data to original response even after using ResponseWrapper?

I have seen many examples over how to & why to wrap a response. As per my understanding, a class extending HttpServletResponseWrapper provides a stream to servlet for writing data over response (plus some additional methods we can put as per our need). So that a servlet can write data over customized response stream.

Besides, in custom class, we can modify stream contents like; removing space, case conversion, or compression etc. But any such operation can be performed once the servlet finish it works and close response stream. So basically the custom class is used to hold the response data only. And we are required to write the data on original response stream further, when control returns back to filter from servlet.

Reference code for my above understanding

CharResponseWrapper wrapper = new CharResponseWrapper((HttpSer开发者_开发百科vletResponse)response);
chain.doFilter(request, wrapper);
response.setContentLength(caw.toString().length());
out.write(caw.toString());
out.close(); 

Other references

http://jango.wordpress.com/2009/04/27/js-minify-filter-in-java/

http://onjava.com/pub/a/onjava/2003/11/19/filters.html?page=3

Now please explain me the code suggested by balusc

HttpServletResponse httpres = (HttpServletResponse) response;
chain.doFilter(request, wrapResponse(httpres, createTrimWriter(httpres)));

Does it not require writing data to response stream too? Please tell me I am missing some part.

There are two approaches:

• Approach described by you: save the data written by the servlet into some temporary buffer, apply the required modification to it and write it to the output stream after completion of servlet.

• balusc's approach: create an wrapper for output stream that performs required modification on the fly, and wrap output stream with it. Actually, in balusc's example it doesn't work really on-the-fly - there is a temporary buffer that is written to the output stream during flush() operation.

In general, the latter approach is better since it doesn't require additional memory and doesn't introduce overhead in terms of latency. However, it can be difficult to implement for complex modifications.

Ideally, your response wrapper performs some type of service for content being written to the output stream. In some cases, you may need to wrap the output stream as well. You would do that by overriding the getOutputStream() method in the response wrapper (and possibly getWriter() method) so that it returns a custom outputstream (or Writer). As content is written to the custom output stream (or Writer), you perform one of three actions (generally):

1. (possibly modify the data and) write it to the original output stream.
2. buffer it (in part or whole), (possibly modify the data and) write it to the original output stream.
3. discard the data completely (I am sure there is some use case for this... somewhere).