Win a copy of Think Java: How to Think Like a Computer Scientist this week in the Java in General forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Filter vs Servlet

 
Bob CHOI
Ranch Hand
Posts: 127
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Is the observation valid that Filter is not only an enhancement to Servlet/GenericServlet/HttpServlet, but also funtionally effecient replacement in most cases?
 
Cameron Wallace McKenzie
author and cow tipper
Saloon Keeper
Posts: 4968
1
Hibernate Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Replacement is a very tough word, but indeed, common functionality across servlets can often be factored into a reusable Filter. The Cocoon framework is almost exactly that - effectively a 'filter based' request-response cycle, which works very well.

You have come to a significant level of enlightenment.

-Cameron McKenzie
 
Bear Bibeault
Author and ninkuma
Marshal
Pie
Posts: 64824
86
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Heck, why bother with a screwdriver when you can bang a screw in with a hammer if you hit it hard enough?
 
Bob CHOI
Ranch Hand
Posts: 127
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks, Cameron!

Another extensive view on below is that Filters have generally advantages over RequestDispatcher aided Servlets.

- implements interface vs extends abstract class
- XML configuration vs hardcoded RequestDispatcher

Filters:



Servlets:



[ January 02, 2007: Message edited by: Bob CHOI ]
[ January 02, 2007: Message edited by: Bob CHOI ]
 
Bob CHOI
Ranch Hand
Posts: 127
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks, Bear!

The oberservation can't be justified without the context - The screwdriver that is better for you is the one suitable for you.
 
Ben Souther
Sheriff
Posts: 13411
Firefox Browser Redhat VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The methods of your servlets and filters will be called at different points along the request/response cycle.

Filters were not meant to be a replacement for servlets.
They allow you to apply pre and post servlet processing.

As Bear suggested, learn about all the tools available to you and learn how to apply the correct one to the task at hand.
 
Bear Bibeault
Author and ninkuma
Marshal
Pie
Posts: 64824
86
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Bob CHOI:
The screwdriver that is better for you is the one suitable for you.


You miss my point. A hammer is never "the screwdriver that is better for you".

There are technical reasons that a filter is not a suitable replacement for a servlet, but even brushing those aside, using a tool incorrectly, even if it can adequately do the job, obfuscates your design and code. Others will not be expecting you to misuse the tool in this manner and all you will do is create confusion and code that deviates from the conventional.

Using unconventional and obfuscating methods "just because I can" is not the sign of a mature developer.
 
Dave Wingate
Ranch Hand
Posts: 262
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Bear's point that replacing all servlets with filters would be to "obfuscate your design and code" is an important one. Another way to highlight the difference between servlets and filters is to consider the types of problems that each is designed to address.

My understanding of filters suggests that they are most powerful when used to modularly address cross-cutting concerns that would otherwise have to be coded in multiple places (ie servlets). But without any servlets, there would be no cross-cutting concerns.

For example, logging & security are both cross-cutting concerns that will apply throughout your application. Filters are one option for addressing those concerns in a single (code) location, rather than writing security and logging code into each servlet you write.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic