I'd recommend taking the compression filter out entirely. That's what we did in 4.0. There's that output stream bug, plus the filter is unnecessary as most Servlet containers (including Tomcat) now support a filtering option.
- Dave On 10/1/07, Phillip Rhodes <[EMAIL PROTECTED]> wrote: > Roller devs: > > Should class CompressionFilter not call > response.getOutputStream().close() before returning? > I've seen some weirdness where if - in a filter - the > response object is actually a wrapper passed > from another filter, and said wrapper uses a ByteArrayOutputStream > as an internal buffer, the data is not written and available > to the "upstream" filter if close() is not called. > > Interestingly enough, and I still don't understand this > fully, I've been playing with using Sitemesh to decorate > Roller pages and have found that using the CompressionFilter > above the Sitemesh filter resulted in no data being > sent to the browser, unless I added said close() method > to the CompressionFilter. This doesn't make any sense > considering that CompressionFilter is receiving > data *from* the Sitemesh filter and I didn't add > anything above the CompressionFilter. But the behavior > is pretty consistent. > > Anyway, just thought I'd raise the issue in case anybody > else thought it would be beneficial to add that > close() call. Oh, and it's the 3.2 code I'm working with. > > > Thanks, > > > Phil >
