October 2014 - arquillian-issues - Jboss List Archives

[JBoss JIRA] (ARQ-1862) Scalatest TestRunner

by Aslak Knutsen (JIRA)

[ https://issues.jboss.org/browse/ARQ-1862?page=com.atlassian.jira.plugin.s... ] Aslak Knutsen edited comment on ARQ-1862 at 10/8/14 3:30 AM: ------------------------------------------------------------- [~giovannicandido] In the Spock example that is actually handled by the Interceptor, not the Runner; https://github.com/arquillian/arquillian-testrunner-spock/blob/master/cor... Similar in plane JUnit Arquillian; https://github.com/arquillian/arquillian-core/blob/master/junit/core/src/... https://github.com/arquillian/arquillian-core/blob/master/junit/core/src/... https://github.com/arquillian/arquillian-core/blob/master/junit/core/src/... https://github.com/arquillian/arquillian-core/blob/master/junit/core/src/... https://github.com/arquillian/arquillian-core/blob/master/junit/core/src/... was (Author: aslak): [~giovannicandido]In the Spock example that is actually handled by the Interceptor, not the Runner; https://github.com/arquillian/arquillian-testrunner-spock/blob/master/cor... Similar in plane JUnit Arquillian; https://github.com/arquillian/arquillian-core/blob/master/junit/core/src/... https://github.com/arquillian/arquillian-core/blob/master/junit/core/src/... https://github.com/arquillian/arquillian-core/blob/master/junit/core/src/... https://github.com/arquillian/arquillian-core/blob/master/junit/core/src/... https://github.com/arquillian/arquillian-core/blob/master/junit/core/src/... > Scalatest TestRunner > -------------------- > > Key: ARQ-1862 > URL: https://issues.jboss.org/browse/ARQ-1862 > Project: Arquillian > Issue Type: Feature Request > Reporter: Giovanni Silva > > Hi, > Would be great to have a Arquillian runner in the same way of JUnitRunner (to run with Junit but with startup of Arquillian) or as native scalatest integration, not using Junit. > Arquillian is great to test Context and Dependency Injections and Java EE components. > Current is possible to run arquillian using the JUnitRunner but it only start in Junit test cases. > This run the FlatSpec test with JUnit, but do not bootstrap arquillian: > {code} > @RunWith(classOf[JUnitRunner]) > class MySimpleBeamTestScala extends FlatSpec with Matchers { > @Inject > private var mysimplebeam: MySimpleBeam = _ > "A simple bean" should "return hello world" in { > mysimplebeam.helloWorld() should be("Hello World") > } > @Test def testIsDeployed { > mysimplebeam.helloWorld() should be("Hell World") > } > } > object MySimpleBeamTestScala { > @Deployment > def createDeployment() = { > println("working") > ShrinkWrap.create(classOf[JavaArchive], "test.jar").addClass(classOf[MySimpleBeam]).addAsManifestResource(EmptyAsset.INSTANCE, "beans.xml") > } > } > {code} > This run the test with TestNG and bootstrap arquillian, but can't use other format spec > {code} > import javax.inject.Inject > import org.jboss.arquillian.container.test.api.Deployment > import org.jboss.arquillian.testng.Arquillian > import org.jboss.shrinkwrap.api.ShrinkWrap > import org.jboss.shrinkwrap.api.asset.EmptyAsset > import org.jboss.shrinkwrap.api.spec.JavaArchive > import org.scalatest._ > import org.testng.annotations.Test > /** > * @author Giovanni Silva > */ > class MySimpleBeamTestScala extends Arquillian with FlatSpecLike with Matchers { > @Inject > private var mysimplebeam: MySimpleBeam = _ > "A simple bean" should "return hello world" in { > mysimplebeam.helloWorld() should be("Hello World") > } > @Test def testIsDeployed { > mysimplebeam.helloWorld() should be("Hell World") > } > } > object MySimpleBeamTestScala { > @Deployment > def createDeployment() = { > println("working") > ShrinkWrap.create(classOf[JavaArchive], "test.jar").addClass(classOf[MySimpleBeam]).addAsManifestResource(EmptyAsset.INSTANCE, "beans.xml") > } > } > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1862) Scalatest TestRunner

by Aslak Knutsen (JIRA)

[ https://issues.jboss.org/browse/ARQ-1862?page=com.atlassian.jira.plugin.s... ] Aslak Knutsen commented on ARQ-1862: ------------------------------------ [~giovannicandido]In the Spock example that is actually handled by the Interceptor, not the Runner; https://github.com/arquillian/arquillian-testrunner-spock/blob/master/cor... Similar in plane JUnit Arquillian; https://github.com/arquillian/arquillian-core/blob/master/junit/core/src/... https://github.com/arquillian/arquillian-core/blob/master/junit/core/src/... https://github.com/arquillian/arquillian-core/blob/master/junit/core/src/... https://github.com/arquillian/arquillian-core/blob/master/junit/core/src/... https://github.com/arquillian/arquillian-core/blob/master/junit/core/src/... > Scalatest TestRunner > -------------------- > > Key: ARQ-1862 > URL: https://issues.jboss.org/browse/ARQ-1862 > Project: Arquillian > Issue Type: Feature Request > Reporter: Giovanni Silva > > Hi, > Would be great to have a Arquillian runner in the same way of JUnitRunner (to run with Junit but with startup of Arquillian) or as native scalatest integration, not using Junit. > Arquillian is great to test Context and Dependency Injections and Java EE components. > Current is possible to run arquillian using the JUnitRunner but it only start in Junit test cases. > This run the FlatSpec test with JUnit, but do not bootstrap arquillian: > {code} > @RunWith(classOf[JUnitRunner]) > class MySimpleBeamTestScala extends FlatSpec with Matchers { > @Inject > private var mysimplebeam: MySimpleBeam = _ > "A simple bean" should "return hello world" in { > mysimplebeam.helloWorld() should be("Hello World") > } > @Test def testIsDeployed { > mysimplebeam.helloWorld() should be("Hell World") > } > } > object MySimpleBeamTestScala { > @Deployment > def createDeployment() = { > println("working") > ShrinkWrap.create(classOf[JavaArchive], "test.jar").addClass(classOf[MySimpleBeam]).addAsManifestResource(EmptyAsset.INSTANCE, "beans.xml") > } > } > {code} > This run the test with TestNG and bootstrap arquillian, but can't use other format spec > {code} > import javax.inject.Inject > import org.jboss.arquillian.container.test.api.Deployment > import org.jboss.arquillian.testng.Arquillian > import org.jboss.shrinkwrap.api.ShrinkWrap > import org.jboss.shrinkwrap.api.asset.EmptyAsset > import org.jboss.shrinkwrap.api.spec.JavaArchive > import org.scalatest._ > import org.testng.annotations.Test > /** > * @author Giovanni Silva > */ > class MySimpleBeamTestScala extends Arquillian with FlatSpecLike with Matchers { > @Inject > private var mysimplebeam: MySimpleBeam = _ > "A simple bean" should "return hello world" in { > mysimplebeam.helloWorld() should be("Hello World") > } > @Test def testIsDeployed { > mysimplebeam.helloWorld() should be("Hell World") > } > } > object MySimpleBeamTestScala { > @Deployment > def createDeployment() = { > println("working") > ShrinkWrap.create(classOf[JavaArchive], "test.jar").addClass(classOf[MySimpleBeam]).addAsManifestResource(EmptyAsset.INSTANCE, "beans.xml") > } > } > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ARQGRA-463) JavaScript resource loader should use JavaScript.class.getClassLoader()

by Lukáš Fryč (JIRA)

Lukáš Fryč created ARQGRA-463: --------------------------------- Summary: JavaScript resource loader should use JavaScript.class.getClassLoader() Key: ARQGRA-463 URL: https://issues.jboss.org/browse/ARQGRA-463 Project: Arquillian Graphene Issue Type: Enhancement Affects Versions: 2.1.0.Alpha1, 2.0.3.Final Reporter: Lukáš Fryč It uses ClassLoader.getSystemResourceAsStream(resourceName); -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1868) JVM waits for Spacelift's cached threads to timeout causing its termination delay

by Stefan Miklosovic (JIRA)

Stefan Miklosovic created ARQ-1868: -------------------------------------- Summary: JVM waits for Spacelift's cached threads to timeout causing its termination delay Key: ARQ-1868 URL: https://issues.jboss.org/browse/ARQ-1868 Project: Arquillian Issue Type: Bug Components: Extension - Spacelift Affects Versions: spacelift_1.0.0.Alpha2 Reporter: Stefan Miklosovic In the current implementation of ExecutorService there is this constructor:; {code} public ExecutionServiceImpl() { this.service = Executors.newCachedThreadPool(); this.scheduledService = Executors.newScheduledThreadPool(1); } {code} JavaDoc for cachedThreadPool says: {quote} Threads that have not been used for sixty seconds are terminated and removed from the cache. Thus, a pool that remains idle for long enough will not consume any resources. {quote} While this is indeed useful, it seems that even JVM has nothing to do, it waits for these cached threads to timeout (so they are not used some time (60 seconds by default) so they are destroyed eventually) and only after their destruction whole JVM terminates properly. Please consider to lower the timeout so user does not have to wait or figure out other pooling mechanism. This issue effects mainly command line tools which hangs without obvious reason and debugging it why is a nightmare. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1868) JVM waits for Spacelift's cached threads to timeout causing its termination delay

by Stefan Miklosovic (JIRA)

[ https://issues.jboss.org/browse/ARQ-1868?page=com.atlassian.jira.plugin.s... ] Stefan Miklosovic updated ARQ-1868: ----------------------------------- Assignee: Karel Piwko > JVM waits for Spacelift's cached threads to timeout causing its termination delay > --------------------------------------------------------------------------------- > > Key: ARQ-1868 > URL: https://issues.jboss.org/browse/ARQ-1868 > Project: Arquillian > Issue Type: Bug > Components: Extension - Spacelift > Affects Versions: spacelift_1.0.0.Alpha2 > Reporter: Stefan Miklosovic > Assignee: Karel Piwko > > In the current implementation of ExecutorService there is this constructor:; > {code} > public ExecutionServiceImpl() { > this.service = Executors.newCachedThreadPool(); > this.scheduledService = Executors.newScheduledThreadPool(1); > } > {code} > JavaDoc for cachedThreadPool says: > {quote} > Threads that have not been used for sixty seconds are terminated and removed from the cache. Thus, a pool that remains idle for long enough will not consume any resources. > {quote} > While this is indeed useful, it seems that even JVM has nothing to do, it waits for these cached threads to timeout (so they are not used some time (60 seconds by default) so they are destroyed eventually) and only after their destruction whole JVM terminates properly. > Please consider to lower the timeout so user does not have to wait or figure out other pooling mechanism. > This issue effects mainly command line tools which hangs without obvious reason and debugging it why is a nightmare. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1867) Recognize Spacelift threads from all others regarding of a thread name

by Stefan Miklosovic (JIRA)

[ https://issues.jboss.org/browse/ARQ-1867?page=com.atlassian.jira.plugin.s... ] Stefan Miklosovic updated ARQ-1867: ----------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/arquillian/arquillian-spacelift/pull/18 > Recognize Spacelift threads from all others regarding of a thread name > ---------------------------------------------------------------------- > > Key: ARQ-1867 > URL: https://issues.jboss.org/browse/ARQ-1867 > Project: Arquillian > Issue Type: Feature Request > Components: Extension - Spacelift > Affects Versions: spacelift_1.0.0.Alpha2 > Reporter: Stefan Miklosovic > > It is hard to distinguish between Spacelift threads and all other threads in the system. > ExecutorServiceImpl creates executor services via Executors.newCachedThreadPool and Executors.newScheduledThreadPool(1) which are naming threads like "pool-1-thread-_number" and it is hard to make a difference what is Spacelift related and what is not in tools like jvisualvm or jconsole. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1867) Recognize Spacelift threads from all others regarding of a thread name

by Stefan Miklosovic (JIRA)

[ https://issues.jboss.org/browse/ARQ-1867?page=com.atlassian.jira.plugin.s... ] Stefan Miklosovic reassigned ARQ-1867: -------------------------------------- Assignee: Stefan Miklosovic > Recognize Spacelift threads from all others regarding of a thread name > ---------------------------------------------------------------------- > > Key: ARQ-1867 > URL: https://issues.jboss.org/browse/ARQ-1867 > Project: Arquillian > Issue Type: Feature Request > Components: Extension - Spacelift > Affects Versions: spacelift_1.0.0.Alpha2 > Reporter: Stefan Miklosovic > Assignee: Stefan Miklosovic > > It is hard to distinguish between Spacelift threads and all other threads in the system. > ExecutorServiceImpl creates executor services via Executors.newCachedThreadPool and Executors.newScheduledThreadPool(1) which are naming threads like "pool-1-thread-_number" and it is hard to make a difference what is Spacelift related and what is not in tools like jvisualvm or jconsole. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1867) Recognize Spacelift threads from all others regarding of a thread name

by Stefan Miklosovic (JIRA)

Stefan Miklosovic created ARQ-1867: -------------------------------------- Summary: Recognize Spacelift threads from all others regarding of a thread name Key: ARQ-1867 URL: https://issues.jboss.org/browse/ARQ-1867 Project: Arquillian Issue Type: Feature Request Components: Extension - Spacelift Affects Versions: spacelift_1.0.0.Alpha2 Reporter: Stefan Miklosovic It is hard to distinguish between Spacelift threads and all other threads in the system. ExecutorServiceImpl creates executor services via Executors.newCachedThreadPool and Executors.newScheduledThreadPool(1) which are naming threads like "pool-1-thread-_number" and it is hard to make a difference what is Spacelift related and what is not in tools like jvisualvm or jconsole. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1862) Scalatest TestRunner

by Giovanni Silva (JIRA)

[ https://issues.jboss.org/browse/ARQ-1862?page=com.atlassian.jira.plugin.s... ] Giovanni Silva commented on ARQ-1862: ------------------------------------- I Will investigate. The basically idea is startup aquillian before the test suite and shutdown after. But I don't understand how the test run in the context of the container,with injection and other services. > Scalatest TestRunner > -------------------- > > Key: ARQ-1862 > URL: https://issues.jboss.org/browse/ARQ-1862 > Project: Arquillian > Issue Type: Feature Request > Reporter: Giovanni Silva > > Hi, > Would be great to have a Arquillian runner in the same way of JUnitRunner (to run with Junit but with startup of Arquillian) or as native scalatest integration, not using Junit. > Arquillian is great to test Context and Dependency Injections and Java EE components. > Current is possible to run arquillian using the JUnitRunner but it only start in Junit test cases. > This run the FlatSpec test with JUnit, but do not bootstrap arquillian: > {code} > @RunWith(classOf[JUnitRunner]) > class MySimpleBeamTestScala extends FlatSpec with Matchers { > @Inject > private var mysimplebeam: MySimpleBeam = _ > "A simple bean" should "return hello world" in { > mysimplebeam.helloWorld() should be("Hello World") > } > @Test def testIsDeployed { > mysimplebeam.helloWorld() should be("Hell World") > } > } > object MySimpleBeamTestScala { > @Deployment > def createDeployment() = { > println("working") > ShrinkWrap.create(classOf[JavaArchive], "test.jar").addClass(classOf[MySimpleBeam]).addAsManifestResource(EmptyAsset.INSTANCE, "beans.xml") > } > } > {code} > This run the test with TestNG and bootstrap arquillian, but can't use other format spec > {code} > import javax.inject.Inject > import org.jboss.arquillian.container.test.api.Deployment > import org.jboss.arquillian.testng.Arquillian > import org.jboss.shrinkwrap.api.ShrinkWrap > import org.jboss.shrinkwrap.api.asset.EmptyAsset > import org.jboss.shrinkwrap.api.spec.JavaArchive > import org.scalatest._ > import org.testng.annotations.Test > /** > * @author Giovanni Silva > */ > class MySimpleBeamTestScala extends Arquillian with FlatSpecLike with Matchers { > @Inject > private var mysimplebeam: MySimpleBeam = _ > "A simple bean" should "return hello world" in { > mysimplebeam.helloWorld() should be("Hello World") > } > @Test def testIsDeployed { > mysimplebeam.helloWorld() should be("Hell World") > } > } > object MySimpleBeamTestScala { > @Deployment > def createDeployment() = { > println("working") > ShrinkWrap.create(classOf[JavaArchive], "test.jar").addClass(classOf[MySimpleBeam]).addAsManifestResource(EmptyAsset.INSTANCE, "beans.xml") > } > } > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1865) Undeploy arquillian bundle after the test suite in JMXDeployableContainer

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/ARQ-1865?page=com.atlassian.jira.plugin.s... ] Thomas Diesler reassigned ARQ-1865: ----------------------------------- Assignee: (was: Thomas Diesler) Martin is taking care of this > Undeploy arquillian bundle after the test suite in JMXDeployableContainer > ------------------------------------------------------------------------- > > Key: ARQ-1865 > URL: https://issues.jboss.org/browse/ARQ-1865 > Project: Arquillian > Issue Type: Bug > Components: OSGi Containers > Reporter: Martin Basovnik > > Undeploy arquillian bundle after the test suite in JMXDeployableContainer -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 2 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

arquillian-issues October 2014