In GZipEnabledResponse
@Override
public ServletOutputStream getOutputStream() throws IOException
{
if (contentLengthSet || isCompressionDisabled())
return super.getOutputStream();
String contentType = getContentType();
return new BufferedGZipOutputStream(contentType, response,
cutover, analyzer);
}
In my case I'm using a Resteasy filter which calls getOutputStream
early in the processing of the request, before my code has had a
chance to set the content type.
One solution would be to have the BufferedGZipOutputStream take some
proxy object that it can call getContentType on instead of evaluating
it before the OutputStream is created. Perhaps it could delay it all
the way to when the first bytes are written. Actually, it's pass the
response, it could probably just grab the content-type from there?
Josh
On Tue, Jan 10, 2012 at 4:36 PM, Howard Lewis Ship <hls...@gmail.com> wrote:
> On Tue, Jan 10, 2012 at 11:59 AM, Josh Canfield <joshcanfi...@gmail.com>
> wrote:
>> The actual error reported is caused by what looks like a defect:
>>
>> java.lang.NullPointerException
>>
>> org.apache.tapestry5.internal.services.assets.CompressionAnalyzerImpl.isCompressable
>>
>> The code:
>>
>> public boolean isCompressable(String contentType)
>> {
>> assert contentType != null;
>>
>> int x = contentType.indexOf(';');
>> ...
>>
>> The assertion here is not helpful when you get a null contentType passed
>> in...
>>
>> I'm going to change this to return false if contentType == null.
>
> I'd prefer to know, first, why the contentType was null.
>
>>
>> Josh
>>
>> On Tue, Jan 10, 2012 at 8:22 AM, Howard Lewis Ship <hls...@gmail.com> wrote:
>>> Order counts; your filter needs to be ordered after Tapestry's
>>> "ErrorFilter" contribution; otherwise, there's nothing to catch the
>>> exception and report it.
>>>
>>> On Tue, Jan 10, 2012 at 1:10 AM, Stephan Windmüller
>>> <stephan.windmuel...@tu-dortmund.de> wrote:
>>>> Am 10.01.2012 09:51, schrieb Stephan Windmüller:
>>>>
>>>>> In the AppModule class we defined a custom component transaction
>>>>> filter. When this filter throws an exception, it is not rendered with
>>>>> the exception report page, instead we are getting this stacktrace:
>>>>
>>>> Forgot to mention: We are using Tapestry 5.3.1.
>>>>
>>>> - Stephan
>>>>
>>>
>>>
>>>
>>> --
>>> 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: users-unsubscr...@tapestry.apache.org
>>> For additional commands, e-mail: users-h...@tapestry.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>> For additional commands, e-mail: users-h...@tapestry.apache.org
>>
>
>
>
> --
> 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: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
