> -----Original Message----- > From: Matt Raible [mailto:[EMAIL PROTECTED] > Sent: 16 January 2004 18:06 > To: 'Cactus Users List' > Subject: RE: cactus ant task on existing container ? > > Hmmm, now Tomcat seems to start just fine, but my app doesn't seem to > get configured. Tomcat just hangs (for minutes) after the following log > messages: > > [cactus] > ----------------------------------------------------------------- > [cactus] Running tests against Tomcat 4.1.29 > [cactus] > ----------------------------------------------------------------- > [cactus] Deleting 6 files from > c:\DOCUME~1\mraible\LOCALS~1\Temp\cactus\tomcat4x > [cactus] Deleted 7 directories from > c:\DOCUME~1\mraible\LOCALS~1\Temp\cactus\tomcat4x > [cactus] HttpConnector Opening server socket on all host IP addresses > [cactus] Starting service Tomcat-Standalone > [cactus] Apache Tomcat/4.1.29 > [cactus] HostConfig[localhost]: Deploying configuration descriptor > appfuse.xml > [cactus] HttpConnector[8080] Starting background thread > > Is this because my context.xml (appfuse.xml) needs to have > docBase="appfuse.war" instead of docBase="appfuse"? > > [a bit later] I tried that and it worked. It is possible to expand the > war by default?
Not at present. The war is deployed as a war file and not as an expanded directory. On http://jakarta.apache.org/tomcat/tomcat-5.0-doc/printer/deployer-howto.h tml it says: "It should be noted that the docBase specified in the Context element can refer to either the .WAR or the directory which will be created when the .WAR is expanded or the .WAR itself.". Looks that it is what you want but maybe this is a Tomcat 5.x feature only... I'm still hesitating to add this feature (deploying as an exploded war) as I'm not sure what benefit it would provide for <cactus> users. On a related matter, are you sure tomcat 4.1.x doesn't support META-INF/context.xml files? (this article seems to imply it does: http://www.onjava.com/pub/a/onjava/2003/01/08/tomcat4.html?page=3). Question: For context.xml files put inside META-INF, do you also need to specify a docBase? > For the time being, I simply added some buid.xml logic > to customize the context.xml just for cactus tests. One thing I don't > like about using the <cactus> task over the <runservertests> task is > this: > > My target that uses <runservertests> can call a "testTarget", which in > my case is "test-web". This target calls "test-module" to have a common > <junit> test configuration for all my tests (from Erik Hatcher's Ant > book). With the <cactus> task, I get a bit of duplication for > definition <classpath>, <formatter>'s and <batchtest> stuff. I agree > that it is minimal and realize this is because it extends the <junit> > task. When you say "common <junit> test config", what is it common with? > > I'll probably leave the "start.tomcat" and "stop.tomcat" stuff in my > build.xml file because they're nice ways to debug tomcat and I use them > for running Canoo's Webtest, Yes, I'd also like that we add <startcontainer>/<stopcontainer> Ant tasks for starting/stopping containers. It should be very easy to implement as we're already doing it in the <cactus> task. We could probably even reuse the existing <[container name]> nested elements (they're already Ant task in their implementation I think), and simply add an "action" attribute (action="start|stop"). Anyone wishing to help? :-) > > One advantage (I think) of using <cactus> over <runservertests> is that > <cactus> doesn't care if tomcat is running? Is this true? Yes, it's true (provided you use a different port of course). It installs a separate conf/ and webapps/ directory. > I also like > that it'll test on an "empty" version of Tomcat instead of the default > one (that might have many apps in webapps). Yep. One of the nice side-effects is that it forces/helps you to clearly save your custom container configuration somewhere in your project. > > As a speed comparison: > > ant clean test-cactus (uses <runservertests>) takes: 1 minute 44 seconds > ant clean cactus (uses <cactus>) takes: 1 minute 42 seconds cool. I would have thought the <cactus> would be much slower. That's cool! :-) > > Above all, I do dig the <cactus> task which should allow me to test > multiple containers. Now if it was only easier to configure other > servers (i.e. Resin, Orion) with a simple context.xml file. Why is it more complex? For Resin, simply pass a resin.conf file to the <resin2x> element, no? Thanks -Vincent > > Thanks, > > Matt > > > -----Original Message----- > > From: Matt Raible [mailto:[EMAIL PROTECTED] > > Sent: Friday, January 16, 2004 9:19 AM > > To: 'Cactus Users List' > > Subject: RE: cactus ant task on existing container ? > > > > > > Nevermind, I just saw the contextxml, let me try that. > > > > > -----Original Message----- > > > From: Matt Raible [mailto:[EMAIL PROTECTED] > > > Sent: Friday, January 16, 2004 9:18 AM > > > To: 'Cactus Users List' > > > Subject: RE: cactus ant task on existing container ? > > > > > > > > > > > > > I believe the IncompatibleClassChangeError is caused by something > > > > else than the change I did. What version of Cactus were you > > > > previously using? > > > > > > > > > > Previously I was using 13-1.5. > > > > > > > Could you also try to rebuild completely your application > > > > using the new Cactus you've downloaded? > > > > > > > > BTW, are you using the > > > > http://cvs.apache.org/builds/jakarta-cactus/nightly/2004-01-16 > > > > / build? If not, could you use this one instead of the one > > > > from the 15th? That's because Chris reminded me that Tomcat > > > > 5.x worked differently and did not support putting the > > > > context xml file in webapps. Thus I made more modifications > > > > to the code this morning. > > > > > > Yeah, I'm using 20040116. I undeployed and rebuilt > > > everything and still got this error. Do I have to specify a > > > path to my context.xml - or will it look in $CATALINA_HOME/webapps? > > > > > > > > > > > Thanks > > > > -Vincent > > > > > > > > > -----Original Message----- > > > > > From: Matt Raible [mailto:[EMAIL PROTECTED] > > > > > Sent: 16 January 2004 16:14 > > > > > To: [EMAIL PROTECTED] > > > > > Subject: RE: cactus ant task on existing container ? > > > > > > > > > > Vincent, > > > > > > > > > > Regarding the enhancement you added to check for > > > context.xml in the > > > > > webapps folder: > > > > > > > > > > > ok. I've implemented and committed it. I'm currently > > > > running a full > > > > > > build now which I'll upload in the nightly build area. > > > It would be > > > > > cool > > > > > > if you could test it though... :-) > > > > > > > > > > I tried it (and added output to my task to supress logging > > > > - thanks!) > > > > > and found some strange errors: > > > > > > > > > > [cactus] Testcase: > > > > > > > > testFormAuthentication(org.appfuse.webapp.action.LoginServletTest): > > > > > Caus > > > > > ed an ERROR > > > > > [cactus] null > > > > > [cactus] java.lang.IncompatibleClassChangeError > > > > > [cactus] at > > > > > > > > > org.appfuse.webapp.action.LoginServletTest.beginFormAuthentica > > > > tion(Login > > > > > ServletTe > > > > > st.java:84) > > > > > [cactus] at > > > > sun.reflect.NativeMethodAccessorImpl.invoke0(Native > > > > > Method) > > > > > [cactus] at > > > > > > > > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccess > > > > orImpl.jav > > > > > a:39) > > > > > [cactus] at > > > > > > > > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMeth > > > > odAccessor > > > > > Impl.java > > > > > :25) > > > > > [cactus] at > > > > > > > > > org.apache.cactus.internal.client.ClientTestCaseCaller.callGen > > > > ericBeginM > > > > > ethod(Cli > > > > > entTestCaseCaller.java:436) > > > > > [cactus] at > > > > > > > > > org.apache.cactus.internal.client.ClientTestCaseCaller.callBeg > > > > inMethod_a > > > > > roundBody > > > > > 0(ClientTestCaseCaller.java:237) > > > > > [cactus] at > > > > > > > > > org.apache.cactus.internal.client.ClientTestCaseCaller.callBeg > > > > inMethod_a > > > > > roundBody > > > > > 1$advice(ClientTestCaseCaller.java:158) > > > > > [cactus] at > > > > > > > > > org.apache.cactus.internal.client.ClientTestCaseCaller.callBeg > > > > inMethod(C > > > > > lientTest > > > > > CaseCaller.java) > > > > > [cactus] at > > > > > > > > > org.apache.cactus.internal.client.ClientTestCaseCaller.runTest > > > > (ClientTes > > > > > tCaseCall > > > > > er.java:186) > > > > > [cactus] at > > > > > > > > > org.apache.cactus.AbstractCactusTestCase.runBareClient(Abstrac > > > > tCactusTes > > > > > tCase.jav > > > > > a:244) > > > > > [cactus] at > > > > > > > > > org.apache.cactus.AbstractCactusTestCase.runBare(AbstractCactu > > > > sTestCase. > > > > > java:162) > > > > > > > > > > [cactus] at > > > > > > > > > org.apache.cactus.integration.ant.CactusTask.executeInContaine > > > > r(CactusTa > > > > > sk.java:4 > > > > > 89) > > > > > [cactus] at > > > > > > > > > org.apache.cactus.integration.ant.CactusTask.execute(CactusTas > > > > k.java:253 > > > > > ) > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: > > [EMAIL PROTECTED] > > > > > For additional commands, e-mail: > > > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
