> -----Original Message----- > From: Chad Woolley [mailto:[EMAIL PROTECTED] > Sent: 31 December 2003 20:28 > Cc: [EMAIL PROTECTED] > Subject: RE: [Vote/Action plan/Feedback] Cactus2 > > Vincent Massol wrote: > > Can someone explain to me what is this POJO idea? What code are we > > talking about? If you're taking about existing Cactus code, it will not > > be there anymore in Cactus v2. > > Well, in VirtualMock, at least, there is really just a couple of simple > "global" aspects. In AspectJ, your aspect is written in AspectJ syntax, > not plain java. This means that it doesn't play well with your IDE > unless you have the right plugins, and even then can't be manipulated as > richly as a plain java class (automated refactoring, for example). > > Also, since I support both AspectWerkz and AspectJ, there are two sets > of aspects which do the same thing. > > In order to minimize duplication and also minimize the issues of dealing > with non-java AspectJ aspects, I have tried to refactor as much logic as > possible out of the aspects, and into plain java helper classes (there's > still some more I could refactor out, too). > > This can be considered a "layer" between the aspects and the rest of the > apps. Since I'm supporting two frameworks, there is really two layers: > One that is framework-specific, and another that is framework- > independent. > > However, for non-global aspects, which are defined and applied on a > per-class or per-method level, I'm not sure if this approach is relevant.
Ok. I understand. Thanks. I'll surely try to use as many POJOs as possible in Cactus implementation. > > Another important point to mention is the compatibility of different AOP > frameworks, and even compatibility within the same framework. > > For example, as the use of AOP becomes more widespread, people will want > to use Cactus to test their apps which are already using AOP or bytecode > manipulation for their own purposes. This raises several issues to be > concerned about: > > * Trying to weave the same code with two different AOP frameworks > * Trying to re-weave the same code twice with the same framework > (something that I'm pretty sure makes AspectJ blow up, Nick can probably > confirm). > * Integrating well into existing build processes. > * Trying to weave application-specific aspects at the same time as > cactus aspects (this might just be a restatement of the first point). > * Integrating with other tools which perform bytecode manipulation > (Hansel, Clover, etc). > > I'm definitely no expert in AOP, and I'm still struggling to fully > understand these issues. However, they are the types of problems I've > had to think about with VirtualMock, and will probably be encountered by > Cactus or any other AOP-based framework. Good points. I agree we'll need to watch for this. However, I believe it'll be more an issue for the Aspect frameworks themselves than for Cactus. For example, AspectJ has had to make modifications to their code to support EJB weaving (that was a bug report I submitted a long time ago), etc. But I do agree that it'll be challenging... ;-) > > > >> I started a thread today on the jmock-dev mailing list to > >> discuss a proposal for a standard, flexible mock-object API. > > > > I've followed the thread and although your intention is noble (hmm... > > that doesn't ring English!), I'm not sure anything will come out of the > > discussion :-) I believe it's fine to have different mock object > > frameworks (especially as they are for different purposes). > > > > <personal pov> > > In addition I don't believe much in creating "artifical" standards. > > Standards should become standard because they are used and recognized as > > such. In any case, I don't see how you'll force open source projects > > (i.e. people working in their free time usually) to all abide by a > > common interface that has not proved its value (especially in a new > > domain like mock objects where discoveries are still being made). > > </personal pov> > > > > I guess standard was the wrong word to use. My goal is one flexible, > extensible API which has most of the best features of the current > independent APIs. This may or may not become a "standard", but it would > allow users to perform diverse mock tasks in a consistent way using a > single API, which is not currently possible. Yep. On a related subject, in my opinion Cactus2 should be as transparent as possible WRT these mock objects frameworks. In other words, users should be able to use any mock objects fwks including Virtual Mock. Thanks -Vincent > > Thanks, > Chad > > --------------------------------------------------------------------- > 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]
