jakarta-cactus-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevin Murdoff" <KMURD...@dfg.ca.gov>
Subject Re: Running <cactus> from Ant
Date Thu, 13 Oct 2005 16:05:12 GMT
Hi -

Thank you for your reply!

I briefly tried supplying a 'server.xml' file via the 'serverxml' attribute like you suggested.
 I also tried the 'contextxml' attribute as well.  No joy.  However, I did finally get the
thing to work.  Problem is, I'm not sure how!  All I did (i.e. remember doing) was enter the
'serverxml' attribute and then take it out ... (???)

Anyway, using port 55555 and 'C:/Temp' as the 'tmpdir', it works.

Below is the <cactus> task I'm using (as an FYI):

		<cactus warfile="${dist.cactus.dir}/${war.file}" fork="true" printsummary="true">
			<classpath refid="classpath"/>
			<classpath refid="jcoverage" />
			<classpath location="${instrumented.build.dir}"/>
			<!-- classpath location="${app.build.dir}" / -->
			<classpath location="${test.build.dir}" />
			<formatter type="xml"/>
			<containerset timeout="30000" >
				<tomcat4x dir="${tomcat.home}" port="55555" tmpdir="C:/Temp"></tomcat4x>
			<batchtest todir="${build.reports.dir}" >
				<fileset dir="${cactus.src}">
					<include name="**/FGIdentifyTest.java"/>
					<include name="**/ZoomRegulation_isDecimalNumberTest.java"/>

I have another question I hope you can help me with:

Why does one of my tests work correctly in the browser using 'ServletTestRunner', but not
in the <cactus> Ant task?

The assert method that fails reports an assertion failure when I try to assert that a value
stored in a 'session'-scoped JavaBean is, in fact, what I expected.  The JavaBean does exist,
and through logs I can verify that it's values are being set properly, but when the <cactus>
task runs the test, the assertion fails.

Is there a difference in handling session-scoped beans between the two runners?

Thank you so much!


Kevin F. Murdoff
GIS / J2EE Software Engineer
Department of Fish and Game
1807 13th Street, Suite 201
Sacramento, CA  95814
(916) 445-3537

>>> suguri.kazuhito@lab.ntt.co.jp 10/11/05 10:32 PM >>>

In article <s34b71b3.064@dfg.ca.gov>,
Tue, 11 Oct 2005 08:02:27 -0700,
"Kevin Murdoff" <KMURDOFF@dfg.ca.gov> wrote: 
KMURDOFF> I read in the docs that the <containerset> won't start and stop
KMURDOFF> Tomcat if it is already running, but when I use it with a port of
KMURDOFF> 8080, it complains (obviously) that port 8080 is already bound.
KMURDOFF> No doubt by my existing Tomcat instance.

AFAIK, to know whether a container is already running,
<cactus> task accesses to ServletRedirector of the target contextURL
and checks its response status. In other words, <cactus> task checks
whether the target cactified application is available.
So, you need to deploy the cactified application
prior to the <cactus> task call.

KMURDOFF> However, when I change the port to say 55555, none of my tests succeed.
KMURDOFF> The test classes could not be loaded by the Context and web apps class loaders.

If you only changed the port attribute of the tomcat5x element
in your build.xml, that may be not enough. You need to provide
a server configuration file (server.xml) for the new server instance.
In your use case, I think, the server.xml, which has been configured
for the existing server instance, has conflicting conditions
that cause the start up of the new server to be failed.
<tomcat5x> task uses ${directory specified by dir attr}/conf/server.xml
to start up the new server by default, but you can change it
by using serverxml attribute.

Be sure that all ports the new server will listen to are not in use
by the existing server, 8005 and 8080 for examples.

Hope this helps,
Kazuhito SUGURI

To unsubscribe, e-mail: cactus-user-unsubscribe@jakarta.apache.org 
For additional commands, e-mail: cactus-user-help@jakarta.apache.org 

View raw message