There's an advantage to having Tapestry do the GZIp compression of static assets: it caches the GZip stream.
On Mon, Jul 16, 2012 at 5:13 PM, Howard Lewis Ship <[email protected]> wrote: > 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] >> -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
