I mean to respond to this, I just haven't had the time yet. I will probably do so sometime this week.
Cheers, Nick > -----Original Message----- > From: Christopher Lenz [mailto:[EMAIL PROTECTED]] > Sent: Thursday, January 16, 2003 9:08 AM > To: Cactus Developers List > Subject: Cactus and AspectJ > > > 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]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
