You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cactus-user@jakarta.apache.org by Joerg von Frantzius <jo...@artnology.com> on 2008/01/09 14:02:14 UTC

CactusTask runs test in same VM?

Hi,

probably I have a fundamental misunderstanding of Cactus, but here's my
question: we're trying to run our JUnit tests on a JBoss container,
using the cactus ant task on a war file that is already cactified. When
we try that, we're getting an exception with a stack trace that tells me
that the JUnit-test is executed in the same VM that ant is running in:

            at shortrunning.inside.ProductFlyerFileProviderTest.testBeanAccess(ProductFlyerFileProviderTest.java:28)
    	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    	at java.lang.reflect.Method.invoke(Method.java:585)
    	at junit.framework.TestCase.runTest(TestCase.java:154)
    	at junit.framework.TestCase.runBare(TestCase.java:127)
    	at junit.framework.TestResult$1.protect(TestResult.java:106)
    	at junit.framework.TestResult.runProtected(TestResult.java:124)
    	at junit.framework.TestResult.run(TestResult.java:109)
    	at junit.framework.TestCase.run(TestCase.java:118)
    	at junit.framework.TestSuite.runTest(TestSuite.java:208)
    	at junit.framework.TestSuite.run(TestSuite.java:203)
    	at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:297)
    	at org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.executeInVM(JUnitTask.java:1072)
    	at org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute(JUnitTask.java:682)
    	at org.apache.cactus.integration.ant.CactusTask.executeInContainer(CactusTask.java:458)
    	at org.apache.cactus.integration.ant.CactusTask.execute(CactusTask.java:208)
    	at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
    	at org.apache.tools.ant.Task.perform(Task.java:364)
    	at org.apache.tools.ant.Target.execute(Target.java:341)
    	at org.apache.tools.ant.Target.performTasks(Target.java:369)
    	at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1216)
    	at org.apache.tools.ant.Project.executeTarget(Project.java:1185)
    	at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:40)
    	at org.apache.tools.ant.Project.executeTargets(Project.java:1068)
    	at org.apache.tools.ant.Main.runBuild(Main.java:668)
    	at org.apache.tools.ant.Main.startAnt(Main.java:187)
    	at org.apache.tools.ant.launch.Launcher.run(Launcher.java:246)
    	at org.apache.tools.ant.launch.Launcher.main(Launcher.java:67)
      

I tried to understand what CactusTask.executeInContainer() is doing in
line 258, and it seems to simply call JUnitTask.execute(JUnitTest). How
is any HTTP communication with the server supposed to happen here that
would invoke the test on the container?

Or is the container supposed to be running within the same VM as the ant
build? When I looked at AbstractJavaContainer.createJavaForStartup(), it
seems to fork a VM.

Thanks for any insights,
Jörg

-- 
____________________________________________________________________
artnology GmbH - Milastraße 4 - 10437 Berlin - Germany
Geschäftsführer: Ekkehard Blome (CEO), Felix Kuschnick (CCO)
Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376 
UST-Id. DE 217652550


Re: CactusTask runs test in same VM?

Posted by Petar Tahchiev <pa...@gmail.com>.
Hi Joerg,

since no one is answering, maybe I will give it a try.

What basically is going on is this: you start Ant in a JVM
and it delegates the executions of the tests that you specify
to Cactus(again in the same JVM). Cactus starts the container
and deploys the cactified war
in it (in the the new release this will be a task given to cargo).
When executing the TestCases Cactus initiates a HTTP connection,
to the server, where JUnit executes the tests. The result is given back to
Cactus (again by HTTP), and then it exits (successfully or not) from the
JVM.

So what you see is that, your test-cases might fail in the phase before
sending the HTTP connection to the server (still in the Ant JVM).

Hope that helped.


2008/1/9, Joerg von Frantzius <jo...@artnology.com>:
>
> Hi,
>
> probably I have a fundamental misunderstanding of Cactus, but here's my
> question: we're trying to run our JUnit tests on a JBoss container,
> using the cactus ant task on a war file that is already cactified. When
> we try that, we're getting an exception with a stack trace that tells me
> that the JUnit-test is executed in the same VM that ant is running in:
>
>             at
> shortrunning.inside.ProductFlyerFileProviderTest.testBeanAccess(
> ProductFlyerFileProviderTest.java:28)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at sun.reflect.NativeMethodAccessorImpl.invoke(
> NativeMethodAccessorImpl.java:39)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(
> DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at junit.framework.TestCase.runTest(TestCase.java:154)
>         at junit.framework.TestCase.runBare(TestCase.java:127)
>         at junit.framework.TestResult$1.protect(TestResult.java:106)
>         at junit.framework.TestResult.runProtected(TestResult.java:124)
>         at junit.framework.TestResult.run(TestResult.java:109)
>         at junit.framework.TestCase.run(TestCase.java:118)
>         at junit.framework.TestSuite.runTest(TestSuite.java:208)
>         at junit.framework.TestSuite.run(TestSuite.java:203)
>         at
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(
> JUnitTestRunner.java:297)
>         at
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.executeInVM(
> JUnitTask.java:1072)
>         at org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute(
> JUnitTask.java:682)
>         at org.apache.cactus.integration.ant.CactusTask.executeInContainer
> (CactusTask.java:458)
>         at org.apache.cactus.integration.ant.CactusTask.execute(
> CactusTask.java:208)
>         at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java
> :275)
>         at org.apache.tools.ant.Task.perform(Task.java:364)
>         at org.apache.tools.ant.Target.execute(Target.java:341)
>         at org.apache.tools.ant.Target.performTasks(Target.java:369)
>         at org.apache.tools.ant.Project.executeSortedTargets(Project.java
> :1216)
>         at org.apache.tools.ant.Project.executeTarget(Project.java:1185)
>         at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(
> DefaultExecutor.java:40)
>         at org.apache.tools.ant.Project.executeTargets(Project.java:1068)
>         at org.apache.tools.ant.Main.runBuild(Main.java:668)
>         at org.apache.tools.ant.Main.startAnt(Main.java:187)
>         at org.apache.tools.ant.launch.Launcher.run(Launcher.java:246)
>         at org.apache.tools.ant.launch.Launcher.main(Launcher.java:67)
>
>
> I tried to understand what CactusTask.executeInContainer() is doing in
> line 258, and it seems to simply call JUnitTask.execute(JUnitTest). How
> is any HTTP communication with the server supposed to happen here that
> would invoke the test on the container?
>
> Or is the container supposed to be running within the same VM as the ant
> build? When I looked at AbstractJavaContainer.createJavaForStartup(), it
> seems to fork a VM.
>
> Thanks for any insights,
> Jörg
>
> --
> ____________________________________________________________________
> artnology GmbH - Milastraße 4 - 10437 Berlin - Germany
> Geschäftsführer: Ekkehard Blome (CEO), Felix Kuschnick (CCO)
> Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376
> UST-Id. DE 217652550
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cactus-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: cactus-user-help@jakarta.apache.org
>



-- 
Regards, Petar!
Karlovo, Bulgaria.

EOOXML Objections
http://www.grokdoc.net/index.php/EOOXML_objections

Public PGP Key at:
https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611