RE: [Vote/Action plan/Feedback] Cactus2

[Vincent Massol <vm...@pivolis.com>]

> -----Original Message-----
> From: Chad Woolley [mailto:lists@thewoolleyweb.com]
> Sent: 31 December 2003 20:28
> Cc: cactus-dev@jakarta.apache.org
> 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: cactus-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: cactus-dev-help@jakarta.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org