You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cactus-dev@jakarta.apache.org by Vincent Massol <vm...@pivolis.com> on 2003/12/09 12:26:45 UTC
[Proposal] Cactus2 architecture ideas
Hi Gang,
I've been thinking a lot about Cactus these days and more specifically
I've tried to create a Cactus SPI for test cases and connectors. I first
refactored the existing code to make an SPI surface (this is what is
currently in Cactus CVS). It looked good to me... until I started to
think about how I would use it with an EjbTestCase for example. As Chris
rightly said, I found that there are not many common points between the
current XXXTestCase (where XXX = Servlet, Jsp, Filter) and an
EjbTestCase. What would the beginXXX() method mean for EJBs? What would
the endXXX() method mean? But even if it did mean something, what would
the advantage of having an EjbTestCase? Answer: not much. If the EJB is
remote, I can test it with a pure JUnit solution. If it is local then I
can test it by doing a new MyEJB() and then use a mock context. So, what
would be nice to have from a user point of view?
The answer gave me another "vision" for Cactus' future. This new
"vision" does not change the current "vision" I posted a few days ago.
However it complements it and gives a potential new Cactus architecture.
Here's what I think would be great for Cactus to provide:
1- a way to intercept calls made in any container. Why? Because for pure
unit tests we already have mock objects. For functional tests we already
have tools like HttpUnit, etc. However what we don't really have is a
way to run functional tests *and* the ability to intercept any call
happening in the container so that integration unit tests can be
performed. There could be 2 ways of using this interception:
* by intercepting the component entry point (whatever that is), the
integration unit test could completely redirect the call flow and call
any method for which a unit test is required
* by preventing the calls to propagate to some layers (like the
database layer). This allows testing some portion of the code in
integration while isolating other parts.
2- a way to automate the whole process, i.e. start the container, deploy
the components + tests, run the tests, stop the container.
Actually all this is not new. I had started discussing it in 2002 if I
recall correctly. However AOP and interception techniques were quite new
at that time.
What I'm proposing here is to restart this discussion as I really
believe we can make something very powerful and more generic than the
current architecture.
A Cactus test would be the composition of a standard JUnit test
(whatever the kind of test: HttpUnit, pure JUnit, whatever other JUnit
extension) and an "Aspect" (i.e. the definition of interception points
and what test logic to apply at those points). See the image attached
for a 10,000 feet overview.
Some further ideas:
- the cactification would weave the test aspects into the runtime code
- it might be best to reuse an existing AOP framework instead of using
directly cglib/asm/bcel/etc as we need a generic interception API.
- it might be best to use one of the Java-based framework (AspectWerkz
for example) instead of a non-java based one (like AspectJ). I believe
AspectJ is way more powerful but being non-java is not very friendly
with development environments.
- interception allows to unit test private methods easily.
- the core framework will lighten a *lot* because:
- we use existing JUnit extensions to provide the functional testing
part. For example the whole HTTP connection stuff is left to HttpUnit
instead of developing it ourself
- we use an existing AOP framework for the interception part
- we may or may not need to define standard pointcuts for different
component APIs (servlets, taglibs, filters, ejbs, etc).
- this would be the basis for Cactus 2.0 as the new architecture is
completely new.
- this would make Cactus much more open and flexible. Thus we could
concentrate on offering end to end usability (automation of end to end
integration unit testing). We start doing this in Cactus 1.5. We could
push it a level further as a main advantage of Cactus.
- I need to check what Chad has been doing lately with his AOP-testing
framework (virtualmock) as this is going in the same direction.
I'm getting really excited by all this stuff! :-)
What do you think?
Thanks
-Vincent
RE: [Proposal] Cactus2 architecture ideas
Posted by Vincent Massol <vm...@pivolis.com>.
> -----Original Message-----
> From: Christopher Lenz [mailto:cmlenz@gmx.de]
> Sent: 10 December 2003 15:24
> To: Cactus Developers List
> Subject: Re: [Proposal] Cactus2 architecture ideas
>
> Vincent,
>
> I think I'll need to see what a Cactus2 test case would actually look
> like in code. I've done hardly nothing with AOP as of yet, so I can't
> say I understand much of your proposal. The idea sounds interesting,
> but I just can't imagine how it would work...
> :-P
yep, I agree. I'm preparing a proof of concept ATM.
Thanks
-Vincent
>
> Cheers,
> Chris
> --
> Christopher Lenz
> /=/ cmlenz at gmx.de
>
> Am 09.12.2003 um 12:26 schrieb Vincent Massol:
> > Hi Gang,
> >
> > I've been thinking a lot about Cactus these days and more
specifically
> > I've tried to create a Cactus SPI for test cases and connectors. I
> > first
> > refactored the existing code to make an SPI surface (this is what is
> > currently in Cactus CVS). It looked good to me... until I started to
> > think about how I would use it with an EjbTestCase for example. As
> > Chris
> > rightly said, I found that there are not many common points between
the
> > current XXXTestCase (where XXX = Servlet, Jsp, Filter) and an
> > EjbTestCase. What would the beginXXX() method mean for EJBs? What
would
> > the endXXX() method mean? But even if it did mean something, what
would
> > the advantage of having an EjbTestCase? Answer: not much. If the EJB
is
> > remote, I can test it with a pure JUnit solution. If it is local
then I
> > can test it by doing a new MyEJB() and then use a mock context. So,
> > what
> > would be nice to have from a user point of view?
> >
> > The answer gave me another "vision" for Cactus' future. This new
> > "vision" does not change the current "vision" I posted a few days
ago.
> > However it complements it and gives a potential new Cactus
> > architecture.
> >
> > Here's what I think would be great for Cactus to provide:
> >
> > 1- a way to intercept calls made in any container. Why? Because for
> > pure
> > unit tests we already have mock objects. For functional tests we
> > already
> > have tools like HttpUnit, etc. However what we don't really have is
a
> > way to run functional tests *and* the ability to intercept any call
> > happening in the container so that integration unit tests can be
> > performed. There could be 2 ways of using this interception:
> > * by intercepting the component entry point (whatever that is),
the
> > integration unit test could completely redirect the call flow and
call
> > any method for which a unit test is required
> > * by preventing the calls to propagate to some layers (like the
> > database layer). This allows testing some portion of the code in
> > integration while isolating other parts.
> >
> > 2- a way to automate the whole process, i.e. start the container,
> > deploy
> > the components + tests, run the tests, stop the container.
> >
> > Actually all this is not new. I had started discussing it in 2002 if
I
> > recall correctly. However AOP and interception techniques were quite
> > new
> > at that time.
> >
> > What I'm proposing here is to restart this discussion as I really
> > believe we can make something very powerful and more generic than
the
> > current architecture.
> >
> > A Cactus test would be the composition of a standard JUnit test
> > (whatever the kind of test: HttpUnit, pure JUnit, whatever other
JUnit
> > extension) and an "Aspect" (i.e. the definition of interception
points
> > and what test logic to apply at those points). See the image
attached
> > for a 10,000 feet overview.
> >
> > Some further ideas:
> > - the cactification would weave the test aspects into the runtime
code
> > - it might be best to reuse an existing AOP framework instead of
using
> > directly cglib/asm/bcel/etc as we need a generic interception API.
> > - it might be best to use one of the Java-based framework
(AspectWerkz
> > for example) instead of a non-java based one (like AspectJ). I
believe
> > AspectJ is way more powerful but being non-java is not very friendly
> > with development environments.
> > - interception allows to unit test private methods easily.
> > - the core framework will lighten a *lot* because:
> > - we use existing JUnit extensions to provide the functional
testing
> > part. For example the whole HTTP connection stuff is left to
HttpUnit
> > instead of developing it ourself
> > - we use an existing AOP framework for the interception part
> > - we may or may not need to define standard pointcuts for different
> > component APIs (servlets, taglibs, filters, ejbs, etc).
> > - this would be the basis for Cactus 2.0 as the new architecture is
> > completely new.
> > - this would make Cactus much more open and flexible. Thus we could
> > concentrate on offering end to end usability (automation of end to
end
> > integration unit testing). We start doing this in Cactus 1.5. We
could
> > push it a level further as a main advantage of Cactus.
> > - I need to check what Chad has been doing lately with his
AOP-testing
> > framework (virtualmock) as this is going in the same direction.
> >
> > I'm getting really excited by all this stuff! :-)
> >
> > What do you think?
> >
> > Thanks
> > -Vincent
> >
> >
---------------------------------------------------------------------
> > 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
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
Re: [Proposal] Cactus2 architecture ideas
Posted by Christopher Lenz <cm...@gmx.de>.
Vincent,
I think I'll need to see what a Cactus2 test case would actually look
like in code. I've done hardly nothing with AOP as of yet, so I can't
say I understand much of your proposal. The idea sounds interesting,
but I just can't imagine how it would work...
:-P
Cheers,
Chris
--
Christopher Lenz
/=/ cmlenz at gmx.de
Am 09.12.2003 um 12:26 schrieb Vincent Massol:
> Hi Gang,
>
> I've been thinking a lot about Cactus these days and more specifically
> I've tried to create a Cactus SPI for test cases and connectors. I
> first
> refactored the existing code to make an SPI surface (this is what is
> currently in Cactus CVS). It looked good to me... until I started to
> think about how I would use it with an EjbTestCase for example. As
> Chris
> rightly said, I found that there are not many common points between the
> current XXXTestCase (where XXX = Servlet, Jsp, Filter) and an
> EjbTestCase. What would the beginXXX() method mean for EJBs? What would
> the endXXX() method mean? But even if it did mean something, what would
> the advantage of having an EjbTestCase? Answer: not much. If the EJB is
> remote, I can test it with a pure JUnit solution. If it is local then I
> can test it by doing a new MyEJB() and then use a mock context. So,
> what
> would be nice to have from a user point of view?
>
> The answer gave me another "vision" for Cactus' future. This new
> "vision" does not change the current "vision" I posted a few days ago.
> However it complements it and gives a potential new Cactus
> architecture.
>
> Here's what I think would be great for Cactus to provide:
>
> 1- a way to intercept calls made in any container. Why? Because for
> pure
> unit tests we already have mock objects. For functional tests we
> already
> have tools like HttpUnit, etc. However what we don't really have is a
> way to run functional tests *and* the ability to intercept any call
> happening in the container so that integration unit tests can be
> performed. There could be 2 ways of using this interception:
> * by intercepting the component entry point (whatever that is), the
> integration unit test could completely redirect the call flow and call
> any method for which a unit test is required
> * by preventing the calls to propagate to some layers (like the
> database layer). This allows testing some portion of the code in
> integration while isolating other parts.
>
> 2- a way to automate the whole process, i.e. start the container,
> deploy
> the components + tests, run the tests, stop the container.
>
> Actually all this is not new. I had started discussing it in 2002 if I
> recall correctly. However AOP and interception techniques were quite
> new
> at that time.
>
> What I'm proposing here is to restart this discussion as I really
> believe we can make something very powerful and more generic than the
> current architecture.
>
> A Cactus test would be the composition of a standard JUnit test
> (whatever the kind of test: HttpUnit, pure JUnit, whatever other JUnit
> extension) and an "Aspect" (i.e. the definition of interception points
> and what test logic to apply at those points). See the image attached
> for a 10,000 feet overview.
>
> Some further ideas:
> - the cactification would weave the test aspects into the runtime code
> - it might be best to reuse an existing AOP framework instead of using
> directly cglib/asm/bcel/etc as we need a generic interception API.
> - it might be best to use one of the Java-based framework (AspectWerkz
> for example) instead of a non-java based one (like AspectJ). I believe
> AspectJ is way more powerful but being non-java is not very friendly
> with development environments.
> - interception allows to unit test private methods easily.
> - the core framework will lighten a *lot* because:
> - we use existing JUnit extensions to provide the functional testing
> part. For example the whole HTTP connection stuff is left to HttpUnit
> instead of developing it ourself
> - we use an existing AOP framework for the interception part
> - we may or may not need to define standard pointcuts for different
> component APIs (servlets, taglibs, filters, ejbs, etc).
> - this would be the basis for Cactus 2.0 as the new architecture is
> completely new.
> - this would make Cactus much more open and flexible. Thus we could
> concentrate on offering end to end usability (automation of end to end
> integration unit testing). We start doing this in Cactus 1.5. We could
> push it a level further as a main advantage of Cactus.
> - I need to check what Chad has been doing lately with his AOP-testing
> framework (virtualmock) as this is going in the same direction.
>
> I'm getting really excited by all this stuff! :-)
>
> What do you think?
>
> Thanks
> -Vincent
>
> ---------------------------------------------------------------------
> 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
RE: [Proposal] Cactus2 architecture ideas
Posted by Vincent Massol <vm...@pivolis.com>.
Once again the image has been stripped... :-(
Here it is:
http://cvs.apache.org/~vmassol/cactus_new/cactus_new_architecture.JPG
Thanks
-Vincent
> -----Original Message-----
> From: Vincent Massol [mailto:vmassol@pivolis.com]
> Sent: 09 December 2003 12:27
> To: 'Cactus Developers List'
> Subject: [Proposal] Cactus2 architecture ideas
>
> Hi Gang,
>
> I've been thinking a lot about Cactus these days and more specifically
> I've tried to create a Cactus SPI for test cases and connectors. I
first
> refactored the existing code to make an SPI surface (this is what is
> currently in Cactus CVS). It looked good to me... until I started to
> think about how I would use it with an EjbTestCase for example. As
Chris
> rightly said, I found that there are not many common points between
the
> current XXXTestCase (where XXX = Servlet, Jsp, Filter) and an
> EjbTestCase. What would the beginXXX() method mean for EJBs? What
would
> the endXXX() method mean? But even if it did mean something, what
would
> the advantage of having an EjbTestCase? Answer: not much. If the EJB
is
> remote, I can test it with a pure JUnit solution. If it is local then
I
> can test it by doing a new MyEJB() and then use a mock context. So,
what
> would be nice to have from a user point of view?
>
> The answer gave me another "vision" for Cactus' future. This new
> "vision" does not change the current "vision" I posted a few days ago.
> However it complements it and gives a potential new Cactus
architecture.
>
> Here's what I think would be great for Cactus to provide:
>
> 1- a way to intercept calls made in any container. Why? Because for
pure
> unit tests we already have mock objects. For functional tests we
already
> have tools like HttpUnit, etc. However what we don't really have is a
> way to run functional tests *and* the ability to intercept any call
> happening in the container so that integration unit tests can be
> performed. There could be 2 ways of using this interception:
> * by intercepting the component entry point (whatever that is), the
> integration unit test could completely redirect the call flow and call
> any method for which a unit test is required
> * by preventing the calls to propagate to some layers (like the
> database layer). This allows testing some portion of the code in
> integration while isolating other parts.
>
> 2- a way to automate the whole process, i.e. start the container,
deploy
> the components + tests, run the tests, stop the container.
>
> Actually all this is not new. I had started discussing it in 2002 if I
> recall correctly. However AOP and interception techniques were quite
new
> at that time.
>
> What I'm proposing here is to restart this discussion as I really
> believe we can make something very powerful and more generic than the
> current architecture.
>
> A Cactus test would be the composition of a standard JUnit test
> (whatever the kind of test: HttpUnit, pure JUnit, whatever other JUnit
> extension) and an "Aspect" (i.e. the definition of interception points
> and what test logic to apply at those points). See the image attached
> for a 10,000 feet overview.
>
> Some further ideas:
> - the cactification would weave the test aspects into the runtime code
> - it might be best to reuse an existing AOP framework instead of using
> directly cglib/asm/bcel/etc as we need a generic interception API.
> - it might be best to use one of the Java-based framework (AspectWerkz
> for example) instead of a non-java based one (like AspectJ). I believe
> AspectJ is way more powerful but being non-java is not very friendly
> with development environments.
> - interception allows to unit test private methods easily.
> - the core framework will lighten a *lot* because:
> - we use existing JUnit extensions to provide the functional testing
> part. For example the whole HTTP connection stuff is left to HttpUnit
> instead of developing it ourself
> - we use an existing AOP framework for the interception part
> - we may or may not need to define standard pointcuts for different
> component APIs (servlets, taglibs, filters, ejbs, etc).
> - this would be the basis for Cactus 2.0 as the new architecture is
> completely new.
> - this would make Cactus much more open and flexible. Thus we could
> concentrate on offering end to end usability (automation of end to end
> integration unit testing). We start doing this in Cactus 1.5. We could
> push it a level further as a main advantage of Cactus.
> - I need to check what Chad has been doing lately with his AOP-testing
> framework (virtualmock) as this is going in the same direction.
>
> I'm getting really excited by all this stuff! :-)
>
> What do you think?
>
> Thanks
> -Vincent
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org