|
Last update : August 25 2002
Doc for : v1.4
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
Jsp Howto
Runner Howto
Security Howto
Ant Howto
HttpUnit Howto
Sample Howto
EJB Howto
IDE Howto
Tomcat Howto
JUnitEE Howto
Support
Bug database
Mailing list
Misc.
Why the name ?
Logo Challenge
Resources
Test Coverage
Stats
Developers
CVS
Coding Conventions
Build results
Release Checklist
|
Can't find resource for cactus error message |
If you get the following stack trace :
java.lang.ExceptionInInitializerError: java.util.MissingResourceException:
Can't find bundle for base name cactus, locale en_GB
at java.util.ResourceBundle.throwMissingResourceException(ResourceBundle.java:707)
at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:679)
at java.util.ResourceBundle.getBundle(ResourceBundle.java:546)
|
it simply means that you have not put the cactus.properties file in
your CLASSPATH (i.e. the directory which contains this file should
be in the CLASSPATH). This file is the Cactus configuration file and
is required. Check the Cactus
Configuration Howto page for
more information.
|
How can I have a web.xml that is valid both for testing and for production ? |
Question |
Cactus needs to have a few entries set in the web.xml
file (redirector definition and mappings mostly). The application to
test also needs its own entries. What would be nice would be to be
able to use the same web.xml file in the build process
for both application testing and deployment to production.
|
Solution |
Here's how I accomplished conditional inclusion
of Cactus web.xml configuration. My web.xml file is capable of
working standalone without requiring any filtered copy to work.
In Ant I'm doing this:
<!-- Activate the Cactus web.xml configuration -->
<copy todir="${admin.build.dir}/WEB-INF"
file="web/admin/WEB-INF/web.xml"
overwrite="yes">
<filterset>
<filter token="start.cactus.config" value="-->" />
<filter token="end.cactus.config" value="<!--" />
</filterset>
</copy> |
In web.xml I have this:
<!-- Cactus configuration
Note: Do not place any XML comments in this Cactus configuration section
(Ant's filtered copy is used to activate this configuration when the test
web application is built)
-->
<!-- Begin Cactus Configuration @start.cactus.config@
<servlet>
<servlet-name>ServletRedirector</servlet-name>
<servlet-class>org.apache.cactus.server.ServletTestRedirector</servlet-class>
</servlet>
<servlet>
<servlet-name>JspRedirector</servlet-name>
<jsp-file>/somewhere/jspRedirector.jsp</jsp-file>
</servlet>
<servlet-mapping>
<servlet-name>ServletRedirector</servlet-name>
<url-pattern>/ServletRedirector/</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>JspRedirector</servlet-name>
<url-pattern>/JspRedirector/</url-pattern>
</servlet-mapping>
@end.cactus.config@ End Cactus Configuration -->
|
|
|
I'm getting a java.io.StreamCorruptedException error. What does it mean ? |
 |
This error only appears for Cactus 1.3dev (before 21/04/2002) and
below. Cactus 1.3 no longer uses a serialized object to return test
result. It uses an XML string.
|
Solution |
This exception results when client-side Cactus code attempts to talk
to a misconfigured installation of Cactus on the server side. The
reason for the obscure exception is this: Cactus makes two requests
to the server. In the first, the client-side test runner requests that
such-and-such a test be run on the server (an oversimplification,
please see: XXXX). Immediately after the response from the server
the client code makes a second request, this time for the results of
the server-side test. Cactus is supposed to send back a serialized
Object containing the results. Cactus then attempts to deserialize
this Object from the input stream in the response. If
Cactus is installed properly on the server, this process
works transparently. If not (for instance the second
request does not even arrive at a Cactus redirector) then
the response to the second request (which very well may be
a 404 or 500 error) will not contain the object that
client-cactus expects. This leads to the
StreamCorruptedException.
When troubleshooting this error, the most likely prospect
is that the requests from client-Cactus are not even
reaching server-Cactus. This can happen when the
cactus.properties contains a bad entry. For instance, I
have run into this problem when building several different
testing-applications. I tried to run my tests against
http://localhost/webapp1/ServletRedirector/ when I needed
to be running against
http://localhost/webapp2/ServletRedirector/ . This can
also happen if your web.xml file contains an error, or does not
properly map the URLs contained in cactus.properties to the
Cactus redirectors.
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. Actually the Cactus redirectors provide a URL just for
that : http://localhost/webapp/ServletRedirector?Cactus_Service=RUN_TEST
(this also works for the other redirectors).
 |
