Web Application Filters were added to the 2.3 Servlet specification and have been
enhanced in the just finalised 2.4 spec. Filters
allow cross cutting concerns to be applied to a web application, which is
exactly the gig of Aspect Oriented Programming (AOP).
Being born and breed with OOP, I have always viewed AOP in the cool but
useless category. Thus I’ve never given myself the opportunity to
use them for real. On the other hand, I view webapp Filters as useful
but ugly. It would be great if AOP could replace/enhance Filters so we
could get into the cool and useful territory.
So I downloaded AspectJ with the intent of seeing how AOP cross cutting
concerns could help. The example I considered was the CompressionFilter, which can be applied to
a web applications to gzip the content generated on the fly. A compression
filter can be declared in web.xml with :
<filter> <filter-name>Compression</filter-name> <filter-class>com.acme.CompressionFilter </filter-class> </filter> <filter-mapping> <filter-name>Compression</filter-name> <url-pattern>*.html</url-pattern> <dispatcher>REQUEST</dispatcher> <dispatcher>FORWARD</dispatcher> <dispatcher>ERROR</dispatcher> </filter-mapping>
This CompressionFilter will apply to any request to a URL ending with html
that is not an
include request. The filter wraps the HttpServletResponse object with a facade, that
in turn wraps any OutputStream or Writer provided by the response with a version capable
of compression the output. The wrappers also allow HTTP headers to be intercepted and
adjusted. The multiple wrappers involved have always stuck me as a bit over complex, error
prone and in need of a better way. But it does allow the compression concern to be applied
to a web application without considering how the html content is generated.
So how would aspectJ help applying such a cross cutting concern to a webapplication?
Reading the tutorial I determined that the basic approach needed was to define a
CompressionAspect that contains:
- PointCut definitions that identified the getOutputStream and getWriter calls
of the response object. - Advice to wrap the response stream/writer in a compressing stream/writer
- PointCut definitions that identified the header setting methods of the response object.
- Advice to intercept and adjust the HTTP headers and other meta data.
AspectJ certainly provides the Join Points and Advice types required to create this
aspect, but unfortunately I was unable to define PointCut that capture the equivalent
semantics of the CompressionFilter declaration above. I believe that the Point Cut semantics
required are something along the lines of:
calls to getOutputStream, getWriter & setContentLength methods
on objects that implement the HttpServletResponse interface
when RequestDispatcher.include is not on the calling stack
and the associated request.getRequestURI() ending with '*.html'
and the request is being handled by my webapplication/classloader
It was looking oh-so-good up to those last two clauses! The ending with ‘*.html’ could
be done with an if() point cut, except that there is no way to navigate from a response
object to the associated request. I couldn’t find any point cuts that would assist me
with restricting the aspect to a particular web application or classloader.
My next thought was to get around this problem by creating a no-op Filter and hanging the
PointCut off calls that go via it. I think this approach would have allowed me to
specified the required PointCuts, but then I realized another problem. In order for
these point cuts to work, I would need to use the AspectJ compiler to modify the response
classes used by the web container and passed into the web application. This breaking of
web application encapsulation was not something that I am prepared to do. It would
modify my infrustructure and aspects from one webapplication to be passed if not
executred to other webapplications.
AOP or at least AspectJ, does not appear to be a good replacement for Filters, as:
- PointCuts are defined in the implementation domain (java calls and classes),
while Filters are defined closer to the application domain (URLs, requests, responses). Using
the implementation domain events to trigger application level concerns may be impossible or
at the very least devoid of the application abstractions we so carefully build in OOP. - The technology of AspectJ does not appear appropriate for Container/Infrastructure
based deployment. It is not appropriate for the container/infrastructure classes to
be modified in order to support the application concerns of a particular application. - The declarative nature of aspects means that PointCuts needs to do a lot of work to
reduce a global scope to a particular instance. It would be great if procedural semantics
were available so you could say in code: “wrap that object with this aspect” or “apply this
advice to that Point Cut”. Such programatic code would also assist with the tracebility
concerns of AOP.
So my first attempt at AOP has not been successful and I’m still left with the “cool but useless”
feeling. The OOP design of Filters does allow cross cutting concerns to be implemented
in a modular fashion, so useful if not cool applies.
Maybe I’m still missing something or am trying the wrong problem. I hope that an AOP
guru reading this will be able to correct the error of my ways?