Re: Cactus tests - HOWTO

[Grant Smith]

Basically, the only difference for Tomcat 5.5 is that commons-el.jar and jsp-2.0.jar should not be included in WEB-INF/lib. Sean Schofield wrote: You are correct that build-webapps.xml ignores it. What is it for anyways? I am using Tomcat 5.1 and the resulting WAR files work for me. Is there something different for required to get the WARs to work with Tomcat 5.5? If so, then we may need to add it back in. The main thing is that we broke out the tomcat deployment which many people do not need and certainly was not needed for the automated nightly build or the release build. If I inadvertently broke something I'm happy to try and help fix it ;-) sean On 4/26/05, Grant Smith <[EMAIL PROTECTED]> wrote: Sean, The original build/foo/build.xml files did some processing based on the value of the tomcat.pre.5.5.version property. Is this not required anymore ? I noticed that your build-webapps.xml ignores it. +1 on the idea of having deploy-webapps.xml & some kind of cactus-tests.xml and removing the build/foo/build.xml's Sean Schofield wrote: I ran into a problem with the build.xml scripts inside each of the build directories myself. Ex. build/blank-webapp/build.xml The problem was that these referenced jars that were not in CVS (either by license restriction or by choice.) I made major modifications to the master build.xml and added a new build-webapps.xml. This is how all of the webapps are built for the nighlty build and release. I omitted everything to do with cactus and tomcat deployment because this is overkill for some users and not needed for the nightly build. If we could come up with a single deploy-webapps.xml and call it from the master build.xml that would be cool. Basically something simliar to what I set up for the release build of the webapps. Then we could wipe out all of the build/foo directories. I'm not sure about the cactus stuff but maybe we could also take this approach with cactus. I haven't used cactus in a long time so I'm probably not the best person to do this. sean On 4/26/05, Grant Smith <[EMAIL PROTECTED]> wrote: Oliver Rossmueller wrote: Thanks for the info, Oliver. I was able to get a little further into the ant task before it complained this time. I think I don't have the correct jars available to the ant environment. Could you tell me exactly which jars are needed in $ANT_HOME/lib ? That would help immensely. It would also be nice (in the future) if we could modify the build.xml so that we dont have to manually make changes to the local ant envirenment in order to perform these tests - I may take that on after I get the tests working for myself. Thanks for your help! -Grant. Grant, the problem is related to cactus 1.5 (or better the aspectj stuff cactus 1.5 is using, which seems to be a problem for the 1.5 JVM). So I updated cactus to the latest release 1.7 and now the tests are executed without problems. Some tests are broken but the general setup for cactus tests seems to be ok. So if you update to the latest HEAD revision you'll get cactus 1.7 plus the xerces version required by nekohtml to get the cactus tests working also on your box. Oliver Grant Smith wrote: OK, So I thought I'd start being productive, and attack a simple JIRA issue. I zoned in on MYFACES-187, as it had a simple solution of removing some code. I commented out the code, then decided to run all-tests from the main build file. Firstly, ant complained about not having access to junit, so I configured IDEA to include it in the ANT environment. Should this not be fixed ? Secondly, every single cactus test failed with: Exception in constructor: testSimpleRender (java.lang.ClassFormatError: Invalid index 0 in LocalVariableTable in class file org/apache/cactus/util/log/LogAspect at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:620) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124) at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) at java.net.URLClassLoader.access$100(URLClassLoader.java:56) at java.net.URLClassLoader$1.run(URLClassLoader.java:195) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) at Now, it's obvious that I'm not configuring something correctly. I'm running under Tomcat 5.5, Linux, JDK 1.5.0_2. If somebody wants to fill me in on the delicate details of running the tests successfully, I will document the process in the doc/ subdirectory. Thanks, Grant.