vmassol 02/04/19 14:36:02
Modified: documentation/docs/xdocs book.xml downloads.xml faq.xml
getting_started.xml how_it_works.xml
howto_ant_cactus.xml howto_ant_install.xml
howto_ant_primer.xml howto_config.xml
howto_httpunit.xml howto_ide.xml
howto_ide_jbuilder4.xml howto_ide_jbuilder5.xml
howto_ide_vajava_tomcat.xml
howto_ide_vajava_wte.xml howto_junitee.xml
howto_sample.xml howto_testcase_filter.xml
howto_testcase_servlet.xml mockobjects.xml
documentation/docs/xdocs/images classpath.jpg config.jpg
documentation/docs/xdocs/misc archi_classpath.ppt
Added: documentation/docs/xdocs howto_classpath.xml
howto_security.xml
Log:
second batch of website documentation updates for Cactus 1.3 compliance. Almost
there ... The Security howto is not finished yet ...
Revision Changes Path
1.5 +4 -1 jakarta-cactus/documentation/docs/xdocs/book.xml
Index: book.xml
===================================================================
RCS file: /home/cvs/jakarta-cactus/documentation/docs/xdocs/book.xml,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- book.xml 14 Apr 2002 21:51:47 -0000 1.4
+++ book.xml 19 Apr 2002 21:36:01 -0000 1.5
@@ -4,7 +4,7 @@
title="Cactus Documentation"
copyright="@year@ The Apache Software Foundation"
updated="@today@"
- docfor="1.2">
+ docfor="1.3">
<menu label="About">
<menu-item label="What is Cactus ?" source="index.xml"/>
@@ -33,6 +33,7 @@
</menu>
<menu label="Howto Guides">
+ <menu-item label="Classpath Howto" source="howto_classpath.xml"/>
<menu-item label="Config Howto" source="howto_config.xml"/>
<menu-item label="Migration Howto" source="howto_migration.xml"/>
@@ -41,6 +42,8 @@
<menu-item type="hidden" source="howto_testcase_servlet.xml"/>
<menu-item type="hidden" source="howto_testcase_jsp.xml"/>
<menu-item type="hidden" source="howto_testcase_filter.xml"/>
+
+ <menu-item label="Security Howto" source="howto_security.xml"/>
<!-- Ant tutorial -->
<menu-item label="Ant Howto" source="howto_ant.xml"/>
1.3 +13 -9 jakarta-cactus/documentation/docs/xdocs/downloads.xml
Index: downloads.xml
===================================================================
RCS file: /home/cvs/jakarta-cactus/documentation/docs/xdocs/downloads.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- downloads.xml 14 Apr 2002 21:51:47 -0000 1.2
+++ downloads.xml 19 Apr 2002 21:36:01 -0000 1.3
@@ -19,8 +19,9 @@
</p>
<ul>
<li>
- <strong><code>jakarta-cactus-<servletapi>-<version>.zip</code>
- </strong> : the Cactus distribution. It contains :
+ <strong><code>jakarta-cactus-<j2eeapi>-<version>.zip</code>
+ </strong> : the Cactus distribution for J2EE <j2eeapi> (where
+ <j2eeapi> = { 1.2 , 1.3 }. It contains :
<ul>
<li>
<strong><code>cactus.jar</code></strong> : the Cactus
@@ -35,9 +36,17 @@
it is finished,
</li>
<li>
+ Dependent libraries that you need to put in your classpath along
+ with the Cactus jars. See
+ <link href="getting_started.html">Getting Started</link> for
+ details.
+ </li>
+ <li>
A Cactus Sample application that shows how to write
- Cactus tests and how to run and deploy them in a servlet engine
- using Ant,
+ Cactus tests for Servlets, Taglibs and Filters (only if you use
+ the J2EE 1.3 API). It also demonstrates how to automate and deploy
+ them in a servlet engine using Ant (scripts for several servlet
+ engines are provided).
</li>
<li>
The Cactus documentation (includes the javadoc + a local copy of
@@ -58,11 +67,6 @@
delivered for releases (and not for nightly builds).
</li>
</ul>
-
- <note>
- <code><servletapi></code> represents the Servlet API
- specifications for which you want to write Cactus unit tests for.
- </note>
<note>
<code><version></code> represents the version number for releases
1.2 +12 -22 jakarta-cactus/documentation/docs/xdocs/faq.xml
Index: faq.xml
===================================================================
RCS file: /home/cvs/jakarta-cactus/documentation/docs/xdocs/faq.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- faq.xml 10 Mar 2002 14:10:25 -0000 1.1
+++ faq.xml 19 Apr 2002 21:36:01 -0000 1.2
@@ -63,11 +63,6 @@
<anchor id="faq2"/>
<s1 title="How can I have a web.xml that is valid both for testing and for
production ?">
- <p>
- <em>submitted by
- <link href="mailto:[EMAIL PROTECTED]";>Erik Hatcher</link></em>
- </p>
-
<s2 title="Question">
<p>
Cactus needs to have a few entries set in the <code>web.xml</code>
@@ -136,11 +131,6 @@
<anchor id="faq3"/>
<s1 title="I'm getting a java.io.StreamCorruptedException error. What does it
mean ?">
- <p>
- <em>submitted by
- <link href="mailto:[EMAIL PROTECTED]";>Nicholas Lesiecki</link></em>
- </p>
-
<s2 title="Solution">
<p>
This exception results when client-side Cactus code attempts to talk
@@ -179,26 +169,26 @@
A good way to check whether your requests are reaching a
Cactus redirector is to manually enter in the URLs for all
of the redirectors you use into the navigation bar of your
- web-browser. If the URL yields a 500 error and you get a
- stack trace (in the log or along with your error page that)
- says <code><![CDATA[Missing service name
- parameter [] in HTTP request.]]></code>
- then that particular URL is probably pointing to a valid
- server-side Cactus install.
- </p>
+ web-browser. Actually the Cactus redirectors provide a URL just for
+ that :
<code>http://localhost/webapp/ServletRedirector?Cactus_Service=RUN_TEST</code>
+ (this also works for the other redirectors).
+ </p>
+ <note>
+ If you call <code>http://localhost/webapp/ServletRedirector</code>
+ directly, you'll get a 500 error and get a stack trace (in the log or
+ along with your error page) that says <code><![CDATA[Missing service
+ name parameter [] in HTTP request.]]></code>. This is because the
+ Cactus redirector expects HTTP parameter from the Cactus client side.
+ </note>
<p>
Another likely error is that your server-side classpath
does not contain a copy of the cactus.jar. (Cactus is
effectively not present on the server.) According to
e-mails on the Cactus user list, the
- StreamCorruptedException could also result when you are
+ <code>StreamCorruptedException</code> could also result when you are
using the wrong version of the servlet.jar in some area
(any version prior to 2.2, or using servlet.jar 2.2 with a
Cactus-2.3 installation).
- </p>
- <p>
- Cactus 1.3 should trap or avoid this exception and provide
- a clearer message about the likely causes.
</p>
</s2>
1.2 +27 -173 jakarta-cactus/documentation/docs/xdocs/getting_started.xml
Index: getting_started.xml
===================================================================
RCS file: /home/cvs/jakarta-cactus/documentation/docs/xdocs/getting_started.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- getting_started.xml 10 Mar 2002 14:10:25 -0000 1.1
+++ getting_started.xml 19 Apr 2002 21:36:01 -0000 1.2
@@ -80,7 +80,7 @@
<p>
At this point, you should have
<link href="downloads.html">downloaded</link> a Cactus distribution
- (for the Servlet API you intend to use) and unzipped it in a
+ (for the J2EE API you intend to use) and unzipped it in a
<code>[cactus root]</code> directory.
</p>
<p>
@@ -111,8 +111,14 @@
thus needs the JUnit jar.
</li>
<li>
- <strong><code>log4j-core.jar</code></strong> : Cactus uses Log4j
- for performing all internal logging. This jar is optional and if
+ <strong><code>aspectjrt.jar</code></strong> : Cactus uses
+ <link href="http://www.aspectj.org";>AspectJ</link> for performing
+ several tasks (logging entries and exit of methods, checking
+ configuration, etc).
+ </li>
+ <li>
+ <strong><code>log4j.jar</code>(optional)</strong> : Cactus uses
+ Log4j for performing all internal logging. This jar is optional and if
you don't put in the classpaths, no logs will be generated.
</li>
</ul>
@@ -123,179 +129,27 @@
</s1>
- <s1 title="The Classpath">
-
- <p>
- 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 <code>testXXX()</code> methods will be executed. See
- <link href="how_it_works.html">How it works</link> to understand the
- mechanism.
- </p>
- <note>
- <strong>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 !</strong>
- </note>
-
- <figure src="images/classpath.jpg" alt="Classpaths"/>
-
- <s2 title="Client side classpath">
-
- <p>
- The Cactus tests are started by running a JUnit Test Runner (For
- explanations on how JUnit works see the
- <link href="http://junit.sourceforge.net";>JUnit web site</link>).
- As pictured in figure 1, you need to have the following jars and classes
- in your client side classpath :
- </p>
- <ul>
- <li>
- <strong><code>junit.jar</code></strong> : obviously this is needed
- for the JUnit Test Runner and because the Cactus
- <code>XXXTestCase</code> classes extend the JUnit
- <code>org.junit.framework.TestCase</code> class.
- </li>
- <li>
- <strong><code>cactus.jar</code></strong> : well, this is the
- Cactus jar containing all Cactus classes,
- </li>
- <li>
- <strong>your test classes</strong> : these are
- your test classes that extend the Cactus <code>XXXTestCase</code>
- classes,
- </li>
- <li>
- <strong><code>servlet.jar</code></strong> : these are the
- Servlet API interfaces (for the Servlet API you are using). This
- is needed because your test case extend one or several of
- <code>XXXTestCase</code> which use class variables that are
- servlet objects (<code>HttpSevletRequest</code>,
- <code>PageContext</code>, ...). You can get this jar either from
- your servlet engine or from the
- <link href="http://java.sun.com/products/servlet/download.html";>
- Servlet download page</link> of the Sun web site. It is also
- included in the <code>j2ee.jar</code>, available either from your
- servlet engine or from the
- <link href="http://java.sun.com/j2ee/download.html";>J2EE download
- page</link> of the Sun web site (but it contains a lot of other
- API that you probably don't need).
- </li>
- <li>
- <strong><code>httpclient.jar</code></strong> : needed for
- Cactus Cookie handling.
- </li>
- <li>
- <strong><code>log4j.jar</code> (optional)</strong> : only needed
- when you want Cactus to output debugging information on the client
- side.
- </li>
- <li>
- <strong><code>httpunit.jar</code></strong>, <strong>
- <code>Tidy.jar</code></strong> and <strong>
- <code>xerces.jar</code> (optional)</strong> : only needed if you
- wish to use
- <link href="http://httpunit.sourceforge.net";>HttpUnit</link>
- in your <code>endXXX()</code> methods (see the
- <link href="howto_httpunit.html">HttpUnit Howto</link> tutorial).
- The 3 jars mentioned above are part of the HttpUnit distribution.
- </li>
- </ul>
-
- <note>
- If you have the habit of declaring class variables for the classes
- to test (as opposed to declaring them within the
- <code>testXXX()</code> method), you'll also need to put your classes
- under test in the client side classpath.
- </note>
-
- <p>
- In addition to the above mentionned jars and classes, you will also
- need to put the <strong><code>cactus.properties</code></strong>
- configuration file in your classpath (because it is a java properties
- file). This file is described in the
- <link href="howto_config.html">Config Howto</link> tutorial).
- </p>
-
- <note>
- In theory you would also need to put the
- <code>log_client.properties</code> properties file in your classpath.
- However a default one is provided in <code>cactus.jar</code>
- (and thus is on the classpath as <code>cactus.jar</code> is
- itself in the classpath !).
- </note>
-
- </s2>
-
- <s2 title="Server side classpath">
-
- <p>
- 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 :
- </p>
-
- <ul>
- <li>
- <strong><code>WEB-INF/lib/cactus.jar</code></strong> : the
- Cactus main jar,
- </li>
- <li>
- <strong><code>WEB-INF/lib/junit.jar</code></strong> : this is
- needed because the Cactus <code>XXXTestCase</code> extends
- the JUnit <code>org.junit.framework.TestCase</code> class.
- </li>
- <li>
- <strong><code>WEB-INF/classes/<your test classes></code>
- </strong> : obviously as their <code>testXXX()</code> methods will
- get executed in the container.
- </li>
- <li>
- <strong><code>WEB-INF/classes/<your classes under test></code>
- </strong> : will be called by your test classes.
- </li>
- <li>
- <strong><code>WEB-INF/lib/log4j.jar</code> (optional)</strong> :
- only needed when you want Cactus to output debugging information
- on the server side.
- </li>
- </ul>
-
- <note>
- If you have several webapps that use cactus you may be tempted to
- place the <code>cactus.jar</code> 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 <code>com.foo.EvilClass</code>
- in webapp A to conflict with <code>com.foo.EvilClass</code> in webapp
- B.
- </note>
-
- <note>
- In theory you would also need to put the
- <code>log_server.properties</code> configuration file in your
- classpath. However a default one is provided in
- <code>cactus.jar</code>
- (and thus is on the classpath as <code>cactus.jar</code> is
- itself in the classpath !).
- </note>
-
- </s2>
-
- </s1>
-
<s1 title="What's next ?">
<p>
- You should now read the <link href="howto_config.html">Configuration
- Howto</link> tutorial. Then, read the
- <link href="howto_testcase.html">TestCase Howto</link>, which
- explains how to write a Cactus Test Case.
- Then, you could try to install the Cactus
- Sample by following the <link href="howto_sample.html">Samples
- Howto</link> tutorial.
+ At this point you should understand what Cactus is and how it works.
+ </p>
+ <p>
+ The next step is to understand how to set up Cactus in your environment.
+ For this you'll need to understand <link href="howto_classpath.html">How
+ to setup Cactus classpaths</link> and <link href="howto_config.html">How
+ to configure Cactus</link>.
+ </p>
+ <p>
+ Then, you should read the <link href="howto_testcase.html">TestCase
+ Howto</link> to understand how to write Cactus Test Cases.
+ </p>
+ <p>
+ The last step is probably to put in practice what you've learned so far
+ by <link href="howto_sample.html">running the Cactus Samples</link>.
+ </p>
+ <p>
+ Enjoy !
</p>
</s1>
1.3 +7 -5 jakarta-cactus/documentation/docs/xdocs/how_it_works.xml
Index: how_it_works.xml
===================================================================
RCS file: /home/cvs/jakarta-cactus/documentation/docs/xdocs/how_it_works.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- how_it_works.xml 14 Apr 2002 21:51:47 -0000 1.2
+++ how_it_works.xml 19 Apr 2002 21:36:01 -0000 1.3
@@ -123,11 +123,13 @@
</li>
<li>
If no exception occurred, the <code>YYYTestCase.runTest()</code>
- method looks for an <code>endXXX(HttpURLConnection)</code> method
- and executes it if found. At this stage, you have the opportunity
- to check returned HTTP headers, Cookies and the servlet output
- stream in the <code>endXXX()</code> method, again using JUnit asserts
- and helper utility classes provided by Cactus.
+ method looks for an <code>endXXX(org.apache.cactus.WebResponse)</code>
+ or <code>endXXX(com.meterware.httpunit.WebResponse)</code> (this
+ signature is used for <link href="howto_httpunit.html">HttpUnit
+ integration</link>) method and executes it if found. At this stage,
+ you have the opportunity to check returned HTTP headers, Cookies and
+ the servlet output stream in the <code>endXXX()</code> method, again
+ using JUnit asserts and helper utility classes provided by Cactus.
</li>
</ol>
1.2 +100 -105 jakarta-cactus/documentation/docs/xdocs/howto_ant_cactus.xml
Index: howto_ant_cactus.xml
===================================================================
RCS file: /home/cvs/jakarta-cactus/documentation/docs/xdocs/howto_ant_cactus.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- howto_ant_cactus.xml 10 Mar 2002 14:10:25 -0000 1.1
+++ howto_ant_cactus.xml 19 Apr 2002 21:36:01 -0000 1.2
@@ -117,18 +117,22 @@
<source><![CDATA[
<!--
- ======================================================================
+ ========================================================================
Run Tomcat 4.0 tests
- ======================================================================
+ ========================================================================
-->
-<target name="tests_tomcat"
- depends="init,deploy_config,create_test_war" if="tomcat.home">
+<target name="test.tomcat.40" depends="prepare.test.tomcat.40"
+ if="tomcat.home.40" description="Run tests on Tomcat 4.0">
- <!-- We suppose our webapp is named "test" -->
- <runservertests testURL="http://localhost:8080/test";
- startTarget="start_tomcat"
- stopTarget="stop_tomcat"
- testTarget="run_tests"/>
+ <!-- Start the servlet engine, wait for it to be started, run the
+ unit tests, stop the servlet engine, wait for it to be stopped.
+ The servlet engine is stopped if the tests fail for any reason -->
+
+ <runservertests
+
testURL="http://localhost:${test.port}/test/ServletRedirector?Cactus_Service=RUN_TEST";
+ startTarget="start.tomcat.40"
+ stopTarget="stop.tomcat.40"
+ testTarget="test"/>
</target>
]]></source>
@@ -136,7 +140,7 @@
<p>
Before you can execute the <code>runservertests</code> task, you
need to define it for Ant as it is not a standard Ant task. A
- good place to do this is in the <code>init</code> target.
+ good place to do this is in an <code>init</code> target.
</p>
<p>
Example :
@@ -153,7 +157,6 @@
<taskdef name="runservertests"
classname="org.apache.cactus.ant.RunServerTestsTask">
<classpath>
<pathelement location="${cactus.ant.jar}"/>
- <pathelement path="${java.class.path}"/>
</classpath>
</taskdef>
[...]
@@ -168,17 +171,12 @@
</p>
<note>
- The <code>deploy_config</code> target is described in
+ The <code>prepare.test.tomcat.40</code> target is described in
Step 0 below.
</note>
<note>
- The <code>create_test_war</code> target is described in
- Step 1 below.
- </note>
-
- <note>
- The <code>tomcat.home</code> is simply an Ant property that
+ The <code>tomcat.home.40</code> is simply an Ant property that
points to the directory where Tomcat 4.0 has been installed. If this
property is not defined we don't run the tests.
</note>
@@ -268,36 +266,48 @@
<source><![CDATA[
<!--
- ======================================================================
- Deploy container configuration files
- ======================================================================
+ ========================================================================
+ Prepare directories and variables for running the tests
+ ========================================================================
-->
-<target name="deploy_config" if="tomcat.home">
+<target name="prepare.test.tomcat.40"
+ depends="check.test.tomcat.40,testwar" if="tomcat.home.40">
+
+ <echo message="tomcat.home.40 = ${tomcat.home.40}"/>
- <!-- This filter is needed to set the absolute path to the webapps
- directory in the Tomcat server.xml configuration file -->
- <filter token="out.server.webapp.dir"
value="${basedir}/${out.server.dir}/webapps"/>
-
- <!-- Delete the deployed file to ensure that they are reread at every
- deployment by Tomcat -->
- <delete dir="${out.server.dir}/conf"/>
- <delete dir="${out.server.dir}/webapps"/>
+ <property name="target.tomcat40.dir"
+ value="${target.test.dir}/tomcat40"/>
+ <property name="conf.tomcat40.dir" value="${conf.test.dir}/tomcat40"/>
<!-- Create work and conf directories and copy configuration files -->
- <mkdir dir="${out.server.dir}/conf"/>
- <mkdir dir="${out.server.dir}/work"/>
- <mkdir dir="${out.server.dir}/webapps"/>
-
- <!-- Copy the Tomcat configuration files to our conf directory -->
- <copy file="${conf.server.dir}/web.xml" todir="${out.server.dir}/conf"/>
- <copy file="${conf.server.dir}/server.xml"
- todir="${out.server.dir}/conf" filtering="on"/>
+ <mkdir dir="${target.tomcat40.dir}/conf"/>
+ <mkdir dir="${target.tomcat40.dir}/work"/>
+ <mkdir dir="${target.tomcat40.dir}/webapps"/>
+
+ <!-- Delete some config file so that they will be copied every time -->
+ <delete file="${target.tomcat40.dir}/conf/server.xml"/>
+
+ <!-- Remove the auto deployed webapp so that it is redeployed every
+ time -->
+ <delete dir="${target.tomcat40.dir}/webapps/test"/>
+
+ <copy todir="${target.tomcat40.dir}/conf" filtering="on">
+ <fileset dir="${conf.tomcat40.dir}"/>
+ </copy>
+
+ <!-- Copy the Tomcat web.xml -->
+ <copy file="${tomcat.home.40}/conf/web.xml"
+ todir="${target.tomcat40.dir}/conf"/>
+
+ <!-- Copy the war file -->
+ <copy file="${target.test.dir}/test.war"
+ tofile="${target.tomcat40.dir}/webapps/test.war"/>
</target>
]]></source>
<note>
- The <code>${out.server.dir}</code> Ant property needs to be
+ The <code>${target.test.dir}</code> Ant property needs to be
defined prior to calling this target and needs to be set to the
location where the tests will be deployed. It should be set to any
subdirectory of your output directory. This property will also be
@@ -305,7 +315,7 @@
</note>
<note>
- The <code>${conf.server.dir}</code> Ant property also needs to be
+ The <code>${conf.test.dir}</code> Ant property also needs to be
defined prior to calling this target and represent the location of
server configuration files (in the current example of Tomcat 4.0,
these are the global <code>web.xml</code> and
@@ -328,18 +338,26 @@
<source><![CDATA[
<!--
- ======================================================================
- Create a test war file that includes the sample application unit
- tests and deploy it to the webapps directory
- ======================================================================
+ ========================================================================
+ Create a Cactus test war file for the sample application.
+ ========================================================================
-->
-<target name="create_test_war" depends="compile">
+<target name="testwar" depends="compile">
- <war warfile="${out.server.dir}/webapps/test.war"
+ <!-- Create the war file -->
+ <war warfile="${target.test.dir}/test.war"
webxml="${conf.test.dir}/web.xml">
- <classes dir="${out.classes.dir}"/>
- <lib dir="${lib.dir}"/>
+ <classes dir="${target.classes.sample.dir}"/>
+ <classes dir="${target.classes.unit.dir}"/>
+
+ <!-- log_server.properties need to be in the server classpath -->
+ <classes dir="${conf.test.dir}">
+ <include name="log_server.properties"/>
+ <include name="cactus.properties"/>
+ </classes>
+
+ <lib dir="${target.lib.dir}"/>
<fileset dir="${web.dir}"/>
</war>
@@ -352,15 +370,15 @@
<ul>
<li>
<code>${conf.test.dir}</code> : directory containing configuration
- files for the test. Namely <code>web.xml</code>,
+ files for the test,
</li>
<li>
- <code>${out.classes.dir}</code> : directory where the java classes
- have been compiled. These are the classes under test + the test
- classes,
+ <code>${target.classes.*.dir}</code> : directory where the java
+ classes have been compiled. These are the classes under test + the
+ test classes,
</li>
<li>
- <code>${lib.dir}</code> : directory containing the needed jars
+ <code>${target.lib.dir}</code> : directory containing the needed jars
(<code>junit.jar</code>, <code>cactus.jar</code>, ...).
</li>
<li>
@@ -371,7 +389,7 @@
<note>
The <code>compile</code> target is used to compile all java classes
- into the <code>${out.classes.dir}</code> directory.
+ into the <code>${target.classes.*.dir}</code> directory.
</note>
</s1>
@@ -384,27 +402,21 @@
<source><![CDATA[
<!--
- ======================================================================
+ ========================================================================
Start Tomcat 4.0
- ======================================================================
+ ========================================================================
-->
-<target name="start_tomcat">
+<target name="start.tomcat.40">
<java classname="org.apache.catalina.startup.Bootstrap" fork="yes">
-
- <jvmarg value="-Dcatalina.home=${tomcat.home}"/>
-
- <arg value="-config"/>
- <arg value="${basedir}/${out.server.dir}/conf/server.xml"/>
+ <jvmarg value="-Dcatalina.home=${tomcat.home.40}"/>
+ <jvmarg value="-Dcatalina.base=${target.tomcat40.dir}"/>
<arg value="start"/>
-
<classpath>
- <fileset dir="${tomcat.home}">
+ <fileset dir="${tomcat.home.40}">
<include name="bin/bootstrap.jar"/>
- <include name="server/catalina.jar"/>
</fileset>
</classpath>
-
</java>
</target>
@@ -421,41 +433,27 @@
<source><![CDATA[
<!--
- ======================================================================
- Run the Cactus test cases by starting a JUnit test runner.
- ======================================================================
+ ========================================================================
+ Run the client JUnit test cases.
+ ========================================================================
-->
-<target name="run_tests">
+<target name="test">
- <junit printsummary="yes" haltonfailure="yes" haltonerror="yes" fork="yes">
+ <junit printsummary="yes" haltonfailure="yes" haltonerror="yes"
+ fork="yes">
<classpath>
- <!-- The Servlet API jar -->
- <pathelement location="${servlet.jar}"/>
-
- <!-- (optional) Will be ignore if log4j.jar is not defined -->
- <pathelement location="${log4j.jar}"/>
-
- <pathelement location="${cactus.jar}"/>
- <pathelement location="${junit.jar}"/>
-
- <!-- for Cactus 1.2 and above only -->
- <pathelement location="${httpclient.jar}"/>
-
- <!-- The test classes and classes to test -->
- <pathelement location="${out.classes.dir}"/>
+ <!-- Cactus.propertie and log_client.properties need to be in
+ the classpath -->
+ <pathelement location="${target.conf.dir}"/>
+ <pathelement location="${target.classes.sample.dir}"/>
+ <pathelement location="${target.classes.unit.dir}"/>
+ <path refid="project.class.path"/>
</classpath>
<formatter type="plain" usefile="false"/>
-
- <test name="your.package.YourTestCaseClass1"/>
- [...]
- <test name="your.package.YourTestCaseClassN"/>
-
- <!-- Or you can gather all the tests in a TestAll class that start
- them all -->
-
- <!-- Or you can use the junit task batchtest nested element -->
+ <test name="org.apache.cactus.unit.TestAll"/>
+ <test name="org.apache.cactus.sample.TestAll"/>
</junit>
@@ -464,8 +462,8 @@
<note>
The list of jars to include in your classpath is explained and
- detailed in the <link href="getting_started.html">Getting
- Started</link> guide.
+ detailed in the <link href="howot_classpath.html">Classpath
+ Howto</link> guide.
</note>
</s1>
@@ -478,24 +476,21 @@
<source><![CDATA[
<!--
- ======================================================================
+ ========================================================================
Stop Tomcat 4.0
- ======================================================================
+ ========================================================================
-->
-<target name="stop_tomcat">
+<target name="stop.tomcat.40">
<java classname="org.apache.catalina.startup.Bootstrap" fork="yes">
-
- <jvmarg value="-Dcatalina.home=${tomcat.home}"/>
+ <jvmarg value="-Dcatalina.home=${tomcat.home.40}"/>
+ <jvmarg value="-Dcatalina.base=${target.tomcat40.dir}"/>
<arg value="stop"/>
-
<classpath>
- <fileset dir="${tomcat.home}">
+ <fileset dir="${tomcat.home.40}">
<include name="bin/bootstrap.jar"/>
- <include name="server/catalina.jar"/>
</fileset>
</classpath>
-
</java>
</target>
1.2 +14 -9 jakarta-cactus/documentation/docs/xdocs/howto_ant_install.xml
Index: howto_ant_install.xml
===================================================================
RCS file: /home/cvs/jakarta-cactus/documentation/docs/xdocs/howto_ant_install.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- howto_ant_install.xml 10 Mar 2002 14:10:25 -0000 1.1
+++ howto_ant_install.xml 19 Apr 2002 21:36:01 -0000 1.2
@@ -41,7 +41,7 @@
version required by the Cactus build is
the Stylebook 1.0b3 for Xalan2 (named
<code>stylebook-1.0-b3_xalan-2.jar</code>) which needs the Xalan 2.0
- jar and the Xerces 1.3 jar. <em>The stylebook task is not used by
+ jar and the Xerces jar. <em>The stylebook task is not used by
the Cactus Sample application build process, so it is only needed
if you're building from the Cactus sources</em>. This task is
normally found in the <code>optional.jar</code> Ant jar.
@@ -58,6 +58,12 @@
found in the <code>lib/</code> directory where you unpacked the
Cactus distribution).
</li>
+ <li>
+ The <strong><code>checkstyle</code></strong> task : it is used only
+ to buidl Cactus from the sources (i.e. not needed for building the
+ Cactus sample application). The version of
+ <link href="http://checkstyle.sf.net";>Checkstyle</link> used is 2.2+.
+ </li>
</ul>
<p>
@@ -79,8 +85,8 @@
Download Jakarta Ant
(<code>jakarta-ant-<version>-bin.zip</code>) from
<link href="http://jakarta.apache.org/ant/index.html";>here</link>. I
- recommend version 1.3 or above. Alternatively you can download the
- prepackaged Ant version, as mentionned above.
+ recommend version 1.4.1 or above. Alternatively you can download the
+ prepackaged Ant version, as mentioned above.
</li>
<li>
Unzip it in a directory. Let's call this directory
@@ -107,12 +113,11 @@
If you haven't downloaded the prepackaged Ant zip, you'll need to
download the Stylebook 1.0b3 for Xalan 2 jar, the latest
<link href="http://xml.apache.org/xalan-j/";>Xalan</link>, the latest
- <link href="http://xml.apache.org/xerces-j";>Xerces</link> and the
- latest <link href="http://junit.org";>JUnit</link> jars. You'll also
- need to ensure that you use a JAXP 1.1 parser (Ant 1.3 comes with
- a JAXP 1.0 parser only, called <code>parser.jar</code>. Ant 1.4
- already bundles a JAXP 1.1 parser, called <code>crimson.jar</code>).
- You can download one (crimson) from
+ <link href="http://xml.apache.org/xerces-j";>Xerces</link>, the
+ latest <link href="http://junit.org";>JUnit</link> and the latest
+ <link href="http://checkstyle.sf.net";>Checkstyle</link> jars. You'll
+ also need to ensure that you use a JAXP 1.1 parser. You can download
+ one (crimson) from
<link href="http://java.sun.com/xml/download.html";>here</link>. Put
all these jars in <code>%ANT_HOME%\lib</code>.
</li>
1.2 +9 -0 jakarta-cactus/documentation/docs/xdocs/howto_ant_primer.xml
Index: howto_ant_primer.xml
===================================================================
RCS file: /home/cvs/jakarta-cactus/documentation/docs/xdocs/howto_ant_primer.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- howto_ant_primer.xml 10 Mar 2002 14:10:25 -0000 1.1
+++ howto_ant_primer.xml 19 Apr 2002 21:36:01 -0000 1.2
@@ -16,6 +16,15 @@
<s1 title="Continuous integration">
+ <note>
+ <strong>This tutorial was written when I wrote Cactus 1.2. Since then
+ I have improved my command of Ant. However this tutorial has not yet
+ been updated. I believe it still provides some very good
+ methodology on how to use Ant, although not the latest. If you wish to
+ keep track of the latest change, have a look at the Cactus build files,
+ found in the source distribution.</strong>
+ </note>
+
<p>
A strong principle of eXtreme Programming (XP) is the continuous
integration aspect (see the
1.2 +324 -107 jakarta-cactus/documentation/docs/xdocs/howto_config.xml
Index: howto_config.xml
===================================================================
RCS file: /home/cvs/jakarta-cactus/documentation/docs/xdocs/howto_config.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- howto_config.xml 10 Mar 2002 14:10:25 -0000 1.1
+++ howto_config.xml 19 Apr 2002 21:36:01 -0000 1.2
@@ -42,22 +42,9 @@
<s3 title="cactus.properties">
- <note>
- Do not forget to put this file on the <strong>client
- classpath</strong> (meaning you need
- to put the directory where this file is located in the client
- side classpath, not the file itself !). See the
- <link href="getting_started.html">Getting Started</link> guide to
- understand how to set up the classpath.
- </note>
-
<p>
The <code>cactus.properties</code> file contains several
- configuration properties. At the current time it is only used to
- tell the client side part of Cactus what is the URL to connect to
- the different Cactus Redirectors set up on the server side (see
- <link href="how_it_works.html">How it works</link> if you don't
- know what a Cactus Redirector is).
+ configuration properties for Cactus.
</p>
<p>
Here are the properties that you can set in
@@ -70,7 +57,38 @@
<strong>Property Name</strong>
</td>
<td>
- <code>cactus.servletRedirectorURL</code>
+ <code>cactus.contextURL</code>
+ </td>
+ </tr>
+ <tr>
+ <td>
+ <strong>Description</strong>
+ </td>
+ <td>
+ Webapp Context under which the application to test runs.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ <strong>Example</strong>
+ </td>
+ <td>
+ <code>cactus.contextURL = http://localhost:8080/test</code>
+ </td>
+ </tr>
+ </table>
+
+ <p>
+ <br/>
+ </p>
+
+ <table>
+ <tr>
+ <td>
+ <strong>Property Name</strong>
+ </td>
+ <td>
+ <code>cactus.servletRedirectorName</code>
</td>
</tr>
<tr>
@@ -78,8 +96,9 @@
<strong>Description</strong>
</td>
<td>
- URL to which the Servlet Redirector is mapped to. This is
- needed only if your test classes are extending
+ Name of the Cactus Servlet Redirector as it is mapped on the
+ server side in <code>web.xml</code> (see below). This property
+ is needed only if your test classes are extending
<code>ServletTestCase</code> (see the
<link href="howto_testcase.html">TestCase Howto</link>
tutorial).
@@ -90,7 +109,7 @@
<strong>Example</strong>
</td>
<td>
- <code>http://localhost:8080/test/ServletRedirector/</code>
+ <code>cactus.servletRedirectorName = ServletRedirector</code>
</td>
</tr>
</table>
@@ -105,7 +124,7 @@
<strong>Property Name</strong>
</td>
<td>
- <code>cactus.jspRedirectorURL</code>
+ <code>cactus.jspRedirectorName</code>
</td>
</tr>
<tr>
@@ -113,8 +132,9 @@
<strong>Description</strong>
</td>
<td>
- URL to which the JSP Redirector is mapped to. This is
- needed only if your test classes are extending
+ Name of the Cactus JSP Redirector as it is mapped on the
+ server side in <code>web.xml</code> (see below). This property
+ is needed only if your test classes are extending
<code>JspTestCase</code> (see the
<link href="howto_testcase.html">TestCase Howto</link>
tutorial).
@@ -125,7 +145,7 @@
<strong>Example</strong>
</td>
<td>
- <code>http://localhost:8080/test/JspRedirector/</code>
+ <code>cactus.jspRedirectorName = JspRedirector</code>
</td>
</tr>
</table>
@@ -140,7 +160,7 @@
<strong>Property Name</strong>
</td>
<td>
- <code>cactus.filterRedirectorURL</code>
+ <code>cactus.filterRedirectorName</code> (For J2EE API 1.3 only)
</td>
</tr>
<tr>
@@ -148,8 +168,9 @@
<strong>Description</strong>
</td>
<td>
- URL to which the Filter Redirector is mapped to. This is
- needed only if your test classes are extending
+ Name of the Cactus Filter Redirector as it is mapped on the
+ server side in <code>web.xml</code> (see below). This property
+ is needed only if your test classes are extending
<code>FilterTestCase</code> (see the
<link href="howto_testcase.html">TestCase Howto</link>
tutorial).
@@ -160,7 +181,41 @@
<strong>Example</strong>
</td>
<td>
- <code>http://localhost:8080/test/FilterRedirector/</code>
+ <code>cactus.filterRedirectorName = FilterRedirector</code>
+ </td>
+ </tr>
+ </table>
+
+ <p>
+ <br/>
+ </p>
+
+ <table>
+ <tr>
+ <td>
+ <strong>Property Name</strong>
+ </td>
+ <td>
+ <code>cactus.enableLogging</code>
+ </td>
+ </tr>
+ <tr>
+ <td>
+ <strong>Description</strong>
+ </td>
+ <td>
+ If set to "true" Cactus internal logging is enabled. Note that
+ you will also need <code>log4j.jar</code> in your classpath to
+ activate logging. If not specified or set to a value different
+ than "true", Cactus logging is disabled.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ <strong>Example</strong>
+ </td>
+ <td>
+ <code>cactus.enableLogging = true</code>
</td>
</tr>
</table>
@@ -176,27 +231,48 @@
# CLASSPATH (Meaning the directory containgin this file should be in the client
# side CLASSPATH, not the file itself of course ... :) )
-# Defines the URLs that will be used by Cactus to call it's redirectors
-# (Servlet and JSP). You need to specify in these URLs the webapp context
-# that you use for your application. In the example below, the context is
-# "test".
-
-cactus.servletRedirectorURL = http://localhost:8080/test/ServletRedirector/
-cactus.jspRedirectorURL = http://localhost:8080/test/JspRedirector/
-cactus.filterRedirectorURL = http://localhost:8080/test/FilterRedirector/
+# Defines the URLs that will be used by Cactus to call it's redirectors.
+# You need to specify in these URLs the webapp context that you use for your
+# application. In the example below, the context is "test".
+
+# Web app Context under which our application to test runs
+cactus.contextURL = http://localhost:@test.port@/test
+
+# Default Servlet Redirector Name. Used by ServletTestCase test cases.
+cactus.servletRedirectorName = ServletRedirector
+
+# Default JSP Redirector Name. Used by JspTestCase test cases.
+cactus.jspRedirectorName = JspRedirector
+
+# Default Filter Redirector Name. Used by FilterTestCase test cases.
+cactus.filterRedirectorName = FilterRedirector
+
+# Enable Cactus internal logging
+#cactus.enableLogging = true
]]></source>
- <note>
- Notice the trailing slash ("/") to Redirector URLs. This is
- because Cactus uses the JDK <code>HttpURLConnection</code> class
- to connect to these URLs and if your code on the server side
- returns an HTTP status code greater than 400,
- <code>HttpURLConnection</code> will return an exception. It does
- not if the URL ends with a forward slash ("/") !
- </note>
+ <anchor id="client_location_cactus_properties"/>
+ <p>
+ There are 2 ways to tell Cactus where <code>cactus.properties</code>
+ is located.
+ </p>
+ <ul>
+ <li>
+ The preferred mechanism is to put it in the client side
+ classpath (i.e. have a CLASSPATH entry that points to the
+ directory where it is located).
+ </li>
+ <li>
+ The other option is to pass a command line parameter when
+ starting your JVM. See the
+ <jump anchor="client_command_line">Command line section</jump>
+ below.
+ </li>
+ </ul>
</s3>
+ <anchor id="client_log_client_properties"/>
<s3 title="log_client.properties">
<p>
@@ -207,9 +283,22 @@
</p>
<p>
If the Log4j jar is not present on the client side classpath,
- Cactus will not log anything. To enable logging, just put the
- Log4j jar in the client side classpath.
- </p>
+ Cactus will not log anything. In addition you need to
+ explicitely tell Cactus to perform logging (if that's what you
+ want). This can be achieved in 2 ways :
+ </p>
+ <ul>
+ <li>
+ By having a <code>cactus.enableLogging = true</code> property
+ in your <code>cactus.properties</code> file (as described
+ above),
+ </li>
+ <li>
+ By passing a property on the Java command line when starting
+ the JVM. See the
+ <jump anchor="client_command_line">Command line section</jump>.
+ </li>
+ </ul>
<p>
The default <code>log_client.properties</code> is :
</p>
@@ -222,17 +311,21 @@
log4j.appender.cactus.File = cactus_client.log
log4j.appender.cactus.Append = false
log4j.appender.cactus.layout = org.apache.log4j.PatternLayout
-log4j.appender.cactus.layout.ConversionPattern = %r [%t] %-5p %c{2} %x - %m %n
+log4j.appender.cactus.layout.ConversionPattern = %d{ABSOLUTE} [%t] %-5p %-30.30c{2}
%x - %m %n
+
+# Any application log which uses Log4J will be logged to the Cactus log file
+log4j.rootCategory=DEBUG, cactus
-log4j.category.org.apache.cactus = DEBUG, cactus
+# By default we don't log at the DEBUG level for Cactus log, in order not to
generate too
+# many logs. However, should a problem arise and logs need to be sent to the Cactus
dev team,
+# then we will ask you to change this to DEBUG.
+log4j.category.org.apache.cactus = WARN, cactus
+log4j.additivity.org.apache.cactus=false
]]></source>
<p>
If you want to understand how to configure Log4j, go to the
<link href="http://jakarta.apache.org/log4j";>Log4j web site</link>.
- Basically, this configuration tells Log4j to log all debug level
- messages to a <code>cactus_client.log</code> file (which will be
- located in the directory where you started the client JVM).
</p>
<p>
@@ -245,11 +338,147 @@
</s3>
+ <anchor id="client_command_line"/>
+ <s3 title="Command line parameters">
+
+ <note>
+ Command line parameters are purely optional and should only be used
+ for very specific cases where the preferred method cannot be used
+ (the preffered method is through <code>cactus.properties</code>).
+ </note>
+
+ <p>
+ The following command line properties can be passed on the java
+ command line :
+ </p>
+
+ <table>
+ <tr>
+ <td>
+ <strong>Property Name</strong>
+ </td>
+ <td>
+ <code>cactus.enableLogging</code>
+ </td>
+ </tr>
+ <tr>
+ <td>
+ <strong>Description</strong>
+ </td>
+ <td>
+ If set to "true" Cactus internal logging is enabled. Note that
+ you will also need <code>log4j.jar</code> in your classpath to
+ activate logging. If not specified or set to a value different
+ than "true", Cactus logging is disabled.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ <strong>Example</strong>
+ </td>
+ <td>
+ <code>-Dcactus.enableLogging=true</code>
+ </td>
+ </tr>
+ </table>
+
+ <p>
+ <br/>
+ </p>
+
+ <table>
+ <tr>
+ <td>
+ <strong>Property Name</strong>
+ </td>
+ <td>
+ <code>cactus.config</code>
+ </td>
+ </tr>
+ <tr>
+ <td>
+ <strong>Description</strong>
+ </td>
+ <td>
+ Specify where to find the Cactus configuration file.
+ By default Cactus looks for a <code>cactus.properties</code>
+ file in the classpath. This property overrides this behaviour.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ <strong>Example</strong>
+ </td>
+ <td>
+ <code>-Dcactus.config=conf/mycactus.properties</code>
+ </td>
+ </tr>
+ </table>
+
+ </s3>
+
</s2>
<anchor id="serverside"/>
<s2 title="Server side configuration files">
+ <s3 title="cactus.properties">
+
+ <p>
+ First and foremost, this file is completely optional on the server
+ side (whereas it is mandatory on the client side). It is only
+ used to turn on Cactus internal logging on the server side.
+ </p>
+ <note>
+ Please note that Cactus logging on the server side can also be
+ turned on by using a java command line property (see the
+ <jump anchor="server_command_line">command line</jump> section
+ below).
+ </note>
+
+ <p>
+ Here are the properties that you can set in
+ <code>cactus.properties</code> :
+ </p>
+
+ <table>
+ <tr>
+ <td>
+ <strong>Property Name</strong>
+ </td>
+ <td>
+ <code>cactus.enableLogging</code>
+ </td>
+ </tr>
+ <tr>
+ <td>
+ <strong>Description</strong>
+ </td>
+ <td>
+ If set to "true" Cactus internal logging is enabled. Note that
+ you will also need <code>log4j.jar</code> in your classpath to
+ activate logging. If not specified or set to a value different
+ than "true", Cactus logging is disabled.
+ </td>
+ </tr>
+ <tr>
+ <td>
+ <strong>Example</strong>
+ </td>
+ <td>
+ <code>cactus.enableLogging = true</code>
+ </td>
+ </tr>
+ </table>
+
+ <p>
+ Location of <code>cactus.properties</code> works in the same
+ way as on the
+ <jump anchor="client_location_cactus_properties">client side</jump>.
+ </p>
+
+ </s3>
+
<s3 title="web.xml">
<p>
@@ -279,85 +508,59 @@
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE web-app
- PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.2//EN"
- "http://java.sun.com/j2ee/dtds/web-app_2.2.dtd";>
+ PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
+ "http://java.sun.com/j2ee/dtds/web-app_2_3.dtd";>
<web-app>
- <!-- Filter Redirector definition -->
<filter>
<filter-name>FilterRedirector</filter-name>
<filter-class>org.apache.cactus.server.FilterTestRedirector</filter-class>
</filter>
- <!-- Filter Redirector URL mapping -->
<filter-mapping>
<filter-name>FilterRedirector</filter-name>
- <url-pattern>/FilterRedirector/</url-pattern>
+ <url-pattern>/FilterRedirector</url-pattern>
</filter-mapping>
- <!-- Servlet Redirector configuration -->
<servlet>
<servlet-name>ServletRedirector</servlet-name>
<servlet-class>org.apache.cactus.server.ServletTestRedirector</servlet-class>
</servlet>
- <!-- JSP Redirector URL configuration -->
<servlet>
<servlet-name>JspRedirector</servlet-name>
- <jsp-file>/somewhere/jspRedirector.jsp</jsp-file>
+ <jsp-file>/jspRedirector.jsp</jsp-file>
</servlet>
- <!-- Servlet Redirector URL mapping -->
<servlet-mapping>
<servlet-name>ServletRedirector</servlet-name>
- <url-pattern>/ServletRedirector/</url-pattern>
+ <url-pattern>/ServletRedirector</url-pattern>
</servlet-mapping>
- <!-- JSP Redirector URL mapping -->
<servlet-mapping>
<servlet-name>JspRedirector</servlet-name>
- <url-pattern>/JspRedirector/</url-pattern>
+ <url-pattern>/JspRedirector</url-pattern>
</servlet-mapping>
</web-app>
]]></source>
<note>
- Notice the trailing slash ("/") to Redirector mappings. This is
- because Cactus uses the JDK <code>HttpURLConnection</code> class
- to connect to these URLs and if your code on the server side
- returns an HTTP status code greater than 400,
- <code>HttpURLConnection</code> will return an exception. It does
- not if the URL ends with a forward slash ("/") !
- </note>
-
- <note>
If you are using the JSP Redirector (i.e. you have test classes
that extend <code>JspTestCase</code>), you <strong>must</strong>
copy the <code>jspRedirector.jsp</code> file (found in the
- <code>sample/web/test</code> directory where you unpacked your
- Cactus distribution) anywhere in your webapp and you need to
- out it's relative path in the mapping defined above (here we
- have put it in a directory named <code>somewhere</code> right under
- the webapp root.
- </note>
- <note>
- We have used the <code><jsp-file></code> tag to define the
- mapping for the JSP Redirector page. However some servlet engine
- still don't support this tag (although it is in the Servlet 2.2
- specifications). If this is your case, simply do not define any
- mapping in <code>web.xml</code> for the JSP Redirector and use
- the following URL in your <code>cactus.properties</code> :
- <code>cactus.jspRedirectorURL =
- http://localhost:8080/test/somewhere/jspRedirector.jsp</code>
+ <code>sample/web</code> directory where you unpacked your
+ Cactus distribution) in a directory in your webapp and you need to
+ put it's relative path in the mapping defined above (here we
+ have put it in the webapp root.
</note>
<p>
If you want to provide some initialisation parameters that will
be available to the <code>config</code> implicit object available
- to you in your test case, simply use the standard <code>
- <init-param></code> tag.
+ in your test case, simply use the standard <code>
+ <init-param></code> tags.
</p>
<p>
For example, for the Servlet Redirector (same principle applies
@@ -385,20 +588,19 @@
your <code>web.xml</code>.
</note>
+ <p>
+ Lastly, if you need to unit test code that uses the Servlet
+ Security API, please check the
+ <link href="howto_security.html">Security Howto</link>.
+ </p>
+
</s3>
<s3 title="log_server.properties">
<p>
- A default <code>log_server.properties</code> is already provided
- in the <code>cactus.jar</code> jar. It is used for
- configuring Log4j, which is the logging framework used by Cactus
- to log debug information.
- </p>
- <p>
- If the Log4j jar is not present on the server side classpath,
- Cactus will not log anything. To enable logging, just put the
- Log4j jar in the server side classpath.
+ It works in the same way as for the
+ <jump anchor="client_log_client_properties">client side</jump>.
</p>
<p>
The default <code>log_server.properties</code> is :
@@ -412,18 +614,17 @@
log4j.appender.cactus.File = cactus_server.log
log4j.appender.cactus.Append = false
log4j.appender.cactus.layout = org.apache.log4j.PatternLayout
-log4j.appender.cactus.layout.ConversionPattern = %r [%t] %-5p %c{2} %x - %m %n
+log4j.appender.cactus.layout.ConversionPattern = %d{ABSOLUTE} [%t] %-5p %-30.30c{2}
%x - %m %n
-log4j.category.org.apache.cactus = DEBUG, cactus
-]]></source>
+# Any application log which uses Log4J will be logged to the Cactus log file
+log4j.rootCategory=DEBUG, cactus
- <p>
- If you want to understand how to configure Log4j, go to the
- <link href="http://jakarta.apache.org/log4j";>Log4j web site</link>.
- Basically, this configuration tells Log4j to log all debug level
- messages to a <code>cactus_server.log</code> file (which will be
- located in the current directory of your servlet engine).
- </p>
+# By default we don't log at the DEBUG level for Cactus log, in order not to
generate too
+# many logs. However, should a problem arise and logs need to be sent to the Cactus
dev team,
+# then we will ask you to change this to DEBUG.
+log4j.category.org.apache.cactus = WARN, cactus
+log4j.additivity.org.apache.cactus=false
+]]></source>
<p>
If you wish to define another file name and location or other
@@ -436,6 +637,22 @@
is located ... :) I don't know if this is part of the
specification). Alternatively, edit the file in
<code>cactus.jar</code> !
+ </p>
+
+ </s3>
+
+ <anchor id="server_command_line"/>
+ <s3 title="Command line parameters">
+
+ <p>
+ Command line parameters on the server side are exactly the same
+ as on the client side. in order to use them you'll have to modify
+ the startup script of your container and add your properties to it.
+ </p>
+ <p>
+ Again, please bear in mind that this is completely optional and
+ that the preferred method is by using
+ <code>cactus.properties</code>.
</p>
</s3>
1.2 +0 -6 jakarta-cactus/documentation/docs/xdocs/howto_httpunit.xml
Index: howto_httpunit.xml
===================================================================
RCS file: /home/cvs/jakarta-cactus/documentation/docs/xdocs/howto_httpunit.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- howto_httpunit.xml 10 Mar 2002 14:10:25 -0000 1.1
+++ howto_httpunit.xml 19 Apr 2002 21:36:01 -0000 1.2
@@ -65,12 +65,6 @@
}
]]></source>
- <note>
- The old <code>public void endXXX(HttpURLConnection theConnection)</code>
- signature is still supported in Cactus v1.2 but has been deprecated.
- We recommend to update to the new signature as soon as possible.
- </note>
-
<p>
The <code>WebResponse</code> object is passed by the Cactus framework
to your <code>endXXX()</code> method. What changes between the 2
1.2 +1 -4 jakarta-cactus/documentation/docs/xdocs/howto_ide.xml
Index: howto_ide.xml
===================================================================
RCS file: /home/cvs/jakarta-cactus/documentation/docs/xdocs/howto_ide.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- howto_ide.xml 10 Mar 2002 14:10:25 -0000 1.1
+++ howto_ide.xml 19 Apr 2002 21:36:01 -0000 1.2
@@ -30,9 +30,6 @@
Tutorial</link> (more focused on JBuilder 5),
</li>
<li>
- <link href="howto_ide_jbuilder.html">JBuilder 4 Integration</link>,
- </li>
- <li>
VisualAge for Java Integration :
<ul>
<li>
@@ -52,7 +49,7 @@
environment. You simply need to know how to start your servlet engine
from your IDE (possibly in debug mode if you wish to debug your
test case) and set up correctly the class path (see the
- <link href="getting_started.html">Getting Started</link> tutorial
+ <link href="howto_classpath.html">Classpath Howto</link> tutorial
for understanding the classpath). Look at the tutorials for other IDEs
and do the same for yours.
</p>
1.2 +35 -43 jakarta-cactus/documentation/docs/xdocs/howto_ide_jbuilder4.xml
Index: howto_ide_jbuilder4.xml
===================================================================
RCS file: /home/cvs/jakarta-cactus/documentation/docs/xdocs/howto_ide_jbuilder4.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- howto_ide_jbuilder4.xml 10 Mar 2002 14:10:25 -0000 1.1
+++ howto_ide_jbuilder4.xml 19 Apr 2002 21:36:01 -0000 1.2
@@ -16,20 +16,12 @@
<s1 title="Forewords and Requirements">
<p>
- First of all, JUnit and Cactus jar files are needed for this tutorial,
please
- download them :
+ First of all, you need to download the
+ <link href="downloads.html">Cactus distribution</link>
</p>
- <ul>
- <li>
- <link href="downloads.html">cactus</link>
- </li>
- <li>
- <link href="http://www.junit.org/";>junit</link>
- </li>
- </ul>
</s1>
- <s1 title="Step 1 : Create junit and cactus libraries">
+ <s1 title="Step 1 : Create JBuilder libraries">
<p>
Let's assume the following conventions :
@@ -40,28 +32,24 @@
<figure src="images/jb_libraries.gif" alt="jbuilder libraries" />
+ <s2 title="Create the JUnit library">
- <s2 title="Create the junit library">
<p>
- Create a new library named <code>junit</code>.
- Add the junit.jar file to this library in the class tab.
+ Create a JUnit library and include <code>junit.jar</code>.
</p>
</s2>
- <s2 title="Create the cactus library">
+ <s2 title="Create the Cactus library">
+
<p>
- Create a library named <code>cactus</code>.
- Add <code>cactus.jar</code> and optionnaly
- <code>log4j-core.jar</code>. Note that
- <code>log4j-core.jar</code> is useful only if you wish to get
- some Cactus runtime logs.
+ Create a Cactus library containing <code>cactus.jar</code> and
+ <code>aspectjrt.jar</code> (you can actually create a separate
+ library for AspectJ if you wish).
</p>
<note>
- You can also add the source file directories in the source tab :
- <code>{Cactus dir}/src/framework/servlet22</code> and
- <code>{Cactus dir}/src/framework/share</code>
+ You can also add the source file directories in the source tab.
This way, you will be able to debug inside cactus sources.
</note>
@@ -89,12 +77,6 @@
tutorial for more details on <code>cactus.properties</code>).
</p>
<p>
- Sample <code>cactus.properties</code> file :
- </p>
-<source><![CDATA[
- cactus.servletRedirectorURL = http://localhost:8080/cactus/ServletRedirector
-]]></source>
- <p>
Copy your <code>cactus.properties</code> file to a directory present
in your classpath. You can copy it to a directory and add this
directory in the class tab of the cactus library.
@@ -107,7 +89,9 @@
<s2 title="Create a cactus webapp">
<p>
- Create and edit the file <code>{Tomcat
dir}/webapps/cactus/WEB-INF/web.xml</code> :
+ Create and edit the file
+ <code>{Tomcat dir}/webapps/cactus/WEB-INF/web.xml</code>. Here is an
+ example for Servlet API 2.2 :
</p>
<source><![CDATA[
@@ -133,8 +117,10 @@
</s2>
<note>
- You can edit <code>{Tomcat dir}/conf/web.xml</code> instead if you prefer.
<br />
- You can also edit the web.xml file of the webapp where is located the
servlet(s) you want to test. <br />
+ You can edit <code>{Tomcat dir}/conf/web.xml</code> instead if you
+ prefer. <br/>
+ You can also edit the <code>web.xml</code> file of the webapp where is
+ located the servlet(s) you want to test. <br/>
Don't forget to modify <code>cactus.properties</code> file accordingly.
</note>
</s1>
@@ -142,12 +128,13 @@
<s1 title="Step 4 : Configure your project">
<ol>
<li>
- Put <code>-classic -Dtomcat.home="{Tomcat dir}"</code> as the VM
parameters for your project and
+ Put <code>-classic -Dtomcat.home="{Tomcat dir}"</code> as the VM
+ parameters for your project and
<code>org.apache.tomcat.startup.Tomcat</code> as the main class.
</li>
<li>
- Add the following libraries in the <code>Required Libraries</code> tab in
the
- project properties :
+ Add the following libraries in the <code>Required Libraries</code>
+ tab in the project properties :
<ul>
<li>tomcat</li>
<li>servlet</li>
@@ -167,24 +154,29 @@
Start Tomcat using the <code>Run/Run Project</code> menu.
</li>
<li>
- Run your unit tests : right Click on the file containing your test case
and click on <code>run</code>
+ Run your unit tests : right Click on the file containing your test
+ case and click on <code>run</code>
</li>
</ol>
</s2>
<s2 title="Debug your servlet and your tests">
<p>
- You can easily print the results of the methods on the server-side itself.
+ You can easily print the results of the methods on the server-side
+ itself.
</p>
<p>
- You can also start Tomcat in debug mode (<code>Run/debug project</code>).
- This way, you can stop at breakpoints on methods that are executed on the
- server side (<code>void testXXX()</code> for example)
+ You can also start Tomcat in debug mode (<code>Run/debug
+ project</code>). This way, you can stop at breakpoints on methods
+ that are executed on the server side (<code>void testXXX()</code> for
+ example)
</p>
<p>
- If you right click on the file containing your test case and click on
<code>debug</code>,
- you can stop at breakpoints on methods that are executed on the client
side like
- <code>void endXXX(WebResponse)</code> or <code>void
beginXXX(WebRequest)</code>
+ If you right click on the file containing your test case and click
+ on <code>debug</code>, you can stop at breakpoints on methods that
+ are executed on the client side like
+ <code>void endXXX(WebResponse)</code> or
+ <code>void beginXXX(WebRequest)</code>
</p>
</s2>
</s1>
1.2 +10 -12 jakarta-cactus/documentation/docs/xdocs/howto_ide_jbuilder5.xml
Index: howto_ide_jbuilder5.xml
===================================================================
RCS file: /home/cvs/jakarta-cactus/documentation/docs/xdocs/howto_ide_jbuilder5.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- howto_ide_jbuilder5.xml 10 Mar 2002 14:10:25 -0000 1.1
+++ howto_ide_jbuilder5.xml 19 Apr 2002 21:36:01 -0000 1.2
@@ -18,12 +18,12 @@
<p>
This document describes steps to setup Cactus to unit test Server side
code (i.e. EJBs, Servlets, etc) deployed to Weblogic 6.1 within
- Jbuilder5 IDE.
+ JBuilder5 IDE.
</p>
<p>
- The steps described below apply to current release (Cactus 1.2 as of
- this writing) and assuming that Cactus has been installed correctly
+ The steps described below apply to current release (Cactus 1.3 as of
+ this writing) and assume that Cactus has been installed correctly
(which means that you can run sample successfully).
</p>
@@ -33,11 +33,8 @@
<p>
Create cactus.properties file : Add entry to identify the URL of the
- redirector. For example:
- <code>cactus.servletRedirectorURL =
- http://localhost:7001/test/ServletRedirector </code>. Modify this to
- reflect the actual redirector used and the actual URL of the
- redirector.
+ redirector (see the <link href="howto_config.html">Configuration
+ Howto</link> for details).
</p>
</s1>
@@ -83,11 +80,11 @@
</li>
<li>
Follow steps 2 - 6 to add <code>junit.jar</code>,
- <code>httpclient.jar</code> which are all in
- <code>[cactus home]/lib</code> directory
+ <code>httpclient.jar</code> and <code>aspectjrt.jar</code> which are
+ all in <code>[cactus home]/lib</code> directory
</li>
<li>
- Optionally, add <code>log4j-core.jar</code> in
+ Optionally, add <code>log4j.jar</code> in
<code>[cactus home]/lib</code> directory to enable cactus logging
</li>
<li>
@@ -117,7 +114,8 @@
</li>
<li>
Copy <code>cactus.jar</code>, <code>junit.jar</code>,
- <code>log4j-core.jar</code>(optional) to <code>WEB-INF/lib</code>
+ <code>aspectjrt.jar</code> and
+ <code>log4j.jar</code>(optional) to <code>WEB-INF/lib</code>
directory of the web application
</li>
<li>
1.2 +5 -0
jakarta-cactus/documentation/docs/xdocs/howto_ide_vajava_tomcat.xml
Index: howto_ide_vajava_tomcat.xml
===================================================================
RCS file:
/home/cvs/jakarta-cactus/documentation/docs/xdocs/howto_ide_vajava_tomcat.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- howto_ide_vajava_tomcat.xml 10 Mar 2002 14:10:25 -0000 1.1
+++ howto_ide_vajava_tomcat.xml 19 Apr 2002 21:36:01 -0000 1.2
@@ -14,6 +14,11 @@
<s1 title="Forewords and Requirements">
+ <note>
+ <strong>This tutorial is written for Cactus 1.2 only. It will need
+ to adapted if you're using Cactus 1.3</strong>
+ </note>
+
<p>
This tutorial explains how to run Cactus tests within VisualAge for
Java Tomcat Test Environment.
1.2 +5 -0 jakarta-cactus/documentation/docs/xdocs/howto_ide_vajava_wte.xml
Index: howto_ide_vajava_wte.xml
===================================================================
RCS file:
/home/cvs/jakarta-cactus/documentation/docs/xdocs/howto_ide_vajava_wte.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- howto_ide_vajava_wte.xml 10 Mar 2002 14:10:25 -0000 1.1
+++ howto_ide_vajava_wte.xml 19 Apr 2002 21:36:01 -0000 1.2
@@ -14,6 +14,11 @@
<s1 title="Forewords and Requirements">
+ <note>
+ <strong>This tutorial is written for Cactus 1.2 only. It will need
+ to adapted if you're using Cactus 1.3</strong>
+ </note>
+
<p>
This tutorial explains how to run Cactus tests within VisualAge for
Java WebSphere Test Environment.
1.2 +9 -9 jakarta-cactus/documentation/docs/xdocs/howto_junitee.xml
Index: howto_junitee.xml
===================================================================
RCS file: /home/cvs/jakarta-cactus/documentation/docs/xdocs/howto_junitee.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- howto_junitee.xml 10 Mar 2002 14:10:25 -0000 1.1
+++ howto_junitee.xml 19 Apr 2002 21:36:01 -0000 1.2
@@ -16,9 +16,11 @@
<s1 title="JUnitEE, a TestRunner inside the Container">
<p>
- You can use the JUnitEE user interface to run your all your tests
inside
- the Container. JUnitEE is a JUnit TestRunner that has been written as a
- servlet with the user interface in HTML format.
+ You can use the
+ <link href="http://junitee.sourceforge.net";>JUnitEE</link> user
+ interface to run your all your tests inside the Container. JUnitEE is
+ a JUnit TestRunner that has been written as a servlet with the user
+ interface in HTML format.
</p>
<p>
@@ -75,7 +77,8 @@
Download the <link href="http://junitee.sourceforge.net";>JUnitEE</link>
zip-file. Add a reference to junitee.jar to your Container classpath.
Add also references to <code>junit.jar</code>, <code>httpunit.jar</code>
- and <code>cactus.jar</code> if you have not already done that.
+ <code>cactus.jar</code> and <code>aspectjrt.jar</code> if you have not
+ already done that.
</p>
<note>
@@ -120,12 +123,9 @@
<p>
The <code>cactus.properties</code> file must be located so that your
- container can find it e.g. in your containers classpath. The file
- contains an url to the cactus redirector.jsp file such as :
+ container can find it e.g. in your containers classpath.
</p>
-<source>
-cactus.jspRedirectorURL = http://localhost:7001/test/JspRedirector/
-</source>
+
</s1>
</body>
1.2 +15 -35 jakarta-cactus/documentation/docs/xdocs/howto_sample.xml
Index: howto_sample.xml
===================================================================
RCS file: /home/cvs/jakarta-cactus/documentation/docs/xdocs/howto_sample.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- howto_sample.xml 10 Mar 2002 14:10:25 -0000 1.1
+++ howto_sample.xml 19 Apr 2002 21:36:01 -0000 1.2
@@ -60,45 +60,15 @@
<li>
A Servlet Engine (Servlet API 2.2 or above). The Cactus Sample
Ant build script supports automatic running the Cactus unit
- tests on the following Servle Engines (however, it is easy to
- support others)
- <ul>
- <li>
- Tomcat 3.2
- </li>
- <li>
- Tomcat 3.3
- </li>
- <li>
- Tomcat 4.0
- </li>
- <li>
- WebLogic 5.1
- </li>
- <li>
- Orion Server 1.4
- </li>
- <li>
- Orion Server 1.5
- </li>
- <li>
- Resin 1.2
- </li>
- <li>
- Resin 1.3
- </li>
- <li>
- Resin 2.0
- </li>
- </ul>
+ tests on several Servlet Engines.
</li>
<li>
Ant (see the <link href="howto_ant_install.html">"Installing
Ant"</link> tutorial).
</li>
<li>
- A Servlet API jar corresponding to the Cactus Sample release you
- have downloaded (Servlet API 2.2 or 2.3). You can download the
+ A Servlet/J2EE API jar corresponding to the Cactus Sample release
+ you have downloaded (J2EE 1.2 or 1.3). You can download the
jar from :
<ul>
<li>
@@ -125,8 +95,18 @@
</li>
</ul>
</li>
+ <li>
+ For the J2EE jar
+ <ul>
+ <li>
+ From
+ <link href="http://java.sun.com/j2ee/download.html";>J2EE
+ download page</link>
+ </li>
+ </ul>
+ </li>
</ul>
- You can put these libraries whereever you want on your hard disk.
+ You can put these libraries anywhere you want on your hard disk.
You'll just have to specify the location where they are in the
<code>build.properties</code> file, as described below.
</li>
@@ -162,7 +142,7 @@
<p>
Open a shell, cd to the <em><code>sampleroot</code></em>
- <code>/build</code> directory and type '<code>ant tests_all</code>'.
+ <code>/build</code> directory and type '<code>ant test.all</code>'.
The tests will be executed on all the servlet engines you have
defined in the <code>build.properties</code> file you have edited.
</p>
1.2 +2 -1
jakarta-cactus/documentation/docs/xdocs/howto_testcase_filter.xml
Index: howto_testcase_filter.xml
===================================================================
RCS file:
/home/cvs/jakarta-cactus/documentation/docs/xdocs/howto_testcase_filter.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- howto_testcase_filter.xml 10 Mar 2002 14:10:25 -0000 1.1
+++ howto_testcase_filter.xml 19 Apr 2002 21:36:01 -0000 1.2
@@ -34,7 +34,8 @@
them.</strong>
</note>
<note>
- <strong>Filter unit testing is only available in Cactus 1.2</strong>
+ <strong>Filter unit testing is only available in Cactus 1.2 and
+ above.</strong>
</note>
</s1>
1.2 +1 -1
jakarta-cactus/documentation/docs/xdocs/howto_testcase_servlet.xml
Index: howto_testcase_servlet.xml
===================================================================
RCS file:
/home/cvs/jakarta-cactus/documentation/docs/xdocs/howto_testcase_servlet.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- howto_testcase_servlet.xml 10 Mar 2002 14:10:25 -0000 1.1
+++ howto_testcase_servlet.xml 19 Apr 2002 21:36:01 -0000 1.2
@@ -265,7 +265,7 @@
</p>
<note>
- This example is for Cactus 1.2 as it uses the new
+ This example is for Cactus 1.2 and above as it uses the new
<code>WebRequest</code> and <code>WebResponse</code> objects.
</note>
1.2 +11 -8 jakarta-cactus/documentation/docs/xdocs/mockobjects.xml
Index: mockobjects.xml
===================================================================
RCS file: /home/cvs/jakarta-cactus/documentation/docs/xdocs/mockobjects.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- mockobjects.xml 10 Mar 2002 14:10:25 -0000 1.1
+++ mockobjects.xml 19 Apr 2002 21:36:01 -0000 1.2
@@ -56,7 +56,7 @@
domain objects. Thus, the MO approach is to fake domain objects
by using simulated copies instead of the real objects (be careful
MO does not implement any logic in it's fake objects, that would be
- "stubbing". All behaviours of mock objects are described by the unit
+ "stubbing". All behaviours of mock objects are controlled by the unit
test itself). This enables to
finely unit test the method with no environment
"noise" and to concentrate on unit testing its logic.
@@ -158,7 +158,7 @@
This table is not meant to be comprehensive in
term of benefits/inconvenients of using MO. It is more focused on
pros and cons of MO when used for unit testing server side code (i.e.
- what Cactus is focused on).
+ what Cactus is focusing on).
</note>
<note>
A '+' indicates a positive point.For example
@@ -198,8 +198,8 @@
Servlet unit testing, JDBC unit testing, Struts unit testing, ...
Cactus only addresses server-side testing, meaning that if in your
Servlet code you have JDBC connections and you want to unit test
- the methods that does database access you still need to have a
- MO-like strategy, thus you need to understand and learn 2
+ in isolation the methods that does database access you still need
+ to have a MO-like strategy, thus you need to understand and learn 2
strategies.
</td>
<td>
@@ -210,10 +210,10 @@
<tr>
<td>
Running MO tests is very fast as it does not rely on having to run
- a container. Thus tests can be run very often. IC testing need to
+ a container. Thus tests can be run very often. IC testing needs to
start the container, run the tests, stop the container. However,
this can be alleviated by using Ant and by using a reloadable
- container (the majority of servlet engines do dynamic reloading).
+ container (the majority of containers implement dynamic reloading).
</td>
<td>
+
@@ -227,12 +227,15 @@
that a Mock implementation can be implemented. There are other
more subtle refactoring involved like smart handler passing instead
of more fine grained data (thus leading to better encapsulation). It
- follows XP refactoring rules.
+ follows XP refactoring rules. Note that if you need to implement
+ tests for existing code it can easily become a nightmare ...
+ </td>
+ <td>
+ +
</td>
<td>
+
</td>
- <td/>
</tr>
<tr>
<td>
1.1 jakarta-cactus/documentation/docs/xdocs/howto_classpath.xml
Index: howto_classpath.xml
===================================================================
<?xml version="1.0"?>
<!DOCTYPE document SYSTEM "./dtd/document-v10.dtd">
<document>
<header>
<title>Setting the Cactus CLASSPATH</title>
<authors>
<person name="Vincent Massol" email="[EMAIL PROTECTED]"/>
</authors>
</header>
<body>
<s1 title="Setting up Cactus Classpaths">
<p>
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 <code>testXXX()</code> methods will be executed. See
<link href="how_it_works.html">How it works</link> to understand the
mechanism.
</p>
<note>
<strong>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 !</strong>
</note>
<figure src="images/classpath.jpg" alt="Classpaths"/>
<s2 title="Client side classpath">
<p>
The Cactus tests are started by running a JUnit Test Runner (For
explanations on how JUnit works see the
<link href="http://junit.sourceforge.net";>JUnit web site</link>).
As pictured in figure 1, you need to have the following jars and
classes in your client side classpath :
</p>
<ul>
<li>
<strong><code>junit.jar</code></strong> : obviously this is needed
for the JUnit Test Runner and because the Cactus
<code>XXXTestCase</code> classes extend the JUnit
<code>org.junit.framework.TestCase</code> class.
</li>
<li>
<strong><code>cactus.jar</code></strong> : well, this is the
Cactus jar containing all Cactus classes,
</li>
<li>
<strong>your test classes</strong> : these are
your test classes that extend the Cactus <code>XXXTestCase</code>
classes,
</li>
<li>
<strong><code>servlet.jar or j2ee.jar</code></strong> : 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 <code>XXXTestCase</code> which use class
variables that are Servlet / J2EE objects
(<code>HttpSevletRequest</code>, <code>PageContext</code>, ...).
You can get this jar either from your servlet engine or from the
<link href="http://java.sun.com";>Sun Web Site</link> (
<link href="http://java.sun.com/products/servlet/download.html";>
Servlet download page</link> or
<link href="http://java.sun.com/j2ee/download.html";>J2EE download
page</link>).
</li>
<li>
<strong><code>httpclient.jar</code></strong> : needed for
Cactus Cookie handling.
</li>
<li>
<strong><code>log4j.jar</code> (optional)</strong> : only needed
when you want Cactus to output debugging information on the client
side.
</li>
<li>
<strong><code>httpunit.jar</code></strong>, <strong>
<code>Tidy.jar</code></strong> and <strong>
<code>xerces.jar</code> (optional)</strong> : only needed if you
wish to use
<link href="http://httpunit.sourceforge.net";>HttpUnit</link>
in your <code>endXXX()</code> methods (see the
<link href="howto_httpunit.html">HttpUnit Howto</link> tutorial).
The 3 jars mentioned above are part of the HttpUnit distribution.
</li>
<li>
<strong><code>aspectjrt.jar</code></strong> :
<link href="http://www.aspectj.org";>AspectJ</link> runtime jar.
</li>
</ul>
<note>
If you have the habit of using class variables for the classes
to test (as opposed to declaring them within the
<code>testXXX()</code> method), you'll also need to put your classes
under test in the client side classpath.
</note>
<p>
In addition to the above mentionned jars and classes, you will also
need to put the <strong><code>cactus.properties</code></strong>
configuration file in your classpath (because it is a java properties
file). Details are described in the
<link href="howto_config.html">Config Howto</link> tutorial).
</p>
<note>
In theory you would also need to put the
<code>log_client.properties</code> properties file in your classpath.
However a default one is provided in <code>cactus.jar</code>
(and thus is on the classpath as <code>cactus.jar</code> is
itself in the classpath !).
</note>
</s2>
<s2 title="Server side classpath">
<p>
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 :
</p>
<ul>
<li>
<strong><code>WEB-INF/lib/cactus.jar</code></strong> : the
Cactus main jar,
</li>
<li>
<strong><code>WEB-INF/lib/junit.jar</code></strong> : this is
needed because the Cactus <code>XXXTestCase</code> extends
the JUnit <code>org.junit.framework.TestCase</code> class.
</li>
<li>
<strong><code>WEB-INF/classes/<your test classes></code>
</strong> : obviously as their <code>testXXX()</code> methods will
get executed in the container.
</li>
<li>
<strong><code>WEB-INF/classes/<your classes under test></code>
</strong> : will be called by your test classes.
</li>
<li>
<strong><code>WEB-INF/lib/log4j.jar</code> (optional)</strong> :
only needed when you want Cactus to output debugging information
on the server side.
</li>
</ul>
<note>
If you have several webapps that use cactus you may be tempted to
place the <code>cactus.jar</code> 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 <code>com.foo.EvilClass</code>
in webapp A to conflict with <code>com.foo.EvilClass</code> in webapp
B.
</note>
<note>
In theory you would also need to put the
<code>log_server.properties</code> configuration file in your
classpath. However a default one is provided in
<code>cactus.jar</code>
(and thus is on the classpath as <code>cactus.jar</code> is
itself in the classpath !).
</note>
</s2>
</s1>
</body>
</document>
1.1 jakarta-cactus/documentation/docs/xdocs/howto_security.xml
Index: howto_security.xml
===================================================================
<?xml version="1.0"?>
<!DOCTYPE document SYSTEM "./dtd/document-v10.dtd">
<document>
<header>
<title>Testing secure code Howto</title>
<authors>
<person name="Vincent Massol" email="[EMAIL PROTECTED]"/>
</authors>
</header>
<body>
<s1 title="Introduction to testing secure code">
<p>
Since version 1.3 Cactus is able to unit test Servlet code that uses
the Servlet Security API (<code>getRemoteUser()</code>,
<code>isUserInRole()</code>, <code>getUserPrincipal()</code>).
</p>
<p>
The way to perform this is by securing a Servlet Redirector defined
in your <code>web.xml</code> and then to specify user credentials
in your <code>beginXXX()</code>, as defined below.
</p>
<note>
The only currently supported authentication mechanism in Cactus 1.3 is
the BASIC authentication.
</note>
<note>
The Cactus sample application demonstrates how to unit test everything
that is explained here.
</note>
</s1>
<s1 title="Step 1 : Passing credentials in beginXXX()">
<p>
Let's start with an example :
</p>
<source><![CDATA[
public void beginBasicAuthentication(WebRequest theRequest)
{
theRequest.setRedirectorName("ServletRedirectorSecure");
theRequest.setAuthentication(
new BasicAuthentication("testuser", "testpwd"));
}
public void testBasicAuthentication()
{
assertEquals("testuser", request.getUserPrincipal().getName());
assertEquals("testuser", request.getRemoteUser());
assertTrue("User not in 'test' role", request.isUserInRole("test"));
}
]]></source>
<p>
</p>
</s1>
</body>
</document>
1.2 +148 -148 jakarta-cactus/documentation/docs/xdocs/images/classpath.jpg
<<Binary file>>
1.2 +112 -109 jakarta-cactus/documentation/docs/xdocs/images/config.jpg
<<Binary file>>
1.2 +110 -110 jakarta-cactus/documentation/docs/xdocs/misc/archi_classpath.ppt
<<Binary file>>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
