|
Last update : April 21 2002
Doc for : v1.3
About
What is Cactus ?
News
Changes
Features/Status
Goals
Roadmap/Todo
Contributors
Contributing
Cactus Users
Tested on ...
License
Downloads
Downloads
Documentation
How it works ?
Getting Started
Mock vs Container
Javadocs
FAQ
Howto Guides
Classpath Howto
Config Howto
Migration Howto
TestCase Howto
Security Howto
Ant Howto
HttpUnit Howto
Sample Howto
EJB Howto
IDE Howto
JUnitEE Howto
Support
Bug database
Mailing list
Misc.
Why the name ?
Logo Challenge
Resources
Stats
Developers
CVS
Coding Conventions
Build results
|
Setting up Cactus Classpaths |
You must understand that your Cactus tests are started by a JUnit
Test Runner (in the client JVM) and that the Cactus TestCase that you
have extended will connect to the Cactus Redirector (in the server
JVM), where your testXXX() methods will be executed. See
How it works to understand the
mechanism.
 |
It is very important that you understand what files you need
to put in the client and server classpaths, as 99% of Cactus
errors come from an incorrect classpath !
|

Client side classpath |
The Cactus tests are started by running a JUnit Test Runner (For
explanations on how JUnit works see the
JUnit web site).
As pictured in figure 1, you need to have the following jars and
classes in your client side classpath :
-
junit.jar : obviously this is needed
for the JUnit Test Runner and because the Cactus
XXXTestCase classes extend the JUnit
org.junit.framework.TestCase class.
-
cactus.jar : well, this is the
Cactus jar containing all Cactus classes,
-
your test classes : these are
your test classes that extend the Cactus
XXXTestCase
classes,
-
servlet.jar or j2ee.jar : these are
the Servlet API / J2EE API interfaces. This
is needed on the client side classpath because your test cases
extend one or several of XXXTestCase which use class
variables that are Servlet / J2EE objects
(HttpSevletRequest , PageContext , ...).
You can get this jar either from your servlet engine or from the
Sun Web Site (
Servlet download page or
J2EE download
page).
-
httpclient.jar : needed for
Cactus Cookie handling.
-
log4j.jar (optional) : only needed
when you want Cactus to output debugging information on the client
side.
-
httpunit.jar ,
Tidy.jar and
xerces.jar (optional) : only needed if you
wish to use
HttpUnit
in your endXXX() methods (see the
HttpUnit Howto tutorial).
The 3 jars mentioned above are part of the HttpUnit distribution.
-
aspectjrt.jar :
AspectJ runtime jar.
 |
If you have the habit of using class variables for the classes
to test (as opposed to declaring them within the
testXXX() method), you'll also need to put your classes
under test in the client side classpath.
|
In addition to the above mentionned jars and classes, you will also
need to put the cactus.properties
configuration file in your classpath (because it is a java properties
file). Details are described in the
Config Howto tutorial).
 |
In theory you would also need to put the
log_client.properties properties file in your classpath.
However a default one is provided in cactus.jar
(and thus is on the classpath as cactus.jar is
itself in the classpath !).
|
|
Server side classpath |
The server side part is a webapp. It can be packaged as a .war file
or as expanded war. It should have the following structure, which
will ensure that the classpath is correct :
-
WEB-INF/lib/cactus.jar : the
Cactus main jar,
-
WEB-INF/lib/junit.jar : this is
needed because the Cactus XXXTestCase extends
the JUnit org.junit.framework.TestCase class.
-
WEB-INF/classes/<your test classes>
: obviously as their testXXX() methods will
get executed in the container.
-
WEB-INF/classes/<your classes under test>
: will be called by your test classes.
-
WEB-INF/lib/log4j.jar (optional) :
only needed when you want Cactus to output debugging information
on the server side.
 |
If you have several webapps that use cactus you may be tempted to
place the cactus.jar in your container's shared library
folder. However, this approach will not work in many cases because
code in a shared location (cactus) cannot access code in a
specific webapp (your test cases). This restriction makes sense
since you would not want com.foo.EvilClass
in webapp A to conflict with com.foo.EvilClass in webapp
B.
|
 |
In theory you would also need to put the
log_server.properties configuration file in your
classpath. However a default one is provided in
cactus.jar
(and thus is on the classpath as cactus.jar is
itself in the classpath !).
|
|
|
|
|