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.
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.
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.
Thanks, Chad
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
