Hi Chad,

> -----Original Message-----
> From: Chad Woolley [mailto:[EMAIL PROTECTED]
> Sent: 31 December 2003 10:34
> To: [EMAIL PROTECTED]
> Subject: Re: [Vote/Action plan/Feedback] Cactus2
> 
> Nicholas Lesiecki wrote:
> 
> >On the subject of new team members. I think Chad would be an
excellent
> >addition to the Cactus team.
> >
> >
> Thanks for the recommendation, although I don't know how much time I
> will have either!

That's ok. Providing your expertise in AOP testing is already very
valuable and is what I call contributing :-)

> 
> >As for the proposal itself, I have 3 areas of feedback.
> >
> >1) AW vs. AJ
> >
> >I think I prefer the stability and maturity of AspectJ, but I
understand
> >that it requires more tool support.
> >
> >One question I have, how well do AspectJ and AspectWerkz play
together?
> >Personally, I am planning on integrating AspectJ into our production
> system
> >in the near future. I would hate to be shut out of Cactus2 because of
> that
> >decision. (I'm not convinced that AspectWerkz is mature enough to use
in
> >production.) I would actually cite AspectJ's tool support (crosscut
> >browsing, for instance) as a bonus for users committed to the idea of
> AOP.
> >The only users I would worry about would be those who did not wish to
do
> AOP
> >except for Cactus.
> >
> >We could consider a dual implementation approach (AspectWerkz and
> AspectJ)
> >as Chad Wooley did for EasyMock. This could be a lot of trouble, but
> might
> >be manageable if we delegate a lot of the actual code to POJO's.
> >
> >
> >
> I think Nick meant to type "VirtualMock" instead of "EasyMock" in the
> last paragraph.  Supporting both could be a good idea.  However,
> Vincent's current approach of directly using the AspectWerkz syntax
(via
> xdoclet-style tags) would not be compatible with AspectJ.  If the AOP
> syntax were hidden by the API, though, it would definitely be possible
> to support both.  I still believe that this may be the best approach,
> but it would all depend on whether or not the API could be made
flexible
> enough without exposing the AOP syntax.

See my answer to Nick's email for my POV on the façade API.

> 
> I like the approach of pulling all possible logic out of aspects into
> POJOs, but this may be a moot point with the xdoclet-style syntax.

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.

> 
> >3) Obviously, bringing in Aspects opens up whole new realms of unit
> testing
> >possibilities. The question is, what will Cactus contribute on top of
> those?
> >Will we have our own mocking framework that uses AOP?
> >
> >
> >
> I think the best case would be if there were a flexible, independent
> framework for using mock objects which Cactus can use.  

Honestly I don't think the mock object part will much used by Cactus
users. For 2 reasons:

1/ In most cases, when people use (or will use) Cactus, it will be to
perform integration unit tests (= white box functional tests). Thus they
want to run the real stuff

2/ If they need not to call a given layer (say the database layer), they
will be able to use the aspect notation to return canned values. Of
course, they'll also be able to use EasyMock and possibly VirtualMock
too (we'll have to do some tests to ensure Cactus will play well with
VirtualMock).

> VirtualMock
> might fill this role, but it is still in the early stages, and limited
> in some ways.  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'm looking foward to seeing cactus2 evolve, and would be glad to
help.

Very cool!

Thanks
-Vincent


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to