André Warnier wrote:
> Hi.
> I found an approximative example for you, here :
> http://www.javafaq.nu/java-example-code-237.html
> (searching Google for "HttpServletResponseWrapper example"
>
> If I remember well, what you want to achieve is : depending on the
> response content that the webapp generates, you would like to set a
> response header. This response header has to be set of course, before
> the first byte of output content is sent to the browser.
>
> Before your webapp is going to send this first byte, it will need to get
> some form of output stream to write the byte to.
> It will do that using one of the methods available to webapps to get
> such an output stream, which I identify as either getOutputStream or
> getWriter.
I suspect it will rather depend on the type of processing the OP is
trying to do on the output, maybe he can enlighten us?
> So what you probably need to do in your wrapper, is to override these
> two methods, so that when the servlet calls one of them, you can return
> your own version of it instead of the regular one.
> In this way, later your wrapper can "sit in the middle" when the webapp
> starts writing to its output, and you can examine this output before
> forwarding it to the "real" servlet output stream. Of course before you
> forward the output there, you will have determined which header you want
> to add and sent it out.
Andre is making the point that the processing could be done inside the
wrapper, rather than in the filter - which is only there to allow you to
wrap the response.
> Not very easy, and over my current capacities.
As above, depends on the type of processing required... the use of a
ByteArrayOutputStream may be a simple way of buffering the response for
example.
p
> Unfortunately the example I provided above is a bit of a cheat, because
> all it has to do is replace the original stream by a compressed one, for
> which there is apparently already a convenient class available.
>
> One of the important elements maybe, is how much of the output you need
> to see in order to determine which header to add.
> If it is just the first few bytes, then I suppose you could buffer this
> in memory until you have enough, send out your header, and then set a
> flag so that subsequent servlet writes happen as transparently as possible.
> If it is the whole response and it can be big, then you might have to
> buffer the entire response to disk before setting your header, and then
> re-read the original response and sending it out yourself.
>
>
> slioch wrote:
>> Sorry all--I'm still stumped. Tried the suggestions and here's what I
>> found.
>> I've subclass HttpServletResponseWrapper and overloaded the following
>> methods:
>>
>> public void flushBuffer();
>> public void sendRedirect(String str);
>> public void sendError(int sc);
>> public void sendError(int sc, String msg);
>>
>> in my new response wrapper. These methods have been disabled while
>> processing is in the scope of my filter (I also record if these
>> methods are
>> called). I've replaced the response object with my new wrapper:
>>
>> public void doFilter(ServletRequest req, ServletResponse res,
>> FilterChain fc)
>> throws java.io.IOException, javax.servlet.ServletException {
>> ResponseWrapper resp = new
>> ResponseWrapper((HttpServletResponse)(res));
>>
>>
>> And I've found that sendError(), sendRedirect(), and flushBuffer() are
>> not
>> being called while in the processing is in the scope of my filter. In
>> other
>> words the filter looks something like:
>>
>> dofilter(ServletRequest req, ServletResponse res, FilterChain fc)
>> {
>> ResponseWrapper resp = new
>> ResponseWrapper((HttpServletResponse)(res));
>> //resp.isCommitted() returns false
>> //some processing work
>> //resp.isCommitted() returns false;
>> fc.doFilter(req,resp);
>> //resp.isCommitted() returns TRUE
>> //some more process work
>> return;
>> }
>>
>> If I know that sendError(), sendRedirect(), and flushBuffer() are not
>> being
>> called how would response be sent (provided autoflush is false and the
>> buffer size is large enough for the print writer). Thanks for the help
>> (and
>> patience)!
>>
>> mike
>>
>>
>> Caldarale, Charles R wrote:
>>>> From: André Warnier [mailto:[EMAIL PROTECTED]
>>>> Subject: Re: setHeader after DoFilter delegation in filter?
>>>>
>>>> To create output for the client, the application calls
>>>> something, right? (I mean a method of HttpRequest).
>>> Not quite - you're confusing request with response. There are
>>> methods in
>>> HttpServletResponse - an Interface, not a class - to obtain a
>>> PrintWriter
>>> or ServletOutputStream that the webapp uses to generate data to be
>>> sent to
>>> the client at some point in the future. The data isn't sent until
>>> flushBuffer(), sendError(), or sendRedirect() are called. Since the
>>> HttpServletResponseWrapper class implements the interface, those methods
>>> are available via the wrapper. The filter needs to subclass the wrapper
>>> in order to subvert anything else in the filter/servlet chain.
>>>
>>> - Chuck
>>>
>>>
>>> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
>>> MATERIAL and is thus for use only by the intended recipient. If you
>>> received this in error, please contact the sender and delete the e-mail
>>> and its attachments from all computers.
>>>
>>> ---------------------------------------------------------------------
>>> To start a new topic, e-mail: users@tomcat.apache.org
>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>
>>>
>>>
>>
>
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
