Setting the Cactus CLASSPATH

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.

    Note 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 !

    Classpaths

    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.

    Note 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).

    Note 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.

    Note 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.

    Note 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 !).





    Copyright © 2000-2002 The Apache Software Foundation. All Rights Reserved.