• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

HFJS: Filters + Wrappers Explaination pg 721

 
Ranch Hand
Posts: 61
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Dude,

Lost in the sauce...I do not understand what is going on.

1) The ServletResponseWrapper is a decorator pattern in action...makes sense.

2) The Filters are configured in the DD and a filterImpl must implement the Filter interface contract...makes sense.

3) A request that is to be filtered will be matched agianst url-patterns first, in a chaining order (the order they are declared in) followed by the servlet-name chain...makes sense.

4) The servlet at the end of the chain has no idea about the filters...makes sense.

5) So how does using a custom wrapper object sent on the Filter.doChain(req,customResponseObject) notify the servlet that the incoming request is from a filter?

The only thing I can think of (guessing) is that the HttpServletResponse(response) decoration occuring, somehow says, "Hey, I'm custom and I need you servlet to respond at TheAwesomeFilter.do
 
Ranch Hand
Posts: 44
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
1. Filters follow stack processing.
2. The control always comes back to the filter thru which it has passes in the reverse sequence.
3. And being you have wrapped the container's response object, you are not writing directly to the response object but your own custom made response object.
4. So once you come back from the servlet in the filter, then you can take action on what needs to go to response.

So the notification from the servlet to filter always happens whether it is wrapped response or not. It is just a matter that you have wrapped the response hence container didn�t have any chance to write to the actual response object.

I hope, this clarifies your doubt.

Thanks,
Atul Samnerkar
 
pie sneak
Posts: 4727
Mac VI Editor Ruby
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Michael Vargenstien:
5) So how does using a custom wrapper object sent on the Filter.doChain(req,customResponseObject) notify the servlet that the incoming request is from a filter?

The only thing I can think of (guessing) is that the HttpServletResponse(response) decoration occuring, somehow says, "Hey, I'm custom and I need you servlet to respond at TheAwesomeFilter.do


@5) Looks like you wrapped the response in this case, not the request.

I think you are having a hard time understanding because you're expecting a response wrapper to do something it was never meant to do.

It might become slightly clearer if you read up on the Decorator pattern. Basically, you'd wrap the request or response to change the way the request or response behaves and this happens transparently to the servlets - the servlets have no clue if they're communicating with a true naked request/response or a wrapped version of either one.

You have to look at the APIs of request and response to see what methods you might want to alter the behavior of.

I once had an application where we wanted every single text field to be trimmed so that there would never be leading or trailing space characters. A lot of the fields were number and money values and a value like "20 " with a space wouldn't pass number validation. I could have trimmed every single value at 1000 or so different spots in code but that would have been a nightmare to maintain. All I had to do was wrap the request in a wrapper that overrides the methods for getting parameters, and all those methods would do is trim the values before return them from the method. So the problem was solved with a filter and wrapper and I didn't have to change one line of code in Servlets or any other code.
 
reply
    Bookmark Topic Watch Topic
  • New Topic