This week's book giveaway is in the OCPJP forum.
We're giving away four copies of OCA/OCP Java SE 7 Programmer I & II Study Guide and have Kathy Sierra & Bert Bates on-line!
See this thread for details.
The moose likes Web Component Certification (SCWCD/OCPJWCD) and the fly likes Compression Filter (Head First Servlets) Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCA/OCP Java SE 7 Programmer I & II Study Guide this week in the OCPJP forum!
JavaRanch » Java Forums » Certification » Web Component Certification (SCWCD/OCPJWCD)
Bookmark "Compression Filter (Head First Servlets)" Watch "Compression Filter (Head First Servlets)" New topic
Author

Compression Filter (Head First Servlets)

Doug Braidwood
Ranch Hand

Joined: Apr 04, 2010
Posts: 42
I am working through the Filters chapter of Head First Servlets and I have run into trouble with the example Compression filter.

I followed the steps described in the book but found that I was getting no output, i.e. a blank page in the browser. I tried to add more tracking and look in the logs but was not able to solve the issue.

I then downloaded the specimen answer from http://headfirstlabs.com/books/hfsvlt/CompFilter.zip
and I have the same problem with that.

The .html file appears correctly in my browser through the filter.
But the .jsp file gives a blank screen.

Have other people run into this problem? Any suggestions how I can tackle it?


SCJP, SCWCD
Frits Walraven
Creator of Enthuware JWS+ V6
Bartender

Joined: Apr 07, 2010
Posts: 1700
    
  25

Hi Doug,

I had the same problem as you described, this is what I did to solve it:
  • Go to the index.html
  • comment out the line 53 in the CompressionFilter, so:


  • Stop and start the server
  • Go to the index.html again
  • try the key combination CNTRL-F5 a couple of times

  • and this should be about the outcome:
    ‹m‘½NÄ0„û<Åtw'A"„èÂ5'(¨8‰zobƒãµlßEy{ì„Ÿ†Æ¶´óͬw[&{¬ª¶µäûÌ1!iF/“£‡ÁØÄ¡΂+3,YB?:—Ø%˜ˆŽAV7Õ$j3N~Ï«zK1CK!¦

    Regards,
    Frits
    Doug Braidwood
    Ranch Hand

    Joined: Apr 04, 2010
    Posts: 42
    Thanks Frits,

    I am using the files downloaded from Head First and what I find is

    index.html - display correctly in the browser the first time, then when I press f5 I get an exception
    java.lang.NullPointerException
    com.example.CompressionResponseWrapper.getGZIPOutputStream(CompressionResponseWrapper.java:99)
    com.example.CompressionFilter.doFilter(CompressionFilter.java:61)
    then if I press f5 again the file displays correctly. With each press of f5 the page alternates between displaying correctly and this error status 500.

    page1.jsp - always displays blank page with no text or data


    commenting out the line 53 wrappedResp.setHeader("Content-Encoding", "gzip");
    page1.jsp - instead of a blank page I get two "wingdings" like squares

    The browser I'm using supports gzip, which I know because I looked in the header "Content-Encoding"

    I'm just surprised that this doesn't just work, especially since it's a specimen answer!
    I'm using Tomcat 5.5.28
    Doug Braidwood
    Ranch Hand

    Joined: Apr 04, 2010
    Posts: 42
    I may be barking up the wrong tree but the decorator class that's being used for the output stream



    This is only overriding write(int) and looking at the API there are a number of other write methods, should they not be overridden too?
    Frits Walraven
    Creator of Enthuware JWS+ V6
    Bartender

    Joined: Apr 07, 2010
    Posts: 1700
        
      25

    Doug,
    With each press of f5 the page alternates between displaying correctly and this error status 500.

    That is also what I got
    commenting out the line 53 wrappedResp.setHeader("Content-Encoding", "gzip");
    page1.jsp - instead of a blank page I get two "wingdings" like squares

    I don't even get to page1.jsp, if I press F5 two times on the index.html the second time it is scrambled
    This is only overriding write(int) and looking at the API there are a number of other write methods, should they not be overridden too?

    Not necessarily, you only have to override what you want to adjust. This implementation is probably only using the write method to show you how the content can be scrambled.

    Regards,
    Frits
    Zhixiong Pan
    Ranch Hand

    Joined: Jan 25, 2006
    Posts: 239
    hi,

    I recieved the same exception.


    Could anyone kindly point out why so many people were blocked there.

    Thanks.


    SCJP 1.4 SCJD
    Doug Braidwood
    Ranch Hand

    Joined: Apr 04, 2010
    Posts: 42
    I've been trying to get to the bottom of this and added extra tracing to the log but I'm still not reaching a solution.

    What seems to be happening when you refresh on the normal .html page is that the container is not doing generating a response at all. It goes through the filter, and then when it comes to act on the response there is no response for it to act on.
    Hence it throws a null pointer exception.

    It's possible to code round that in the CompressrionResponseWrapper

    and in the CompressionFilter itself.


    But I don't understand why this should be the case. And I'm not sure whether the issue that intermittently affects the .html is the same as always affects the .jsp
    It's like simply no response is being generated by the Container.
    El Laped
    Greenhorn

    Joined: May 18, 2014
    Posts: 1
    Good book. I am at the end of it. I have got into the the same problem.
    It bugged me so I have looked deeper.

    In order to see the output of the jsp, you need to flush the output buffer somewhere along the chain.
    For testing, you can just put a scriptlet at the end of the jsp "out.flush();" You will see the jsp in full in the browser.

    In the CompressionFilter, after the call the the filterchain "doFilter" method, you need to flush the response. Something like "wrappedResp.getWriter().flush();"

    Tomcat has a more complete implementation of the compression filter. Looking at the source code of tomcat you can see that
    - in the filter they call custom finishResponse method on the custom response ->
    - which in turn call close on the custom stream ->
    - which was overrided to perform a flush before doing close on stream.



    Additional interesting resources:
    - http://stackoverflow.com/questions/1159168/should-one-call-close-on-httpservletresponse-getoutputstream-getwriter
    - http://www.oracle.com/technetwork/java/filters-137243.html#72674
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: Compression Filter (Head First Servlets)