If you call http://localhost/webapp/ServletRedirector
directly, you'll get a 500 error and get a stack trace (in the log or
along with your error page) that says Missing service
name parameter [] in HTTP request. . This is because the
Cactus redirector expects HTTP parameter from the Cactus client side.
|
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
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-1.3 installation).
|
|
How can I test the chaining of several HTTP requests ? |
Question |
Let's imagine that I have one servlet that performs an HTTP redirect
to a JSP page (or to another servlet). How do I test it with Cactus ?
|
Solution |
Short answer : you don't !
Long answer : Cactus is meant to be a unit testing tool, meaning it
lets you perform tests for a given method and then it lets you
assert the result from that method.
In the above scenario, a typical Cactus test will consist in
verifying that the return HTTP response is an HTTP redirect (by
checking the HTTP response code - 302 - in the endXXX()
method) and possibly also checking the URL of the redirect page.
Then, as a second test, you could (if you wish) verify that calling
the URL of the JSP does return such HTML content (using HttpUnit
integration for example). Note that this second test is rather a
functional test than a unit test but it can still be viewed as
unit testing the doGet() method of the JSP ...
|
|
The Ant runservertests task hangs when my server is started |
Question |
When I use the runservertests Cactus custom Ant task,
it starts my server allright but then hangs and the tests are not
executed. What is happening ?
|
Solution |
It means that the testURL attribute you've specified
in runservertests is not a valid URL. It must be a URL
that is valid when the server is up. To diagnosis the problem simply
open a browser once your server is started (i.e. when the task hangs)
and type the URL in your browser. An alternative to debug is also to
run Ant in debug mode (ant -debug [your target] ).
With Cactus 1.3, the correct URL to call is the following, which is
always valid :
http://localhost:8080/webapp/ServletRedirector?Cactus_Service=RUN_TEST .
Of course replace webapp by your webapp context and
replace the port by the one you're using.
|
|
I'm getting a 'not a valid response' error message. What does it mean ? |
Question |
When I run my Cactus test, I'm getting the following :
testRequestDispatcherInclude(org.apache.cactus.sample.TestSampleServlet)
org.apache.cactus.util.ChainedRuntimeException:
Not a valid response
at
org.apache.cactus.client.WebTestResultParser.readRootElement(
WebTestResultParser.java;org/apache/cactus/util/log/LogAspect.java(1k):134)
|
|
Solution |
It means that Cactus could not connect to the server side properly.
There could several reasons for this : a valid Redirector URL but
not pointing to the Redirector, a secured resource, etc.
To easiest way to diagnosis the problem is to enable Cactus logging
(see the Configuration Howto
for how to do this). The cactus client log
(cactus_client.log will clearly give the error).
|
|
How to send multipart/form-data ? |
Question |
How to send multipart/form-data to my servlet under test ?
|
Solution |
One solution is to use the
HTTPClient
classes from Ronald Tschalar, as demonstrated in the following
example :
import HTTPClient.Codecs;
import HTTPClient.NVPair;
.
.
.
NVPair[] hdrs = new NVPair[1];
public void beginUpload(WebRequest theRequest)
{
NVPair[] opts = { new NVPair("option", "myoption") };
NVPair[] file = { new NVPair("comment", "/home/alan/src.zip") };
try {
byte[] data = Codecs.mpFormDataEncode(opts, file, hdrs);
InputStream i = new ByteArrayInputStream(data);
theRequest.setUserData(i);
theRequest.setContentType(hdrs[0].getValue());
i.close();
} catch (IOException e) {
System.out.println("Error Building Multipart");
}
}
|
|
|
I get a 'java.lang.ClassCastException: org.apache.commons.logging.impl.LogFactoryImpl' error when I use a JUnit TestRunner different from TextTestRunner |
Question |
Cactus tests run fine when I use the JUnit TextTestRunner but
fails with other runners like the SwingTestRunner. I get the
following exception :
org.apache.commons.logging.LogConfigurationException:
java.lang.ClassCastException: org.apache.commons.logging.impl.LogFactoryImpl
at org.apache.commons.logging.LogFactory.newFactory(LogFactory.java:505)
at org.apache.commons.logging.LogFactory.getFactory(LogFactory.java:340)
at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:381) at
org.apache.cactus.AbstractTestCase.runBare(AbstractTestCase.java:188)
|
|
Solution |
Check the
JUnit
FAQ. Indeed, JUnit uses a special class loader to
load classes that is incompatible with the Commons-Logging
framework. Thus you need to put the commons-logging package in the
JUnit excluded.properties file (see the JUnit FAQ).
|
|
|
|