The BileBlog

Next up is the Enterprise AOP talk. This promises to be particularly fun as AOP fans are basically those too lazy to do any thinking or design up front.

The talk starts with a couple of slides talking about modularity in Tomcat. Now, admittedly, I know next to nothing about practical AOP, so I am, at this point, utterly baffled by what I’m looking at graphs that have something to do with code in tomcat.

Shortly thereafter, we’re regaled with a slide pointing out ‘the crosscutting problem’. It dawns on me as this point that the first few slides were basically trying to say that Tomcat has crosscutting concerns, and things like logging are scattered everywhere. The usual suspects are trotted out to advertise the whole thing: non-AOP is ‘inflexible’, ‘unmaintanable’, ‘messy’, and ‘non-modular’.

Ohdear, here we go. The furious arm waving telling us that AOP is as much of a step as OOP. Why oh why must people be so obsessed with the sound of their own flatulence? Why can’t it just be ‘this is AOP, it does some stuff that might be useful’. Why do advocates of this shite need to feel like they’re messiahs?

After the bizarre arm waving interlude, we finally have the basic AOP concepts explained to us. Maybe someone should have pointed out that, amazingly, ‘crosscutting concern’ is in fact gibberish outside of the AOP world, introducing that term up front left many people looking befuddled and sad.

The example trotted out is also misleading. They pick on servlet buffering (basically, response.setBufferSize()) as a good candidate for a rampant round of AOPisation (using AspectJ no less!). Now, maybe I’m crazy and old fashioned, but this strikes me as an exceptionally braindamaged shoehorning of AOP. There’s NEVER any reason to use AOP with servlets. The spec lets you specify filters which can be applied pre and/or post request. No extra jars needed, no fuckfaced precompiling of freaky AspectJ sources, no bytecode genitalia tuggage, no AOP fappery anywhere. This really seems to be someone’s sick idea of Enterprise AOP.

After what seems like hours, the next genius idea introduced is using AOP to prevent servlets from setting the buffer themselves. Again, cruel disregard for the spec and the fact that that functionality is already trivial to achieve by simply using a ResponseWrapper that overrides setBufferSize().

Next construct to be introduced is how to limit the scope of the aspect and only have it apply to a limited set of servlets. Hmmm, yep, spec thought of that too! Welcome to filter url mappings, a modern day wonder provided for free to you by those crazy servlet kids.

Finally, they had the decency to try and highlight with the furious arm waving AOP contrived example with the servlet filter approach. The first slide manages to have many lines which allegedly say why AOP is better, yet somehow, doesn’t manage to actually SAY anything that doesn’t boil down to ‘AOP is better!’. The final ‘proof’ is that the AOP example is all in one class. Needless to say, it ignores the fact that declaring paths and applying filters in web.xml is a hell of a lot nicer than applying a filter to hardcoded classnames. Ultimately I think everyone felt a bit scammed by the ‘AOP is just better!’ argument. Ultimately all the time wasted on the example can currently be trivially done using 3 lines of filter code, and a one line response wrapper.

Of course, no AOP talk would be complete without a logging example. So to illustrate a ‘real world’ enterprise usage, we’re basically insulted with the ‘transfer money from account A to account B and log errors’ example. The only excitement added is some piddly exception handling. So what did we learn from this? Put very simply: avoid AOP, half the people involved in it are asshats who have a disturbing logging fetish.

This entry was posted on Thursday, May 6th, 2004 at 2:20 pm and is filed under General. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.