Thanks for the responses. The reason we need to look at the response before setting a header value is to support a dynamic caching behavior, where the caching determination is made after examining the response and what database interactions are made as a result of building the response.
So, I took your advice and implemented a responsewrapper object. This worked in buffering the response, however a new problem cropped up. I think it's mine--but I found out that I need to also buffer the header values and commit these to the response as well. Still looking at my source though. Thanks all! Pid-2 wrote: > > 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] > > > -- View this message in context: http://www.nabble.com/setHeader-after-DoFilter-delegation-in-filter--tp19862960p20024120.html Sent from the Tomcat - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
