The Cactus project is pleased to announce the release of version 1.6.1.
Cactus is a unit testing framework for testing server side java code.
Primarily a bug fix release. Several usability enhancements and the addition of the Maven plugin as part of the Cactus distribution. Move to the Apache 2.0 license.
Main new features
* [Core] Added the Maven plugin. It was formerly hosted in the Maven
project's own CVS. It is now in the Cactus CVS and is part of the
Cactus distribution. To install the plugin in your Maven installation
* [Core] Added new ServletContextWrapper.setInitParameters() method which allows
to programatically define Context init parameters.
* [Ant] The <cactus> Ant task now supports Mac OSX.
* [Ant] Added support for Resin 3.x in the <cactus> Ant task (<resin3x> element).
* [Ant] Better configurability of the <cactus> container elements:
- new configXml attribute for the <weblogic7x> element
- added support for JBoss jboss-web.xml in the <jboss3x> element
- new contextxml attribute for the <tomcat4x> element
- new jndiport attribute for the <jboss3x> element
* [Maven] Only runs tests if there are Cactus tests present in the filesystem.
* [Maven] Added support for EJB testing with Cactus.
* [Maven] Added cactus.jboss3x.jndiport property to specify which JNDI port to
use when shutting down JBoss.
* [Maven] Added support for Resin 3.x (above version 3.0.5).
* [Maven] Added support for custom ports when using JBoss. Please note that
this will only work with custom JBoss configs. The default config used by
Cactus uses port 8080 (that's the default JBoss config).
* [Maven] Added 2 new properties to support debugging Cactus tests:
cactus.logging.config.client and cactus.logging.config.server. They point
to logging config properties file.
* [Maven] Added support for custom WebLogic config.xml
* [Maven] The cactus:test goal now automatically discovers JUnit Test Cases
from non JUnit java classes and by default excludes all classes that are
Please check the Changes page at
http://jakarta.apache.org/cactus/changes.html for a full list of the
changes in version 1.6.1.
Please check the Changes page at
for a full list of the changes in the Maven plugin for Cactus 1.6.1.
Known limitations and bugs:
* Possible binary compatibility problem: We've had a big internal
restructuration: we have moved all the non public API classes to java
packages with the name "internal". As a result of this change you may
need in some cases to rebuild your code with the new cactus jar in the
* Due to the internal package restructuration, the jspredirector.jsp file
was modified. If you have installed this file manually somewhere, you'll
need to remember to update it with the new version.
* List of known bugs are available on http://tinyurl.com/3ymel
For more information about Cactus, please visit
-The Cactus team
- eclipse plugin by The Industry Observer on May 17 2004 11:51 EDT
- ServletTestRunner by Brock Heinz on May 17 2004 14:57 EDT
Any news about the eclipse plugin . when is that going to work???
Any news about the eclipse plugin . when is that going to work???It has been removed. The guy who initially created it has left it in an unfinished state and so far the Cactus committer have not had the time/will to fix the code to make it work again. It should be quite easy though. Just needs someone to dive it... Volunteers are very welcome and will be covered with flowers, we will song their praises, etc... :-)
While recently working with a client we had a scenario where we were building and deploy an EAR file on a nightly basis. This build consisted of the typical JUnit regression tests being run, but we needed something more. We wanted to have the ability to run our unit tests (or regression tests) via the browser and we wanted to immediately see the results. With Cactus' ServletTestRunner, we were able to (relatively easily) create a test WAR that is deployed along side our nightly EAR file.
Originally just the developers were executing the tests via the browser, and we just needed to remember the TestCase's names (along with packages) and we would pass them to the ServletTestRunner via the 'suite' request parameter. No big deal. But, as the project evolved and more people wanted to execute the tests, this scenario didn't fit will. So then we created an index file that was to be deployed with the test WAR. Basically we had to add by hand the links to execute the given tests as they were written. This was fine, but we quickly realized that this could be automated with our build. So after spending a few hours writing an ANT task, we were able to generate an index Cactus file that showed links to all of our Unit and Regression tests. An static HTML example of this can be seen here:
Since this was done some time ago, I'm not sure if the folks at Cactus have developed something similar (or if it even already exists :) But if anyone finds this useful, I'd like to contribute it to the community. Anyone have any thoughts on this?
Since this was done some time ago, I'm not sure if the folks at Cactus have developed something similar (or if it even already exists :) But if anyone finds this useful, I'd like to contribute it to the community. Anyone have any thoughts on this?BrockWe value all feedbacks! If you're interested in getting this integrated we could start a discussion on the Cactus mailing list. I'd like to understand more about your use case and why you think using the provided <cactus> task + the <junitreport> cannot fill the bill.
I'm a few days late i'm sure, but this task of automatically creating an index.html to go into the cactified war sounds most excellent! I like to run individual tests myself sometimes and am constantly forgetting the URL...
I've posted the ANT task that I created and a build file snippet here: http://brockheinz.dyndns.org/cactus. After bouncing a few emails around on the cactus-dev list, it looks as though I may be building this into the cactifywar task. Until then, let me know if you have any questions setting up /using the task.