Cactus and AspectJ

[Christopher Lenz]

Folks,

this is likely a quite controversial message, but I'd like to state my opinion on this matter and get some feedback.

The Cactus framework is currently using AspectJ (since when?). AspectJ is used for a LogAspect, which is responsible for logging trace-level messages when a method is entered/exited. This looks like a good solution, as you read about logging as one of the primary examples in every introduction about AOP.

However, my concern that we're paying to high a "price" for a pretty small gain. The gain is that AspectJ separates parts of the logging aspect of Cactus from the "actual" code.

But really only *parts* of the logging aspect. If we want any logging above the method-enter/exit traces, we call Commons-Logging directly from the code. And often enough, that is the kind of logging that really matters: the developer makes an informed decision that the relevant section of code is critical enough to emit a log message.

The "price" we pay:
1 An additional runtime dependancy (aspectjrt.jar)
2 Additional build dependancies: the AspectJ compiler and the Ant
tasks, and - although currently disabled - the AspectJ javadoc. A
build-time dependancy is in some ways worse than a runtime dependancy
because it complicates the build file.
Also note that the AspectJ compiler doesn't provide good dependancy
checking (probably because it can't, it's all about cross-cutting
concerns after all), so an edit to a single source file causes a
complete recompile.
3 Obscured stack traces: the traces contain "weird" around_699()-style
methods that are confusing. Especially for a testing framework such
as Cactus, readable stack traces are pretty important IMHO.
4 The Clover-generated code coverage reports shows code that looks
different than the original code. I'm not 100% sure if this is still
true, or whether it's actually the fault of AspectJ.

Now, I'm not saying any of these disadvantages are very critical. But I do think they by far outweigh the benefits provided by AspectJ for Cactus. For example, if there were plans to make more use of AOP in the code base, that would put the whole situation into a different light.

Contra?

--
Christopher Lenz
/=/ cmlenz at gmx.de


--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>