flexibility. Otherwise, any changes to this common authorization logic would have to be
replicated across all the JSP front controllers.
A client who was using eInsure in production submitted some enhancements. They
wanted to prevent access to the application beyond the scheduled office hours of 9 a.m.
to 6 p.m. This would let them use this downtime to run scheduled batch programs more
efficiently. In addition, they wanted to track and analyze the usage pattern of the web
site. Last but not least, they wanted a configurable monitor to track the time spent by
individual page controllers in fulfilling a request. This would be turned on from time to
time to check system performance.
The typical approach in this case would be to create some new components and
change some existing ones. But this is risky as new bugs can be added to the existing
codebase. A careful analysis of these new requirements reveals that they can best be
addressed by applying new reusable components before and after the existing code. It
should be possible to configure and apply these components transparently without
affecting the existing code. This would save lot of time and effort if existing components
had to be altered.
• You want common processing to be centralized into reusable components.
• The preprocessing and postprocessing components should be loosely coupled to
the existing application code.
• Apply common processing declaratively.
Use an intercepting filter to apply reusable processing transparently before and after the
actual request execution by the front and page controllers.
Strategies with the Spring Framework
It is possible to solve some of the requirements mentioned earlier with filters that are
built into the servlet API. All modern web servers provide support for filters—code that is
executed before control passes to a target servlet, after control leaves the servlet, or both.