I'm not sure I'm personally interested in removing AspectJ and replacing with AspectWerkz--Cactus would still need to be preprocessed or launched differently to accommodate it. Plus I'd be hurting my book sales :P That being said, I wouldn't oppose it either.
> As you said, I don't think a simpleAspectJ integration app fits too well > the current Cactus landscape. I see several potential subjects related > to AOP that you could work with in Cactus: I assume you mean any AOP sample app, not just AspectJ... > - decide whether it is possible to use AOP for replacing redirectors (at > least in some cases) I'm intrigued, but puzzled by this one. How do you envision AOP doing away with the need for redirectors? Where would the AOP step in? > Then of course, if you're happy to work on something that's not AOP > related, there's plenty of interesting stuff on the todo page: > http://jakarta.apache.org/cactus/participating/todo.html Yep, I'm happy to do so. (Presuming that's where the help is most needed.) I think that I'd most like to tackle the concurrent tests issue and/or documentation/completion of the custom tag testing framework. (Presuming the replacement of redirectors with AOP is a reasonably large endeavor that won't be fully tackled any time soon.) Cheers, Nick On 6/18/03 11:24 PM, "Vincent Massol" <[EMAIL PROTECTED]> wrote: > > >> -----Original Message----- >> From: Nicholas Lesiecki [mailto:[EMAIL PROTECTED] >> Sent: 19 June 2003 07:31 >> To: [EMAIL PROTECTED] >> Subject: Reopening the Aspects Debate >> >> Hello Cactus developers, >> > > Hi Nick! Welcome back :-) > >> A long while back (just about a year ago, to be precise) I wrote up an >> article on JUnit, AspectJ, and Cactus. >> >> http://www-106.ibm.com/developerworks/java/library/j-aspectj2/ >> >> At the time, I envisioned myself writing a Cactus sample application > that >> would use AspectJ to replace calls to EJBs. Sadly, that has not come > to >> pass, what with writing a book on AspectJ, and being busy in other > ways. >> Still, I feel that I owe the Cactus team some work or at least some >> thought >> on the matter, since I said that I might work on it. >> >> So, my question is: does it make sense to provide a sample-application >> integrating Cactus and AspectJ? The answer may be "no." (though I'm > still >> very in-favor of using it internally to the project). >> >> Here are my thoughts: >> 1) Cactus and MO are very different approaches. AspectJ really > supports >> MO, >> not IC testing. Of course you can combine the two approaches (use MOs > in >> your Cactus test). However, I'm not sure it's the place of Cactus to > say >> anything in particular about which of the many MO frameworks you use > to do >> your mocking. AspectJ is actually somewhat weak for providing MOs in > my >> opinion. The syntax for overriding a method call in a specific >> circumstance >> is not terribly easy and requires more effort than simply subclassing > or >> using an interface based framework like EasyMock. (And refactoring to >> allow >> traditional mock objects often yields good side-benefits to the code.) > > Yep. I completely agree on several points: > > - Cactus and MO are difference although MO can be used in a cactus tests > (to prevent database access fro example). > > - One way to use AOP in Cactus is to remove the need for the Redirectors > (in some cases, it's not possible for all cases I think). In that case, > interception would be done on existing components (Servlets, Filters, > EJBs, etc). > > - AspectJ is no longer my favorite AOP framework. It is certainly the > most powerful but it is not the most development-friendly. Other > frameworks have emerged and my current favorite for using AOP for unit > testing is AspectWerkz (this is what I am currently researching). The > main advantages are: > - a pure Java API (hence no need for a pre-compiler) > - ability to add/remove advice at runtime (I'm in discussion with the > author on this point as it is not yet 100% working) > - dynamic weaving > >> >> 1a) Conversely, if you use AspectJ to do your call replacement, > there's no >> need to be running Cactus. You certainly can, but most often you want > to >> run >> your code outside of the container if you've gone through the trouble > of >> mocking things up. > > yep > >> >> 2) Integrating AspectJ into your project requires compiling with ajc. > This >> means that creating a sample application that used AspectJ would > require >> instructions, troubleshooting, and support for a variety of AspectJ >> related >> issues with regard to the sample app. That's not to say that it isn't >> worth >> doing, the sample simply has to be worth more to justify the > additional >> support cost. > > Yep, see above. I would rather do the sample with AspectWerkz... > >> >> So, what are the team members' opinions: should I create a simple > AspectJ >> integration app as described in the article above, or should I spend > my >> efforts elsewhere on the project (perhaps in another Aspectj related >> area?) > > hmmm.... > > As you said, I don't think a simpleAspectJ integration app fits too well > the current Cactus landscape. I see several potential subjects related > to AOP that you could work with in Cactus: > > - find out other places where using an AOP approach is interesting in > Cactus. > > - replace AspectJ by AspectWerkz in Cactus code. Not sure how mature > AspectWerkz (I've just tried it very briefly) is but it certainly looks > very nice. > > - decide whether it is possible to use AOP for replacing redirectors (at > least in some cases) > > Then of course, if you're happy to work on something that's not AOP > related, there's plenty of interesting stuff on the todo page: > http://jakarta.apache.org/cactus/participating/todo.html > > Thanks > -Vincent > >> >> >> Cheers, >> nick >> >> >> --------------------------------------------------------------------- >> 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
