In response to Vincent: <<< 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!) >>>
I agree with Vincent--more of Cactus' code could use AspectJ. Again, however, finding the right spots to do it can be difficult. I think this is the most compelling use case until we are more familiar with AOP. > * 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. Yes, I still mean to continue this. However, I probably need to open the discussion up about what would make a valuable addition to Cactus. Unfortunately, MockObjects are simpler in most cases (though AspectJ trumps them when you wish to use Mock EJBs or Mock static method calls). What AspectJ can do is neatly swap in a mock object when necessary. However, is this useful to Cactus as an in-container testing framework? I don't know. Anyway, that's probably a separate discussion. (You can see some of my investigation and conclusions in: http://www-106.ibm.com/developerworks/java/library/j-aspectj2/?loc=j) In response to Chris: <<< 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. >>> I agree that it's not a total logging solution, but I really would rather not see all of the removed log calls re-added to the source. I respond to the drawbacks: <<< 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. >>> This is probably the best point, though AspectJ 1.1 does better dependency checking (or will if it ever emerges from beta). <<< 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. >>> For us yes, they need to be readable. However, they *are* readable if you know a little about AspectJ. For our users, they don't really need to be, as most of the time they don't need to analyze the Cactus stack trace. <<< 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. >>> Yes, it's AspectJ's fault. I agree that we should probably run only one source/class munging tool on the cactus source. However, I'd say Clover is the one to go. Cheers, Nick > -----Original Message----- > From: Vincent Massol [mailto:[EMAIL PROTECTED]] > Sent: Friday, January 31, 2003 2:14 PM > To: 'Cactus Developers List' > Subject: RE: Cactus and AspectJ > > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
