A ServletFilter could put a request attribute in place that a
ResponseCompressionAnalyzer could use, to indicate no further compression.
JavaMelody doesn't do that, but another filter mapped to the same path perhaps
could.
Sent from my iPad
On Jul 13, 2012, at 9:40 AM, Kalle Korhonen <[email protected]> wrote:
> Using contentType and response size as a criteria for determining
> whether or not to apply gzipping makes a lot of sense when handling
> Tapestry responses. However, we just integrated javamelody
> (https://code.google.com/p/javamelody/) that's implemented as a filter
> and does its own gzipping. You could argue that javamelody should
> provide that as a configurable option but currently doesn't. Luckily
> it was easy enough to override ResponseCompressionAnalyzer and use
> it's deprecated and currently unused contribution as a collection of
> paths that should be excluded from gzipping by T5. Just wondering if
> others think this is too much of an edge case to support or if we
> should put it back in the core and reuse the contribution for excluded
> paths? Are there any other valid reasons to disable gzipping on
> case-by-case basis than existing resource specific compression and the
> size of a response?
>
> Kalle
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
