[JBoss JIRA] (ARQ-1996) Upgrade to ShrinkWrap 1.2.3
by Aslak Knutsen (JIRA)
Aslak Knutsen created ARQ-1996:
----------------------------------
Summary: Upgrade to ShrinkWrap 1.2.3
Key: ARQ-1996
URL: https://issues.jboss.org/browse/ARQ-1996
Project: Arquillian
Issue Type: Component Upgrade
Components: Base Implementation
Affects Versions: 1.1.10.Final
Reporter: Aslak Knutsen
Assignee: Aslak Knutsen
Fix For: 1.2.0.Alpha1
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (ARQ-1255) Multiple deployments is not working in Weld SE container
by Antonin Stefanutti (JIRA)
[ https://issues.jboss.org/browse/ARQ-1255?page=com.atlassian.jira.plugin.s... ]
Antonin Stefanutti commented on ARQ-1255:
-----------------------------------------
Test case is available here: https://github.com/astefanutti/arquillian-container-weld/blob/ARQ-1255/we...
It's available starting Weld version {{2.1.0.Final}} so that I created a new module {{weld-se-embedded-2.1}}.
> Multiple deployments is not working in Weld SE container
> --------------------------------------------------------
>
> Key: ARQ-1255
> URL: https://issues.jboss.org/browse/ARQ-1255
> Project: Arquillian
> Issue Type: Bug
> Components: Weld Containers
> Affects Versions: 1.0.0.CR5
> Reporter: Antonin Stefanutti
> Attachments: Bean1.java, Bean2.java, MultipleDeploymentArquilianCdiTest.java, OperateOnDeploymentArquilianCdiTest.java, pom.xml, test_case_1_stacktrace.txt, test_case_2_stacktrace.txt
>
>
> As described in [Multiple Deployments|https://docs.jboss.org/author/display/ARQ/Multiple+Deployments], multiple {{@Deployment}} annotated methods can be declared in a test class. In addition, the {{@OperateOnDeployment}} annotation enables the selection of a particular _deployment_ per test method.
> However, when using Arquillian with a Weld SE container, the CDI container isn't deployed with the expected archives which ends up having {{DeploymentException}} thrown, as illustrated in the test cases below:
> *Test case 1:*
> {code}
> @RunWith(Arquillian.class)
> public class MultipleDeploymentArquilianCdiTest {
> @Inject
> private Bean1 bean1;
> @Inject
> private Bean2 bean2;
> @Deployment(name = "bean1-jar")
> public static Archive<?> createBean1Jar() {
> return ShrinkWrap.create(JavaArchive.class).addClass(Bean1.class).addAsManifestResource(EmptyAsset.INSTANCE, "beans.xml");
> }
> @Deployment(name = "bean2-jar")
> public static Archive<?> createBean2Jar() {
> return ShrinkWrap.create(JavaArchive.class).addClass(Bean2.class).addAsManifestResource(EmptyAsset.INSTANCE, "beans.xml");
> }
> @Test
> public void multiDeploymentTest() {
> assertNotNull(bean1);
> assertNotNull(bean2);
> }
> }
> {code}
> *Test case 2:*
> {code}
> @RunWith(Arquillian.class)
> public class OperateOnDeploymentArquilianCdiTest {
> @Inject
> private Bean1 bean1;
> @Inject
> private Bean2 bean2;
> @Deployment(name = "beans-jar")
> public static Archive<?> createBeansJar() {
> return ShrinkWrap.create(JavaArchive.class).addClass(Bean1.class).addClass(Bean2.class).addAsManifestResource(EmptyAsset.INSTANCE, "beans.xml");
> }
> @Deployment(name = "bean1-jar")
> public static Archive<?> createBean1Jar() {
> return ShrinkWrap.create(JavaArchive.class).addClass(Bean1.class).addAsManifestResource(EmptyAsset.INSTANCE, "beans.xml");
> }
> @Deployment(name = "bean2-jar")
> public static Archive<?> createBean2Jar() {
> return ShrinkWrap.create(JavaArchive.class).addClass(Bean2.class).addAsManifestResource(EmptyAsset.INSTANCE, "beans.xml");
> }
> @Test
> @OperateOnDeployment("beans-jar")
> public void singleDeploymentTest() {
> assertNotNull(bean1);
> assertNotNull(bean2);
> }
> }
> {code}
> In both cases, the following exception is thrown:
> {code}
> org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied dependencies for type [Bean2] with qualifiers [@Default] at injection point [[field] @Inject private arquillian.test.OperateOnDeploymentArquilianCdiTest.bean2]
> {code}
> Note that test case 2 is working when only {{@Deployment(name = "beans-jar")}} is declared.
> Test classes and the {{pom.xml}} are attached.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (ARQ-1255) Multiple deployments is not working in Weld SE container
by Antonin Stefanutti (JIRA)
[ https://issues.jboss.org/browse/ARQ-1255?page=com.atlassian.jira.plugin.s... ]
Antonin Stefanutti updated ARQ-1255:
------------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/arquillian/arquillian-container-weld/pull/21
> Multiple deployments is not working in Weld SE container
> --------------------------------------------------------
>
> Key: ARQ-1255
> URL: https://issues.jboss.org/browse/ARQ-1255
> Project: Arquillian
> Issue Type: Bug
> Components: Weld Containers
> Affects Versions: 1.0.0.CR5
> Reporter: Antonin Stefanutti
> Attachments: Bean1.java, Bean2.java, MultipleDeploymentArquilianCdiTest.java, OperateOnDeploymentArquilianCdiTest.java, pom.xml, test_case_1_stacktrace.txt, test_case_2_stacktrace.txt
>
>
> As described in [Multiple Deployments|https://docs.jboss.org/author/display/ARQ/Multiple+Deployments], multiple {{@Deployment}} annotated methods can be declared in a test class. In addition, the {{@OperateOnDeployment}} annotation enables the selection of a particular _deployment_ per test method.
> However, when using Arquillian with a Weld SE container, the CDI container isn't deployed with the expected archives which ends up having {{DeploymentException}} thrown, as illustrated in the test cases below:
> *Test case 1:*
> {code}
> @RunWith(Arquillian.class)
> public class MultipleDeploymentArquilianCdiTest {
> @Inject
> private Bean1 bean1;
> @Inject
> private Bean2 bean2;
> @Deployment(name = "bean1-jar")
> public static Archive<?> createBean1Jar() {
> return ShrinkWrap.create(JavaArchive.class).addClass(Bean1.class).addAsManifestResource(EmptyAsset.INSTANCE, "beans.xml");
> }
> @Deployment(name = "bean2-jar")
> public static Archive<?> createBean2Jar() {
> return ShrinkWrap.create(JavaArchive.class).addClass(Bean2.class).addAsManifestResource(EmptyAsset.INSTANCE, "beans.xml");
> }
> @Test
> public void multiDeploymentTest() {
> assertNotNull(bean1);
> assertNotNull(bean2);
> }
> }
> {code}
> *Test case 2:*
> {code}
> @RunWith(Arquillian.class)
> public class OperateOnDeploymentArquilianCdiTest {
> @Inject
> private Bean1 bean1;
> @Inject
> private Bean2 bean2;
> @Deployment(name = "beans-jar")
> public static Archive<?> createBeansJar() {
> return ShrinkWrap.create(JavaArchive.class).addClass(Bean1.class).addClass(Bean2.class).addAsManifestResource(EmptyAsset.INSTANCE, "beans.xml");
> }
> @Deployment(name = "bean1-jar")
> public static Archive<?> createBean1Jar() {
> return ShrinkWrap.create(JavaArchive.class).addClass(Bean1.class).addAsManifestResource(EmptyAsset.INSTANCE, "beans.xml");
> }
> @Deployment(name = "bean2-jar")
> public static Archive<?> createBean2Jar() {
> return ShrinkWrap.create(JavaArchive.class).addClass(Bean2.class).addAsManifestResource(EmptyAsset.INSTANCE, "beans.xml");
> }
> @Test
> @OperateOnDeployment("beans-jar")
> public void singleDeploymentTest() {
> assertNotNull(bean1);
> assertNotNull(bean2);
> }
> }
> {code}
> In both cases, the following exception is thrown:
> {code}
> org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied dependencies for type [Bean2] with qualifiers [@Default] at injection point [[field] @Inject private arquillian.test.OperateOnDeploymentArquilianCdiTest.bean2]
> {code}
> Note that test case 2 is working when only {{@Deployment(name = "beans-jar")}} is declared.
> Test classes and the {{pom.xml}} are attached.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (ARQ-1940) arquillian-osgi-bundle is not undeployed when executing a test with surefire 2.18
by Grzegorz Grzybek (JIRA)
[ https://issues.jboss.org/browse/ARQ-1940?page=com.atlassian.jira.plugin.s... ]
Grzegorz Grzybek edited comment on ARQ-1940 at 10/22/15 5:24 AM:
-----------------------------------------------------------------
The problem was introduced by [this commit|https://github.com/apache/maven-surefire/commit/4df65165] in maven-surefire-plugin 2.18.
With surefire 2.17, we had {{org.jboss.arquillian.junit.Arquillian}} object created once, when runners were created using this invocation trace:
{noformat}
"main@1" prio=5 tid=0x1 nid=NA runnable
java.lang.Thread.State: RUNNABLE
at org.jboss.arquillian.junit.Arquillian.<init>(Arquillian.java:50)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(NativeConstructorAccessorImpl.java:-1)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:422)
at org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:104)
at org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:86)
at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59)
at org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:26)
at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59)
at org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:33)
- locked <0x2b5> (a java.lang.Object)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:262)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
{noformat}
However mave-surefire 2.18 added:
{code:java}
runNotifier.fireTestRunStarted( createTestsDescription() );
{code}
invocation before tests are started. And this leads to double creation of Arquillian runner.
1st:
{noformat}
"main@1" prio=5 tid=0x1 nid=NA runnable
java.lang.Thread.State: RUNNABLE
at org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:25)
at org.junit.runner.Computer.getRunner(Computer.java:40)
at org.junit.runner.Computer$1.runnerForClass(Computer.java:31)
at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59)
at org.junit.runners.model.RunnerBuilder.runners(RunnerBuilder.java:101)
at org.junit.runners.model.RunnerBuilder.runners(RunnerBuilder.java:87)
at org.junit.runners.Suite.<init>(Suite.java:81)
at org.junit.runner.Computer.getSuite(Computer.java:28)
at org.junit.runner.Request.classes(Request.java:75)
at org.junit.runner.Request.classes(Request.java:91)
at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.apache.maven.surefire.common.junit4.JUnit4Reflector.createRequest(JUnit4Reflector.java:67)
at org.apache.maven.surefire.common.junit4.JUnit4ProviderUtil.createSuiteDescription(JUnit4ProviderUtil.java:111)
at org.apache.maven.surefire.junit4.JUnit4Provider.createTestsDescription(JUnit4Provider.java:328)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:166)
at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:286)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:240)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
{noformat}
2nd:
{noformat}
"main@1" prio=5 tid=0x1 nid=NA runnable
java.lang.Thread.State: RUNNABLE
at org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:25)
at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59)
at org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:33)
- locked <0x3ab> (a java.lang.Object)
at org.junit.internal.requests.FilterRequest.getRunner(FilterRequest.java:36)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:341)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:269)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:240)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:184)
at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:286)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:240)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
{noformat}
So in surefire 2.18, {{org.jboss.arquillian.junit.State#runnerStarted()}} is called twice and at the end we have no "Suite finished" event.
(IMO this is rather bug in surefire, than in ARQ)
was (Author: grgrzybek):
The problem was introduced by [this commit|https://github.com/apache/maven-surefire/commit/4df65165] in maven-surefire-plugin 2.18.
With surefire 2.17, we had {{org.jboss.arquillian.junit.Arquillian}} object created once, when runners were created using this invocation trace:
{noformat}
"main@1" prio=5 tid=0x1 nid=NA runnable
java.lang.Thread.State: RUNNABLE
at org.jboss.arquillian.junit.Arquillian.<init>(Arquillian.java:50)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(NativeConstructorAccessorImpl.java:-1)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:422)
at org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:104)
at org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:86)
at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59)
at org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:26)
at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59)
at org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:33)
- locked <0x2b5> (a java.lang.Object)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:262)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
{noformat}
However mave-surefire 2.18 added:
{code:java}
runNotifier.fireTestRunStarted( createTestsDescription() );
{code}
invocation before tests are started. And this leads to double creation of Arquillian runner.
1st:
{noformat}
"main@1" prio=5 tid=0x1 nid=NA runnable
java.lang.Thread.State: RUNNABLE
at org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:25)
at org.junit.runner.Computer.getRunner(Computer.java:40)
at org.junit.runner.Computer$1.runnerForClass(Computer.java:31)
at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59)
at org.junit.runners.model.RunnerBuilder.runners(RunnerBuilder.java:101)
at org.junit.runners.model.RunnerBuilder.runners(RunnerBuilder.java:87)
at org.junit.runners.Suite.<init>(Suite.java:81)
at org.junit.runner.Computer.getSuite(Computer.java:28)
at org.junit.runner.Request.classes(Request.java:75)
at org.junit.runner.Request.classes(Request.java:91)
at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.apache.maven.surefire.common.junit4.JUnit4Reflector.createRequest(JUnit4Reflector.java:67)
at org.apache.maven.surefire.common.junit4.JUnit4ProviderUtil.createSuiteDescription(JUnit4ProviderUtil.java:111)
at org.apache.maven.surefire.junit4.JUnit4Provider.createTestsDescription(JUnit4Provider.java:328)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:166)
at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:286)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:240)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
{noformat}
2nd:
{noformat}
"main@1" prio=5 tid=0x1 nid=NA runnable
java.lang.Thread.State: RUNNABLE
at org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:25)
at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59)
at org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:33)
- locked <0x3ab> (a java.lang.Object)
at org.junit.internal.requests.FilterRequest.getRunner(FilterRequest.java:36)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:341)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:269)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:240)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:184)
at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:286)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:240)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
{noformat}
So in surefire 2.18, {{org.jboss.arquillian.junit.State#runnerStarted()}} is called twice and at the end we have no "Suite finished" event.
> arquillian-osgi-bundle is not undeployed when executing a test with surefire 2.18
> ---------------------------------------------------------------------------------
>
> Key: ARQ-1940
> URL: https://issues.jboss.org/browse/ARQ-1940
> Project: Arquillian
> Issue Type: Bug
> Components: OSGi Containers
> Reporter: Tomas Rohovsky
> Priority: Minor
> Attachments: surefire-reproducer.zip
>
>
> arquillian-osgi-bundle is not undeployed when executing a test with surefire-plugin 2.18. It works with older versions of surefire-plugin. A reproducer is attached.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (ARQ-1940) arquillian-osgi-bundle is not undeployed when executing a test with surefire 2.18
by Grzegorz Grzybek (JIRA)
[ https://issues.jboss.org/browse/ARQ-1940?page=com.atlassian.jira.plugin.s... ]
Grzegorz Grzybek edited comment on ARQ-1940 at 10/22/15 5:23 AM:
-----------------------------------------------------------------
The problem was introduced by [this commit|https://github.com/apache/maven-surefire/commit/4df65165] in maven-surefire-plugin 2.18.
With surefire 2.17, we had {{org.jboss.arquillian.junit.Arquillian}} object created once, when runners were created using this invocation trace:
{noformat}
"main@1" prio=5 tid=0x1 nid=NA runnable
java.lang.Thread.State: RUNNABLE
at org.jboss.arquillian.junit.Arquillian.<init>(Arquillian.java:50)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(NativeConstructorAccessorImpl.java:-1)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:422)
at org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:104)
at org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:86)
at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59)
at org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:26)
at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59)
at org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:33)
- locked <0x2b5> (a java.lang.Object)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:262)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
{noformat}
However mave-surefire 2.18 added:
{code:java}
runNotifier.fireTestRunStarted( createTestsDescription() );
{code}
invocation before tests are started. And this leads to double creation of Arquillian runner.
1st:
{noformat}
"main@1" prio=5 tid=0x1 nid=NA runnable
java.lang.Thread.State: RUNNABLE
at org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:25)
at org.junit.runner.Computer.getRunner(Computer.java:40)
at org.junit.runner.Computer$1.runnerForClass(Computer.java:31)
at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59)
at org.junit.runners.model.RunnerBuilder.runners(RunnerBuilder.java:101)
at org.junit.runners.model.RunnerBuilder.runners(RunnerBuilder.java:87)
at org.junit.runners.Suite.<init>(Suite.java:81)
at org.junit.runner.Computer.getSuite(Computer.java:28)
at org.junit.runner.Request.classes(Request.java:75)
at org.junit.runner.Request.classes(Request.java:91)
at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.apache.maven.surefire.common.junit4.JUnit4Reflector.createRequest(JUnit4Reflector.java:67)
at org.apache.maven.surefire.common.junit4.JUnit4ProviderUtil.createSuiteDescription(JUnit4ProviderUtil.java:111)
at org.apache.maven.surefire.junit4.JUnit4Provider.createTestsDescription(JUnit4Provider.java:328)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:166)
at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:286)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:240)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
{noformat}
2nd:
{noformat}
"main@1" prio=5 tid=0x1 nid=NA runnable
java.lang.Thread.State: RUNNABLE
at org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:25)
at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59)
at org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:33)
- locked <0x3ab> (a java.lang.Object)
at org.junit.internal.requests.FilterRequest.getRunner(FilterRequest.java:36)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:341)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:269)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:240)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:184)
at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:286)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:240)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
{noformat}
So in surefire 2.18, {{org.jboss.arquillian.junit.State#runnerStarted()}} is called twice and at the end we have no "Suite finished" event.
was (Author: grgrzybek):
The problem was introduced by [this commit|https://github.com/apache/maven-surefire/commit/4df65165] in maven-surefire-plugin 2.18.
With surefire 2.17, we had {{org.jboss.arquillian.junit.Arquillian}} object created once, when runners were created using this invocation trace:
{noformat}
"main@1" prio=5 tid=0x1 nid=NA runnable
java.lang.Thread.State: RUNNABLE
at org.jboss.arquillian.junit.Arquillian.<init>(Arquillian.java:50)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(NativeConstructorAccessorImpl.java:-1)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:422)
at org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:104)
at org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:86)
at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59)
at org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:26)
at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59)
at org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:33)
- locked <0x2b5> (a java.lang.Object)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:262)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
{noformat}
However mave-surefire 2.18 added:
{code:java}
runNotifier.fireTestRunStarted( createTestsDescription() );
{code}
invocation before tests are started. And this leads to earler creation of Arquillian runner.
1st:
{noformat}
"main@1" prio=5 tid=0x1 nid=NA runnable
java.lang.Thread.State: RUNNABLE
at org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:25)
at org.junit.runner.Computer.getRunner(Computer.java:40)
at org.junit.runner.Computer$1.runnerForClass(Computer.java:31)
at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59)
at org.junit.runners.model.RunnerBuilder.runners(RunnerBuilder.java:101)
at org.junit.runners.model.RunnerBuilder.runners(RunnerBuilder.java:87)
at org.junit.runners.Suite.<init>(Suite.java:81)
at org.junit.runner.Computer.getSuite(Computer.java:28)
at org.junit.runner.Request.classes(Request.java:75)
at org.junit.runner.Request.classes(Request.java:91)
at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.apache.maven.surefire.common.junit4.JUnit4Reflector.createRequest(JUnit4Reflector.java:67)
at org.apache.maven.surefire.common.junit4.JUnit4ProviderUtil.createSuiteDescription(JUnit4ProviderUtil.java:111)
at org.apache.maven.surefire.junit4.JUnit4Provider.createTestsDescription(JUnit4Provider.java:328)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:166)
at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:286)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:240)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
{noformat}
2nd:
{noformat}
"main@1" prio=5 tid=0x1 nid=NA runnable
java.lang.Thread.State: RUNNABLE
at org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:25)
at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59)
at org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:33)
- locked <0x3ab> (a java.lang.Object)
at org.junit.internal.requests.FilterRequest.getRunner(FilterRequest.java:36)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:341)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:269)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:240)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:184)
at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:286)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:240)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
{noformat}
So in surefire 2.18, {{org.jboss.arquillian.junit.State#runnerStarted()}} is called twice and at the end we have no "Suite finished" event.
> arquillian-osgi-bundle is not undeployed when executing a test with surefire 2.18
> ---------------------------------------------------------------------------------
>
> Key: ARQ-1940
> URL: https://issues.jboss.org/browse/ARQ-1940
> Project: Arquillian
> Issue Type: Bug
> Components: OSGi Containers
> Reporter: Tomas Rohovsky
> Priority: Minor
> Attachments: surefire-reproducer.zip
>
>
> arquillian-osgi-bundle is not undeployed when executing a test with surefire-plugin 2.18. It works with older versions of surefire-plugin. A reproducer is attached.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (ARQ-1940) arquillian-osgi-bundle is not undeployed when executing a test with surefire 2.18
by Grzegorz Grzybek (JIRA)
[ https://issues.jboss.org/browse/ARQ-1940?page=com.atlassian.jira.plugin.s... ]
Grzegorz Grzybek commented on ARQ-1940:
---------------------------------------
The problem was introduced by [this commit|https://github.com/apache/maven-surefire/commit/4df65165] in maven-surefire-plugin 2.18.
With surefire 2.17, we had {{org.jboss.arquillian.junit.Arquillian}} object created once, when runners were created using this invocation trace:
{noformat}
"main@1" prio=5 tid=0x1 nid=NA runnable
java.lang.Thread.State: RUNNABLE
at org.jboss.arquillian.junit.Arquillian.<init>(Arquillian.java:50)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(NativeConstructorAccessorImpl.java:-1)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:422)
at org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:104)
at org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:86)
at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59)
at org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:26)
at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59)
at org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:33)
- locked <0x2b5> (a java.lang.Object)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:262)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
{noformat}
However mave-surefire 2.18 added:
{code:java}
runNotifier.fireTestRunStarted( createTestsDescription() );
{code}
invocation before tests are started. And this leads to earler creation of Arquillian runner.
1st:
{noformat}
"main@1" prio=5 tid=0x1 nid=NA runnable
java.lang.Thread.State: RUNNABLE
at org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:25)
at org.junit.runner.Computer.getRunner(Computer.java:40)
at org.junit.runner.Computer$1.runnerForClass(Computer.java:31)
at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59)
at org.junit.runners.model.RunnerBuilder.runners(RunnerBuilder.java:101)
at org.junit.runners.model.RunnerBuilder.runners(RunnerBuilder.java:87)
at org.junit.runners.Suite.<init>(Suite.java:81)
at org.junit.runner.Computer.getSuite(Computer.java:28)
at org.junit.runner.Request.classes(Request.java:75)
at org.junit.runner.Request.classes(Request.java:91)
at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.apache.maven.surefire.common.junit4.JUnit4Reflector.createRequest(JUnit4Reflector.java:67)
at org.apache.maven.surefire.common.junit4.JUnit4ProviderUtil.createSuiteDescription(JUnit4ProviderUtil.java:111)
at org.apache.maven.surefire.junit4.JUnit4Provider.createTestsDescription(JUnit4Provider.java:328)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:166)
at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:286)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:240)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
{noformat}
2nd:
{noformat}
"main@1" prio=5 tid=0x1 nid=NA runnable
java.lang.Thread.State: RUNNABLE
at org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:25)
at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59)
at org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:33)
- locked <0x3ab> (a java.lang.Object)
at org.junit.internal.requests.FilterRequest.getRunner(FilterRequest.java:36)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:341)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:269)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:240)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:184)
at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:286)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:240)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
{noformat}
So in surefire 2.18, {{org.jboss.arquillian.junit.State#runnerStarted()}} is called twice and at the end we have no "Suite finished" event.
> arquillian-osgi-bundle is not undeployed when executing a test with surefire 2.18
> ---------------------------------------------------------------------------------
>
> Key: ARQ-1940
> URL: https://issues.jboss.org/browse/ARQ-1940
> Project: Arquillian
> Issue Type: Bug
> Components: OSGi Containers
> Reporter: Tomas Rohovsky
> Priority: Minor
> Attachments: surefire-reproducer.zip
>
>
> arquillian-osgi-bundle is not undeployed when executing a test with surefire-plugin 2.18. It works with older versions of surefire-plugin. A reproducer is attached.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (ARQGRA-480) Screenshooter - When "takeOnEveryAction" is activated then "takeBeforeTest" seems to be activated as well
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/ARQGRA-480?page=com.atlassian.jira.plugin... ]
Lukáš Fryč updated ARQGRA-480:
------------------------------
Fix Version/s: 2.1.0.Alpha3
(was: 2.1-Tracking)
> Screenshooter - When "takeOnEveryAction" is activated then "takeBeforeTest" seems to be activated as well
> ---------------------------------------------------------------------------------------------------------
>
> Key: ARQGRA-480
> URL: https://issues.jboss.org/browse/ARQGRA-480
> Project: Arquillian Graphene
> Issue Type: Bug
> Components: screenshooter
> Affects Versions: 2.1.0.Alpha2
> Reporter: Matous Jobanek
> Assignee: Matous Jobanek
> Fix For: 2.1.0.Alpha3
>
>
> Consider this scenario:
> Arquillian.xml contains:
> {code:xml}
> <extension qualifier="screenshooter">
> <property name="takeOnEveryAction">true</property>
> <property name="takeBeforeTest">false</property>
> <property name="takeAfterTest">false</property>
> <property name="takeWhenTestFailed">false</property>
> </extension>
> {code}
> Then, when the test starts this output is written there in the console log:
> {noformat}
> Configuration of Arquillian Browser Screenshooter:
> rootDir target/screenshots
> screenshotType PNG
> takeBeforeTest true
> takeAfterTest false
> takeWhenTestFailed false
> takeOnEveryAction true
> {noformat}
> There is written {{takeBeforeTest true}} which can be confusing, because it is not activated there in the arquillian.xml. This output should reflect what is set there.
> The second thing is that the {{_before}} screenshot is taken when takeOnEveryAction is activated. However, neither {{_after}} nor {{_failed}} is taken. This is confusing as well - I would expect some consistency. I'm suggesting two options how to solve this:
> 1) take screenshots only on every interaction with the WebDriver object (as it is written in the [README|https://github.com/MatousJobanek/arquillian-graphene/tree/ARQ-1979...]) - this means not taking screenshots during the before phase
> 2) take screenshots on every action at all - this means not only on every interaction with the WebDriver but also during before, after and when the test fails
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months