This week's book giveaway is in the Agile and Other Processes forum.
We're giving away four copies of The Little Book of Impediments (e-book only) and have Tom Perry on-line!
See this thread for details.
Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Use of ResponseWrapper for filtering response

 
Karthikeyan Komar
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have a question regarding filtering the response based on the explanation in HF Servlets and JSP.

The HttpServletResponseWrapper wraps the same HttpServletResponse object and sends it to the servlet in the filter's doFilter() method via filterChain.doFilter(req,wrapped_resp). The book explains that if we don't use a responsewrapper,the original response would have been already sent to the client before it reaches the compression filter's doFilter() method and we won't be able to compress the servlet output.

The HttpServletResponseWrapper is basically wrapping the HttpServletResponse and overrides getOutputStream() method which again returns servletOutputStream wrapped with gzipoutputstream. So, when filterchain.doFilter() is called,the servlet could still have access to the same response and outputstream beneath the covers. So,now how does this wrapping prevent the servletoutputstream to be sent to the client before compression(though it is the original response/outputstream under the covers)?

Thanks
Karthik
 
Marc Peabody
pie sneak
Sheriff
Posts: 4727
Mac Ruby VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Please check your Private Messages for an important message.

The servlets typically won't get direct access to the under-the-covers response or outputstream in this case. That's the whole point of wrapping. The Servlets still think they're dealing with the original, but the wrapper is pulling a switcheroo.
[ April 03, 2008: Message edited by: Marc Peabody ]
 
Karthikeyan Komar
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Marc,
Thanks for your reply.
According to this link- http://edocs.bea.com/wls/docs61/webapp/filters.html#172615,
I assume that the container does the job of automatically returning the ServletOutputStream to the client by calling ServletOutputStream.flush() when we don't flush it explicitly within the doXXX() methods.So,without any wrappers,I understand the fact that the normal ServletOutputStream would be returned to the client by the container after the Servlet finishes its execution and hence the filter won't have access to the original ServletOutputStream.

In the example in the book, the servlet writes to GzipOutputStream of ResponseWrapper which compresses the Servlet output.But what's confusing to me is, there is still the original ServletOutputstream beneath Gzipoutputstream.Eventhough the wrappedoutputstream/response is available to the filter after servlet's execution,before completing servlet execution what had now prevented the container to call flush() on the outputstream and prevented returning ServletOutputStream(covered by Gzipoutputstream) to the client?
i.e,just because we wrapped the ServletOutputStream, how was it prevented from being sent to the client by the container?


Kindly clarify.

Thanks
Karthik

[ April 03, 2008: Message edited by: Karthikeyan Komar ]

[ April 03, 2008: Message edited by: Karthikeyan Komar ]
[ April 03, 2008: Message edited by: Karthikeyan Komar ]
 
Karthikeyan Komar
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Could anybody please clarify my question..?
 
Marc Peabody
pie sneak
Sheriff
Posts: 4727
Mac Ruby VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Karthikeyan komar:
i.e,just because we wrapped the ServletOutputStream, how was it prevented from being sent to the client by the container?

The container won't touch the inner stream directly. However, calling flush on the GZipServletOutputStream would cause GZipSOS to look inside and call flush on its inner stream, which would cause the response to flush to the client.

Why are you assuming that there is some kind of prevention involved?
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic