Hi Chris, It is indeed controversial! :-)
To make it short, yes, I would like to add more pointcuts. Ok, a bit more of history: * Some time ago, I had introduced another use of AOP in Cactus. It was a configuration checker that was checking if the user configuration of Cactus was ok and it was reporting nice and informative errors if it were not. I can't remember why I removed it (maybe because I have done it in a "better" way using standard exceptions). I can't really recall * Nick Lesiecki and I are quite enthusiastic about AOP and more specifically using AOP for unit testing. The idea is to provide the same testing flexibility as Mock Objects but in a much much simpler way. We wanted (and still want) to add some AOP testing functionality to Cactus in Cactus 2.0. Nick has had to work on some other stuff but I know we is still keen to continue this. You can search the developer archives for AOP or AspectJ. There were issues with the static weaving thing issue which prevented us doing nifty things in Cactus. I was eagerly waiting for AspectJ 1.x in order to get weaving of bytecode. It is there now but I haven't found the time to investigate it yet. I would really like to continue using AOP in Cactus and research it more. There are several axis of research: 1/ as a development tool for the cactus framework itself, i.e. find other usages in addition to logging. I'm open to suggestion. BTW, this is what I find the hardest in AOP: finding usages for it (it may have to do with my mindset working in "traditional" ways!) 2/ as ways to simplify Cactus, i.e. could it be used instead of the redirectors to intercept calls inside the container? That would eliminate the need to configure the cactus redirectors in web.xml... 3/ as solution to improve In-container testing by providing easy to use mock replacement (Cactus 2.0) Ideas? Comments? Thanks -Vincent PS: I would hate to have to put entry and exit log statements in every public method... :-) > -----Original Message----- > From: Christopher Lenz [mailto:[EMAIL PROTECTED]] > Sent: 16 January 2003 17:08 > 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:cactus-dev- > [EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:cactus-dev- > [EMAIL PROTECTED]> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
