From issues at jboss.org  Wed Oct  1 13:52:03 2014
From: issues at jboss.org (Aslak Knutsen (JIRA))
Date: Wed, 1 Oct 2014 13:52:03 -0400 (EDT)
Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1861) ContainerDeployer
 should be running commands in a privileged context
In-Reply-To: <JIRA.12553806.1412130399000@Atlassian.JIRA>
References: <JIRA.12553806.1412130399000@Atlassian.JIRA>
	<JIRA.12553806.1412130399000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12553806.1412130399000.41622.1412185923410@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ARQ-1861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Aslak Knutsen updated ARQ-1861:
-------------------------------
           Status: Resolved  (was: Pull Request Sent)
    Fix Version/s: 1.1.6.Final
       Resolution: Done


> ContainerDeployer should be running commands in a privileged context
> --------------------------------------------------------------------
>
>                 Key: ARQ-1861
>                 URL: https://issues.jboss.org/browse/ARQ-1861
>             Project: Arquillian
>          Issue Type: Bug
>    Affects Versions: 1.1.2.Final
>            Reporter: David Lloyd
>             Fix For: 1.1.6.Final
>
>
> The ContainerDeployer should run commands in a privileged context, because the deployment (which is typically unprivileged) may be on the call stack.



--
This message was sent by Atlassian JIRA
(v6.3.1#6329)

From issues at jboss.org  Wed Oct  1 13:52:03 2014
From: issues at jboss.org (Aslak Knutsen (JIRA))
Date: Wed, 1 Oct 2014 13:52:03 -0400 (EDT)
Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1859) Arquillian
 SecurityActions fail under actual security manager
In-Reply-To: <JIRA.12553495.1411763968000@Atlassian.JIRA>
References: <JIRA.12553495.1411763968000@Atlassian.JIRA>
	<JIRA.12553495.1411763968000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12553495.1411763968000.41623.1412185923526@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ARQ-1859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Aslak Knutsen updated ARQ-1859:
-------------------------------
           Status: Resolved  (was: Pull Request Sent)
    Fix Version/s: 1.1.6.Final
       Resolution: Done


> Arquillian SecurityActions fail under actual security manager
> -------------------------------------------------------------
>
>                 Key: ARQ-1859
>                 URL: https://issues.jboss.org/browse/ARQ-1859
>             Project: Arquillian
>          Issue Type: Bug
>          Components: Base Implementation
>    Affects Versions: 1.1.2.Final
>            Reporter: David Lloyd
>            Priority: Critical
>             Fix For: 1.1.6.Final
>
>
> The {{org.jboss.arquillian.core.impl.loadable.SecurityActions#newInstance(java.lang.Class<T>, java.lang.Class<?>[], java.lang.Object[])}} method takes extra care to reflectively acquire an object constructor in a privileged block.  However, it then calls setAccessible(true) outside of a privileged block, rendering previous efforts useless and causing execution failures.  The fix is to move that statement to within the privileged block as well.



--
This message was sent by Atlassian JIRA
(v6.3.1#6329)

From issues at jboss.org  Thu Oct  2 04:58:02 2014
From: issues at jboss.org (Alexandr Sokolov (JIRA))
Date: Thu, 2 Oct 2014 04:58:02 -0400 (EDT)
Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1842) Show original exception
 instead of NullPointerExcetpion from TransactionHandler
In-Reply-To: <JIRA.12549797.1408593191000@Atlassian.JIRA>
References: <JIRA.12549797.1408593191000@Atlassian.JIRA>
	<JIRA.12549797.1408593191000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12549797.1408593191000.42827.1412240282773@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ARQ-1842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13007983#comment-13007983 ] 

Alexandr Sokolov commented on ARQ-1842:
---------------------------------------

@Aslak Knutsen:
Could you please where can we find the last 2.0.0.CR1 version? Is there any maven repository to download it from?


> Show original exception instead of NullPointerExcetpion from TransactionHandler
> -------------------------------------------------------------------------------
>
>                 Key: ARQ-1842
>                 URL: https://issues.jboss.org/browse/ARQ-1842
>             Project: Arquillian
>          Issue Type: Sub-task
>          Components: Base Implementation
>            Reporter: Alexandr Sokolov
>             Fix For: 2.0.0.CR1
>
>
> Arquillan architecture based on observers. But now, if one of observers throws an exception and transactions are used. We are getting:
>  
> java.lang.NullPointerException: null
>   at org.jboss.arquillian.transaction.impl.lifecycle.TransactionHandler.testRequiresRollbackDueToFailure(TransactionHandler.java:170)
>  
> Although the actual exception in my case was thrown by DBUnitDataHandler.prepare().
>  
> Could you please change the logic so the original exception is displayed in the output? Otherwise we have to debug to get the actual exception. There is no way to find a solution without debugging via arquillian classes. It really takes rather long time.
> Full exception log:
> {code}
> java.lang.NullPointerException: null
> 	at org.jboss.arquillian.transaction.impl.lifecycle.TransactionHandler.testRequiresRollbackDueToFailure(TransactionHandler.java:170)
> 	at org.jboss.arquillian.transaction.impl.lifecycle.TransactionHandler.rollbackRequired(TransactionHandler.java:159)
> 	at org.jboss.arquillian.transaction.impl.lifecycle.TransactionHandler.endTransaction(TransactionHandler.java:123)
> 	at org.jboss.arquillian.transaction.impl.lifecycle.TransactionHandler.endTransactionAfterTest(TransactionHandler.java:102)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:606)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.testenricher.cdi.CreationalContextDestroyer.destory(CreationalContextDestroyer.java:44)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:606)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:102)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:606)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:84)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:606)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:65)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:606)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> 	at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.after(EventTestRunnerAdaptor.java:103)
> 	at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:277)
> 	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> 	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> 	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> 	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> 	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> 	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> 	at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:193)
> 	at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:345)
> 	at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:49)
> 	at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:207)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> 	at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:155)
> 	at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
> 	at org.junit.runner.JUnitCore.run(JUnitCore.java:138)
> 	at org.jboss.arquillian.junit.container.JUnitTestRunner.execute(JUnitTestRunner.java:66)
> 	at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.executeTest(ServletTestRunner.java:159)
> 	at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.execute(ServletTestRunner.java:125)
> 	at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.doGet(ServletTestRunner.java:89)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:734)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
> 	at org.jboss.weld.servlet.ConversationPropagationFilter.doFilter(ConversationPropagationFilter.java:62)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161)
> 	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:397)
> 	at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50)
> 	at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:165)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:372)
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877)
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:679)
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:931)
> 	at java.lang.Thread.run(Thread.java:744)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.1#6329)

From issues at jboss.org  Fri Oct  3 11:50:12 2014
From: issues at jboss.org (Giovanni Silva (JIRA))
Date: Fri, 3 Oct 2014 11:50:12 -0400 (EDT)
Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1862) Scalatest TestRunner
In-Reply-To: <JIRA.12554169.1412351372000@Atlassian.JIRA>
References: <JIRA.12554169.1412351372000@Atlassian.JIRA>
	<JIRA.12554169.1412351372717@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12554169.1412351372000.1147.1412351412073@Atlassian.JIRA>

Giovanni Silva created ARQ-1862:
-----------------------------------

             Summary: 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)

From issues at jboss.org  Sat Oct  4 06:34:11 2014
From: issues at jboss.org (Alex Soto (JIRA))
Date: Sat, 4 Oct 2014 06:34:11 -0400 (EDT)
Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1863) Update Spacelift
 Arquillian dependency version to 1.1.5.Final
In-Reply-To: <JIRA.12554194.1412418803000@Atlassian.JIRA>
References: <JIRA.12554194.1412418803000@Atlassian.JIRA>
	<JIRA.12554194.1412418803716@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12554194.1412418803000.1808.1412418851421@Atlassian.JIRA>

Alex Soto created ARQ-1863:
------------------------------

             Summary: Update Spacelift Arquillian dependency version to 1.1.5.Final
                 Key: ARQ-1863
                 URL: https://issues.jboss.org/browse/ARQ-1863
             Project: Arquillian
          Issue Type: Enhancement
          Components: Extension - Spacelift
    Affects Versions: 1.0.0.Alpha2
            Reporter: Alex Soto
            Assignee: Alex Soto
            Priority: Minor


Currently Arquillian Spacelift uses Arquillian 1.1.4 as arquillian version but if you run in a 1.1.5, an exception is thrown. This is because both dependencies 1.14 and 1.1.5 coexists and a NoSuchMethodError exception is thrown. To avoid this you can add arquillian pom in dependency management.

<dependency>
            <groupId>org.jboss.arquillian</groupId>
            <artifactId>arquillian-bom</artifactId>
            <version>1.1.5.Final</version>
            <scope>import</scope>
            <type>pom</type>
</dependency>

Related issue https://github.com/arquillian/arquillian-spacelift/issues/13



--
This message was sent by Atlassian JIRA
(v6.3.1#6329)

From issues at jboss.org  Sat Oct  4 07:18:11 2014
From: issues at jboss.org (Alex Soto (JIRA))
Date: Sat, 4 Oct 2014 07:18:11 -0400 (EDT)
Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1864) Change Zip4j in favor
	of commons-compress
In-Reply-To: <JIRA.12554195.1412421448000@Atlassian.JIRA>
References: <JIRA.12554195.1412421448000@Atlassian.JIRA>
	<JIRA.12554195.1412421448512@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12554195.1412421448000.1816.1412421491318@Atlassian.JIRA>

Alex Soto created ARQ-1864:
------------------------------

             Summary: Change Zip4j in favor of commons-compress
                 Key: ARQ-1864
                 URL: https://issues.jboss.org/browse/ARQ-1864
             Project: Arquillian
          Issue Type: Enhancement
          Components: Extension - Spacelift
            Reporter: Alex Soto
            Assignee: Alex Soto


UnZip tool is based on zip4j library. The problem is that sometimes the files are tar, gzip, 7z, or arj. I suggest to change zip4j to commons-compress which supports a lot of compress algorithms in order to be able to write some Tool like UnzipTool, UntarTool and so on and even a generic UnCompressTool which you set the algorithm to be used.

http://search.maven.org/#artifactdetails%7Corg.apache.commons%7Ccommons-compress%7C1.8.1%7Cjar

The good news is that this library is maintained as well (last version released is from May 2014.

Again if you agree I will implement the change.

Note: that I have never found this error because I download zip files but today it is the first time I have found this barrier.

Of course another approach is to use GZipIS but because we are already using zip4j we can drop it and add this library.

Related with https://github.com/arquillian/arquillian-spacelift/issues/15



--
This message was sent by Atlassian JIRA
(v6.3.1#6329)

From issues at jboss.org  Mon Oct  6 07:23:12 2014
From: issues at jboss.org (Aslak Knutsen (JIRA))
Date: Mon, 6 Oct 2014 07:23:12 -0400 (EDT)
Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1862) Scalatest TestRunner
In-Reply-To: <JIRA.12554169.1412351372000@Atlassian.JIRA>
References: <JIRA.12554169.1412351372000@Atlassian.JIRA>
	<JIRA.12554169.1412351372000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12554169.1412351372000.2596.1412594592102@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ARQ-1862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13008779#comment-13008779 ] 

Aslak Knutsen commented on ARQ-1862:
------------------------------------

[~giovannicandido] Would you be interested in investigating this? We had to do something similar with the Spock test runner; https://github.com/arquillian/arquillian-testrunner-spock/blob/master/core/src/main/java/org/jboss/arquillian/spock/ArquillianSputnik.java Basically extend Spock's Spunik driver and reimplement the Arquillian calls in it.

> 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)

From issues at jboss.org  Mon Oct  6 08:00:16 2014
From: issues at jboss.org (Karel Piwko (JIRA))
Date: Mon, 6 Oct 2014 08:00:16 -0400 (EDT)
Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1864) Change Zip4j in favor
	of commons-compress
In-Reply-To: <JIRA.12554195.1412421448000@Atlassian.JIRA>
References: <JIRA.12554195.1412421448000@Atlassian.JIRA>
	<JIRA.12554195.1412421448000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12554195.1412421448000.2642.1412596816176@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ARQ-1864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13008791#comment-13008791 ] 

Karel Piwko commented on ARQ-1864:
----------------------------------

+1, this is very good idea.

> Change Zip4j in favor of commons-compress
> -----------------------------------------
>
>                 Key: ARQ-1864
>                 URL: https://issues.jboss.org/browse/ARQ-1864
>             Project: Arquillian
>          Issue Type: Enhancement
>          Components: Extension - Spacelift
>            Reporter: Alex Soto
>            Assignee: Alex Soto
>
> UnZip tool is based on zip4j library. The problem is that sometimes the files are tar, gzip, 7z, or arj. I suggest to change zip4j to commons-compress which supports a lot of compress algorithms in order to be able to write some Tool like UnzipTool, UntarTool and so on and even a generic UnCompressTool which you set the algorithm to be used.
> http://search.maven.org/#artifactdetails%7Corg.apache.commons%7Ccommons-compress%7C1.8.1%7Cjar
> The good news is that this library is maintained as well (last version released is from May 2014.
> Again if you agree I will implement the change.
> Note: that I have never found this error because I download zip files but today it is the first time I have found this barrier.
> Of course another approach is to use GZipIS but because we are already using zip4j we can drop it and add this library.
> Related with https://github.com/arquillian/arquillian-spacelift/issues/15



--
This message was sent by Atlassian JIRA
(v6.3.1#6329)

From issues at jboss.org  Mon Oct  6 10:02:11 2014
From: issues at jboss.org (Martin Basovnik (JIRA))
Date: Mon, 6 Oct 2014 10:02:11 -0400 (EDT)
Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1865) Undeploy arquillian
 bundle after the test suite in JMXDeployableContainer
In-Reply-To: <JIRA.12554273.1412604104000@Atlassian.JIRA>
References: <JIRA.12554273.1412604104000@Atlassian.JIRA>
	<JIRA.12554273.1412604104508@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12554273.1412604104000.3242.1412604131788@Atlassian.JIRA>

Martin Basovnik created ARQ-1865:
------------------------------------

             Summary: 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
            Assignee: Thomas Diesler


Undeploy arquillian bundle after the test suite in JMXDeployableContainer



--
This message was sent by Atlassian JIRA
(v6.3.1#6329)

From issues at jboss.org  Mon Oct  6 13:57:11 2014
From: issues at jboss.org (Martin Basovnik (JIRA))
Date: Mon, 6 Oct 2014 13:57:11 -0400 (EDT)
Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1865) Undeploy arquillian
 bundle after the test suite in JMXDeployableContainer
In-Reply-To: <JIRA.12554273.1412604104000@Atlassian.JIRA>
References: <JIRA.12554273.1412604104000@Atlassian.JIRA>
	<JIRA.12554273.1412604104000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12554273.1412604104000.4283.1412618231880@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ARQ-1865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Basovnik updated ARQ-1865:
---------------------------------
              Status: Pull Request Sent  (was: Open)
    Git Pull Request: https://github.com/arquillian/arquillian-container-osgi/pull/32


> 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
>            Assignee: Thomas Diesler
>
> Undeploy arquillian bundle after the test suite in JMXDeployableContainer



--
This message was sent by Atlassian JIRA
(v6.3.1#6329)

From issues at jboss.org  Mon Oct  6 13:58:11 2014
From: issues at jboss.org (Martin Basovnik (JIRA))
Date: Mon, 6 Oct 2014 13:58:11 -0400 (EDT)
Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1856) Remove dynamic import
 from arquillian-bundle
In-Reply-To: <JIRA.12553090.1411477331000@Atlassian.JIRA>
References: <JIRA.12553090.1411477331000@Atlassian.JIRA>
	<JIRA.12553090.1411477331000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12553090.1411477331000.4287.1412618291798@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ARQ-1856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Basovnik updated ARQ-1856:
---------------------------------
              Status: Pull Request Sent  (was: Open)
    Git Pull Request: https://github.com/arquillian/arquillian-container-osgi/pull/31


> Remove dynamic import from arquillian-bundle
> --------------------------------------------
>
>                 Key: ARQ-1856
>                 URL: https://issues.jboss.org/browse/ARQ-1856
>             Project: Arquillian
>          Issue Type: Feature Request
>          Components: OSGi Containers
>            Reporter: Thomas Diesler
>            Assignee: Thomas Diesler
>             Fix For: osgi_2.0.0.Final
>
>
> Currently, the arquillian bundle contains a dynamic import "*" which may lead to undesired package wiring. Theoretically, it should possible to embed all required dependencies in the arq-bundle and load the test classes from the test-bundle(s) via Bundle.loadClass(...)



--
This message was sent by Atlassian JIRA
(v6.3.1#6329)

From issues at jboss.org  Mon Oct  6 17:19:11 2014
From: issues at jboss.org (Martin Basovnik (JIRA))
Date: Mon, 6 Oct 2014 17:19:11 -0400 (EDT)
Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1780) Fix parsing of
 import-export packages in class AbstractOSGiApplicationArchiveProcessor
In-Reply-To: <JIRA.12541136.1400510716000@Atlassian.JIRA>
References: <JIRA.12541136.1400510716000@Atlassian.JIRA>
	<JIRA.12541136.1400510716000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12541136.1400510716000.4535.1412630351527@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ARQ-1780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Basovnik updated ARQ-1780:
---------------------------------
        Status: Resolved  (was: Pull Request Sent)
    Resolution: Done


> Fix parsing of import-export packages in class AbstractOSGiApplicationArchiveProcessor
> --------------------------------------------------------------------------------------
>
>                 Key: ARQ-1780
>                 URL: https://issues.jboss.org/browse/ARQ-1780
>             Project: Arquillian
>          Issue Type: Bug
>          Components: OSGi Containers
>            Reporter: Martin Basovnik
>            Assignee: Thomas Diesler
>
> Method {{enhanceApplicationArchive()}} in specified class  cannot parse import packages from file {{MANIFEST.MF}} correctly. Input string must be split only by those commas that are not surrounded by double-quotes.
> Example:
> {{org.jboss.arquillian.junit;version="[X.0.0,Y.0.0)";extra="A,B",org.junit"}}
> must be split as follows:
> {{org.jboss.arquillian.junit;version="[X.0.0,Y.0.0)";extra="A,B"}} and {{org.junit}}



--
This message was sent by Atlassian JIRA
(v6.3.1#6329)

From issues at jboss.org  Mon Oct  6 17:20:12 2014
From: issues at jboss.org (Martin Basovnik (JIRA))
Date: Mon, 6 Oct 2014 17:20:12 -0400 (EDT)
Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1781) Add support for
 multiple bootstrap complete services
In-Reply-To: <JIRA.12541724.1400854214000@Atlassian.JIRA>
References: <JIRA.12541724.1400854214000@Atlassian.JIRA>
	<JIRA.12541724.1400854214000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12541724.1400854214000.4544.1412630412449@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ARQ-1781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Basovnik updated ARQ-1781:
---------------------------------
              Status: Pull Request Sent  (was: Open)
    Git Pull Request: https://github.com/arquillian/arquillian-container-osgi/pull/19, https://github.com/arquillian/arquillian-container-osgi/pull/18


> Add support for multiple bootstrap complete services
> ----------------------------------------------------
>
>                 Key: ARQ-1781
>                 URL: https://issues.jboss.org/browse/ARQ-1781
>             Project: Arquillian
>          Issue Type: Feature Request
>          Components: OSGi Containers
>            Reporter: Martin Basovnik
>            Assignee: Thomas Diesler
>
> Add support for both master and 4.2 branches.



--
This message was sent by Atlassian JIRA
(v6.3.1#6329)

From issues at jboss.org  Mon Oct  6 17:20:12 2014
From: issues at jboss.org (Martin Basovnik (JIRA))
Date: Mon, 6 Oct 2014 17:20:12 -0400 (EDT)
Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1781) Add support for
 multiple bootstrap complete services
In-Reply-To: <JIRA.12541724.1400854214000@Atlassian.JIRA>
References: <JIRA.12541724.1400854214000@Atlassian.JIRA>
	<JIRA.12541724.1400854214000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12541724.1400854214000.4546.1412630412623@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ARQ-1781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Basovnik updated ARQ-1781:
---------------------------------
        Status: Resolved  (was: Pull Request Sent)
    Resolution: Done


> Add support for multiple bootstrap complete services
> ----------------------------------------------------
>
>                 Key: ARQ-1781
>                 URL: https://issues.jboss.org/browse/ARQ-1781
>             Project: Arquillian
>          Issue Type: Feature Request
>          Components: OSGi Containers
>            Reporter: Martin Basovnik
>            Assignee: Thomas Diesler
>
> Add support for both master and 4.2 branches.



--
This message was sent by Atlassian JIRA
(v6.3.1#6329)

From issues at jboss.org  Mon Oct  6 17:21:11 2014
From: issues at jboss.org (Martin Basovnik (JIRA))
Date: Mon, 6 Oct 2014 17:21:11 -0400 (EDT)
Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1788) containers - code
	refactoring
In-Reply-To: <JIRA.12542193.1401288785000@Atlassian.JIRA>
References: <JIRA.12542193.1401288785000@Atlassian.JIRA>
	<JIRA.12542193.1401288785000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12542193.1401288785000.4548.1412630471618@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ARQ-1788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Basovnik updated ARQ-1788:
---------------------------------
              Status: Pull Request Sent  (was: Open)
    Git Pull Request: https://github.com/arquillian/arquillian-container-osgi/pull/22


> containers - code refactoring
> -----------------------------
>
>                 Key: ARQ-1788
>                 URL: https://issues.jboss.org/browse/ARQ-1788
>             Project: Arquillian
>          Issue Type: Enhancement
>          Components: OSGi Containers
>            Reporter: Martin Basovnik
>            Assignee: Thomas Diesler
>
> *Code refactoring*
> - Create an ancestor for managed/remote containers using JMX
> - Rename class OSGiContainerConfiguration to EmbeddedContainerConfiguration
> - Process bootstrapCompleteServices in CommonDeployableContainer



--
This message was sent by Atlassian JIRA
(v6.3.1#6329)

From issues at jboss.org  Mon Oct  6 17:21:11 2014
From: issues at jboss.org (Martin Basovnik (JIRA))
Date: Mon, 6 Oct 2014 17:21:11 -0400 (EDT)
Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1788) containers - code
	refactoring
In-Reply-To: <JIRA.12542193.1401288785000@Atlassian.JIRA>
References: <JIRA.12542193.1401288785000@Atlassian.JIRA>
	<JIRA.12542193.1401288785000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12542193.1401288785000.4549.1412630471684@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ARQ-1788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Basovnik updated ARQ-1788:
---------------------------------
        Status: Resolved  (was: Pull Request Sent)
    Resolution: Done


> containers - code refactoring
> -----------------------------
>
>                 Key: ARQ-1788
>                 URL: https://issues.jboss.org/browse/ARQ-1788
>             Project: Arquillian
>          Issue Type: Enhancement
>          Components: OSGi Containers
>            Reporter: Martin Basovnik
>            Assignee: Thomas Diesler
>
> *Code refactoring*
> - Create an ancestor for managed/remote containers using JMX
> - Rename class OSGiContainerConfiguration to EmbeddedContainerConfiguration
> - Process bootstrapCompleteServices in CommonDeployableContainer



--
This message was sent by Atlassian JIRA
(v6.3.1#6329)

From issues at jboss.org  Tue Oct  7 03:02:13 2014
From: issues at jboss.org (=?UTF-8?Q?Ji=C5=99=C3=AD_=C5=A0tefek_=28JIRA=29?=)
Date: Tue, 7 Oct 2014 03:02:13 -0400 (EDT)
Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1866) Warp: make compilable
	with JDK 6
In-Reply-To: <JIRA.12554326.1412665287000@Atlassian.JIRA>
References: <JIRA.12554326.1412665287000@Atlassian.JIRA>
	<JIRA.12554326.1412665287038@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12554326.1412665287000.4885.1412665333897@Atlassian.JIRA>

Ji?? ?tefek created ARQ-1866:
--------------------------------

             Summary: Warp: make compilable with JDK 6
                 Key: ARQ-1866
                 URL: https://issues.jboss.org/browse/ARQ-1866
             Project: Arquillian
          Issue Type: Enhancement
          Components: Extension - Warp
            Reporter: Ji?? ?tefek


It would be good if the Warp can be compilable with older JDK.

The project is not compilable with jdk 6 because of method which was added in java 7 used on [this line|https://github.com/arquillian/arquillian-extension-warp/blob/master/impl/src/main/java/org/jboss/arquillian/warp/impl/client/proxy/DefaultURLMapping.java#L73]. 
Imho it could be replaced with:
{code}
try {
  return Inet4Address.getByName(null);
} catch (UnknownHostException ex) {
  throw new RuntimeException(ex);
}
{code}
>From the javadoc of this method:
bq. If the host is null then an InetAddress representing an address of the loopback interface is returned. See RFC?3330 section?2 and RFC?2373 section?2.5.3.



--
This message was sent by Atlassian JIRA
(v6.3.1#6329)


From issues at jboss.org  Tue Oct  7 05:11:11 2014
From: issues at jboss.org (Thomas Diesler (JIRA))
Date: Tue, 7 Oct 2014 05:11:11 -0400 (EDT)
Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1865) Undeploy arquillian
 bundle after the test suite in JMXDeployableContainer
In-Reply-To: <JIRA.12554273.1412604104000@Atlassian.JIRA>
References: <JIRA.12554273.1412604104000@Atlassian.JIRA>
	<JIRA.12554273.1412604104000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12554273.1412604104000.5283.1412673071618@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ARQ-1865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

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)

From issues at jboss.org  Tue Oct  7 08:22:11 2014
From: issues at jboss.org (Giovanni Silva (JIRA))
Date: Tue, 7 Oct 2014 08:22:11 -0400 (EDT)
Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1862) Scalatest TestRunner
In-Reply-To: <JIRA.12554169.1412351372000@Atlassian.JIRA>
References: <JIRA.12554169.1412351372000@Atlassian.JIRA>
	<JIRA.12554169.1412351372000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12554169.1412351372000.6441.1412684531205@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ARQ-1862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13009253#comment-13009253 ] 

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)

From issues at jboss.org  Tue Oct  7 18:31:11 2014
From: issues at jboss.org (Stefan Miklosovic (JIRA))
Date: Tue, 7 Oct 2014 18:31:11 -0400 (EDT)
Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1867) Recognize Spacelift
 threads from all others regarding of a thread name
In-Reply-To: <JIRA.12554458.1412721036000@Atlassian.JIRA>
References: <JIRA.12554458.1412721036000@Atlassian.JIRA>
	<JIRA.12554458.1412721036208@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12554458.1412721036000.8746.1412721071278@Atlassian.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)

From issues at jboss.org  Tue Oct  7 18:54:12 2014
From: issues at jboss.org (Stefan Miklosovic (JIRA))
Date: Tue, 7 Oct 2014 18:54:12 -0400 (EDT)
Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1867) Recognize Spacelift
 threads from all others regarding of a thread name
In-Reply-To: <JIRA.12554458.1412721036000@Atlassian.JIRA>
References: <JIRA.12554458.1412721036000@Atlassian.JIRA>
	<JIRA.12554458.1412721036000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12554458.1412721036000.8770.1412722452401@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ARQ-1867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

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)

From issues at jboss.org  Tue Oct  7 18:54:12 2014
From: issues at jboss.org (Stefan Miklosovic (JIRA))
Date: Tue, 7 Oct 2014 18:54:12 -0400 (EDT)
Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1867) Recognize Spacelift
 threads from all others regarding of a thread name
In-Reply-To: <JIRA.12554458.1412721036000@Atlassian.JIRA>
References: <JIRA.12554458.1412721036000@Atlassian.JIRA>
	<JIRA.12554458.1412721036000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12554458.1412721036000.8772.1412722452578@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ARQ-1867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

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)

From issues at jboss.org  Tue Oct  7 19:04:11 2014
From: issues at jboss.org (Stefan Miklosovic (JIRA))
Date: Tue, 7 Oct 2014 19:04:11 -0400 (EDT)
Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1868) JVM waits for
 Spacelift's cached threads to timeout causing its termination delay
In-Reply-To: <JIRA.12554459.1412722994000@Atlassian.JIRA>
References: <JIRA.12554459.1412722994000@Atlassian.JIRA>
	<JIRA.12554459.1412722994027@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12554459.1412722994000.8774.1412723051605@Atlassian.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)

From issues at jboss.org  Tue Oct  7 19:04:11 2014
From: issues at jboss.org (Stefan Miklosovic (JIRA))
Date: Tue, 7 Oct 2014 19:04:11 -0400 (EDT)
Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1868) JVM waits for
 Spacelift's cached threads to timeout causing its termination delay
In-Reply-To: <JIRA.12554459.1412722994000@Atlassian.JIRA>
References: <JIRA.12554459.1412722994000@Atlassian.JIRA>
	<JIRA.12554459.1412722994000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12554459.1412722994000.8776.1412723051765@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ARQ-1868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

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)

From issues at jboss.org  Wed Oct  8 03:21:10 2014
From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=)
Date: Wed, 8 Oct 2014 03:21:10 -0400 (EDT)
Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-463) JavaScript resource
 loader should use JavaScript.class.getClassLoader()
In-Reply-To: <JIRA.12554472.1412752824000@Atlassian.JIRA>
References: <JIRA.12554472.1412752824000@Atlassian.JIRA>
	<JIRA.12554472.1412752824784@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12554472.1412752824000.9325.1412752870718@Atlassian.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)


From issues at jboss.org  Wed Oct  8 03:31:11 2014
From: issues at jboss.org (Aslak Knutsen (JIRA))
Date: Wed, 8 Oct 2014 03:31:11 -0400 (EDT)
Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1862) Scalatest TestRunner
In-Reply-To: <JIRA.12554169.1412351372000@Atlassian.JIRA>
References: <JIRA.12554169.1412351372000@Atlassian.JIRA>
	<JIRA.12554169.1412351372000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12554169.1412351372000.9354.1412753471624@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ARQ-1862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13009647#comment-13009647 ] 

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/core/src/main/java/org/jboss/arquillian/spock/ArquillianInterceptor.java#L53

Similar in plane JUnit Arquillian; 
https://github.com/arquillian/arquillian-core/blob/master/junit/core/src/main/java/org/jboss/arquillian/junit/Arquillian.java#L190 
https://github.com/arquillian/arquillian-core/blob/master/junit/core/src/main/java/org/jboss/arquillian/junit/Arquillian.java#L212
https://github.com/arquillian/arquillian-core/blob/master/junit/core/src/main/java/org/jboss/arquillian/junit/Arquillian.java#L259
https://github.com/arquillian/arquillian-core/blob/master/junit/core/src/main/java/org/jboss/arquillian/junit/Arquillian.java#L279
https://github.com/arquillian/arquillian-core/blob/master/junit/core/src/main/java/org/jboss/arquillian/junit/Arquillian.java#L270

> 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)

From issues at jboss.org  Wed Oct  8 03:31:11 2014
From: issues at jboss.org (Aslak Knutsen (JIRA))
Date: Wed, 8 Oct 2014 03:31:11 -0400 (EDT)
Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1862) Scalatest TestRunner
In-Reply-To: <JIRA.12554169.1412351372000@Atlassian.JIRA>
References: <JIRA.12554169.1412351372000@Atlassian.JIRA>
	<JIRA.12554169.1412351372000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12554169.1412351372000.9356.1412753471812@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ARQ-1862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13009647#comment-13009647 ] 

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/core/src/main/java/org/jboss/arquillian/spock/ArquillianInterceptor.java#L53

Similar in plane JUnit Arquillian; 
https://github.com/arquillian/arquillian-core/blob/master/junit/core/src/main/java/org/jboss/arquillian/junit/Arquillian.java#L190 
https://github.com/arquillian/arquillian-core/blob/master/junit/core/src/main/java/org/jboss/arquillian/junit/Arquillian.java#L212
https://github.com/arquillian/arquillian-core/blob/master/junit/core/src/main/java/org/jboss/arquillian/junit/Arquillian.java#L259
https://github.com/arquillian/arquillian-core/blob/master/junit/core/src/main/java/org/jboss/arquillian/junit/Arquillian.java#L279
https://github.com/arquillian/arquillian-core/blob/master/junit/core/src/main/java/org/jboss/arquillian/junit/Arquillian.java#L270


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/core/src/main/java/org/jboss/arquillian/spock/ArquillianInterceptor.java#L53

Similar in plane JUnit Arquillian; 
https://github.com/arquillian/arquillian-core/blob/master/junit/core/src/main/java/org/jboss/arquillian/junit/Arquillian.java#L190 
https://github.com/arquillian/arquillian-core/blob/master/junit/core/src/main/java/org/jboss/arquillian/junit/Arquillian.java#L212
https://github.com/arquillian/arquillian-core/blob/master/junit/core/src/main/java/org/jboss/arquillian/junit/Arquillian.java#L259
https://github.com/arquillian/arquillian-core/blob/master/junit/core/src/main/java/org/jboss/arquillian/junit/Arquillian.java#L279
https://github.com/arquillian/arquillian-core/blob/master/junit/core/src/main/java/org/jboss/arquillian/junit/Arquillian.java#L270

> 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)

From issues at jboss.org  Wed Oct  8 03:49:11 2014
From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=)
Date: Wed, 8 Oct 2014 03:49:11 -0400 (EDT)
Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-463) JavaScript resource
 loader should use JavaScript.class.getClassLoader()
In-Reply-To: <JIRA.12554472.1412752824000@Atlassian.JIRA>
References: <JIRA.12554472.1412752824000@Atlassian.JIRA>
	<JIRA.12554472.1412752824000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12554472.1412752824000.9387.1412754551383@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ARQGRA-463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13009651#comment-13009651 ] 

Luk?? Fry? commented on ARQGRA-463:
-----------------------------------

https://github.com/arquillian/arquillian-graphene/commit/755f1718ab8cefa1c6707f2049f8f9cd8c7e77b5

> 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.0.3.Final, 2.1.0.Alpha1
>            Reporter: Luk?? Fry?
>             Fix For: 2.1.0.Alpha2
>
>
> It uses ClassLoader.getSystemResourceAsStream(resourceName);



--
This message was sent by Atlassian JIRA
(v6.3.1#6329)


From issues at jboss.org  Wed Oct  8 03:49:11 2014
From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=)
Date: Wed, 8 Oct 2014 03:49:11 -0400 (EDT)
Subject: [arquillian-issues] [JBoss JIRA] (ARQGRA-463) JavaScript resource
 loader should use JavaScript.class.getClassLoader()
In-Reply-To: <JIRA.12554472.1412752824000@Atlassian.JIRA>
References: <JIRA.12554472.1412752824000@Atlassian.JIRA>
	<JIRA.12554472.1412752824000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12554472.1412752824000.9388.1412754551441@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ARQGRA-463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Luk?? Fry? updated ARQGRA-463:
------------------------------
    Fix Version/s: 2.1.0.Alpha2


> 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.0.3.Final, 2.1.0.Alpha1
>            Reporter: Luk?? Fry?
>             Fix For: 2.1.0.Alpha2
>
>
> It uses ClassLoader.getSystemResourceAsStream(resourceName);



--
This message was sent by Atlassian JIRA
(v6.3.1#6329)


From issues at jboss.org  Wed Oct  8 07:57:11 2014
From: issues at jboss.org (Karel Piwko (JIRA))
Date: Wed, 8 Oct 2014 07:57:11 -0400 (EDT)
Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1868) JVM waits for
 Spacelift's cached threads to timeout causing its termination delay
In-Reply-To: <JIRA.12554459.1412722994000@Atlassian.JIRA>
References: <JIRA.12554459.1412722994000@Atlassian.JIRA>
	<JIRA.12554459.1412722994000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12554459.1412722994000.10272.1412769431694@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ARQ-1868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13009796#comment-13009796 ] 

Karel Piwko commented on ARQ-1868:
----------------------------------

Not sure if I understand the issue. Is that about JVM shutdown taking extra 60 seconds?

> 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)

From issues at jboss.org  Wed Oct  8 08:27:11 2014
From: issues at jboss.org (Stefan Miklosovic (JIRA))
Date: Wed, 8 Oct 2014 08:27:11 -0400 (EDT)
Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1868) JVM waits for
 Spacelift's cached threads to timeout causing its termination delay
In-Reply-To: <JIRA.12554459.1412722994000@Atlassian.JIRA>
References: <JIRA.12554459.1412722994000@Atlassian.JIRA>
	<JIRA.12554459.1412722994000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12554459.1412722994000.10385.1412771231235@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ARQ-1868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13009814#comment-13009814 ] 

Stefan Miklosovic commented on ARQ-1868:
----------------------------------------

Basically yes. When I use ExecutorSevice and put there callables, these are executed but underlying thread(s) which run them are not stopped immediately but they are cached so that mean even whole program is at its end and has nothing else to do, for JVM, in order to be stopped, it has to wait for that cached thread to timeout.

> 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)

From issues at jboss.org  Wed Oct  8 08:35:11 2014
From: issues at jboss.org (Stefan Miklosovic (JIRA))
Date: Wed, 8 Oct 2014 08:35:11 -0400 (EDT)
Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1868) JVM waits for
 Spacelift's cached threads to timeout causing its termination delay
In-Reply-To: <JIRA.12554459.1412722994000@Atlassian.JIRA>
References: <JIRA.12554459.1412722994000@Atlassian.JIRA>
	<JIRA.12554459.1412722994000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12554459.1412722994000.10394.1412771711398@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ARQ-1868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13009816#comment-13009816 ] 

Stefan Miklosovic commented on ARQ-1868:
----------------------------------------

I have tripple checked that the thread which needs to be timeouted does not hold any file descriptors to be closed and so on ... thread dump while it is hanging confirms my theory and jvisualvm proofs. Beer on me if you proof me to be wrong :)

> 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)

From issues at jboss.org  Wed Oct  8 10:25:13 2014
From: issues at jboss.org (Stefan Miklosovic (JIRA))
Date: Wed, 8 Oct 2014 10:25:13 -0400 (EDT)
Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1868) JVM waits for
 Spacelift's cached threads to timeout causing its termination delay
In-Reply-To: <JIRA.12554459.1412722994000@Atlassian.JIRA>
References: <JIRA.12554459.1412722994000@Atlassian.JIRA>
	<JIRA.12554459.1412722994000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12554459.1412722994000.10947.1412778313065@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ARQ-1868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stefan Miklosovic updated ARQ-1868:
-----------------------------------
    Attachment: spacelift_thread_dump.txt


> 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
>         Attachments: spacelift_thread_dump.txt
>
>
> 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)

From issues at jboss.org  Sun Oct 12 12:26:35 2014
From: issues at jboss.org (Alex Soto (JIRA))
Date: Sun, 12 Oct 2014 12:26:35 -0400 (EDT)
Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1869) Adds overwrite flag to
	DownloadTool
In-Reply-To: <JIRA.12554919.1413131169000@Atlassian.JIRA>
References: <JIRA.12554919.1413131169000@Atlassian.JIRA>
	<JIRA.12554919.1413131169960@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12554919.1413131169000.221.1413131195158@Atlassian.JIRA>

Alex Soto created ARQ-1869:
------------------------------

             Summary: Adds overwrite flag to DownloadTool
                 Key: ARQ-1869
                 URL: https://issues.jboss.org/browse/ARQ-1869
             Project: Arquillian
          Issue Type: Feature Request
          Components: Extension - Spacelift
            Reporter: Alex Soto
            Assignee: Alex Soto
            Priority: Minor


Adds overwrite flag to DownloadTool. By default the flag will be true for back compatibility, but if is set to false and the archive is already downloaded, then the file will not be downloaded.

Related with https://github.com/arquillian/arquillian-spacelift/issues/14



--
This message was sent by Atlassian JIRA
(v6.3.1#6329)

From issues at jboss.org  Mon Oct 13 04:41:35 2014
From: issues at jboss.org (Martin Basovnik (JIRA))
Date: Mon, 13 Oct 2014 04:41:35 -0400 (EDT)
Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1870) Method
 KarafRemoteContainerConfiguration.validate() does not call super method
In-Reply-To: <JIRA.12554949.1413189689000@Atlassian.JIRA>
References: <JIRA.12554949.1413189689000@Atlassian.JIRA>
	<JIRA.12554949.1413189689627@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12554949.1413189689000.735.1413189695292@Atlassian.JIRA>

Martin Basovnik created ARQ-1870:
------------------------------------

             Summary: Method KarafRemoteContainerConfiguration.validate() does not call super method
                 Key: ARQ-1870
                 URL: https://issues.jboss.org/browse/ARQ-1870
             Project: Arquillian
          Issue Type: Bug
          Components: OSGi Containers
            Reporter: Martin Basovnik
            Assignee: Thomas Diesler


Method {{KarafRemoteContainerConfiguration.validate()}} does not call super method.

Neither {{JMXContainerConfiguration.validate()}} nor {{CommonContainerConfiguration.validate()}} is called.



--
This message was sent by Atlassian JIRA
(v6.3.1#6329)

From issues at jboss.org  Mon Oct 13 05:12:35 2014
From: issues at jboss.org (Martin Basovnik (JIRA))
Date: Mon, 13 Oct 2014 05:12:35 -0400 (EDT)
Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1870) Method
 KarafRemoteContainerConfiguration.validate() does not call super method
In-Reply-To: <JIRA.12554949.1413189689000@Atlassian.JIRA>
References: <JIRA.12554949.1413189689000@Atlassian.JIRA>
	<JIRA.12554949.1413189689000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12554949.1413189689000.805.1413191555198@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ARQ-1870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Basovnik updated ARQ-1870:
---------------------------------
              Status: Pull Request Sent  (was: Open)
    Git Pull Request: https://github.com/arquillian/arquillian-container-osgi/pull/34, https://github.com/arquillian/arquillian-container-osgi/pull/35


> Method KarafRemoteContainerConfiguration.validate() does not call super method
> ------------------------------------------------------------------------------
>
>                 Key: ARQ-1870
>                 URL: https://issues.jboss.org/browse/ARQ-1870
>             Project: Arquillian
>          Issue Type: Bug
>          Components: OSGi Containers
>            Reporter: Martin Basovnik
>            Assignee: Thomas Diesler
>
> Method {{KarafRemoteContainerConfiguration.validate()}} does not call super method.
> Neither {{JMXContainerConfiguration.validate()}} nor {{CommonContainerConfiguration.validate()}} is called.



--
This message was sent by Atlassian JIRA
(v6.3.1#6329)

From issues at jboss.org  Mon Oct 13 05:13:35 2014
From: issues at jboss.org (Martin Basovnik (JIRA))
Date: Mon, 13 Oct 2014 05:13:35 -0400 (EDT)
Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1865) Undeploy arquillian
 bundle after the test suite in JMXDeployableContainer
In-Reply-To: <JIRA.12554273.1412604104000@Atlassian.JIRA>
References: <JIRA.12554273.1412604104000@Atlassian.JIRA>
	<JIRA.12554273.1412604104000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12554273.1412604104000.807.1413191615237@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ARQ-1865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Basovnik updated ARQ-1865:
---------------------------------
              Status: Pull Request Sent  (was: Pull Request Sent)
    Git Pull Request: https://github.com/arquillian/arquillian-container-osgi/pull/32, https://github.com/arquillian/arquillian-container-osgi/pull/33  (was: https://github.com/arquillian/arquillian-container-osgi/pull/32)


> 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)

From issues at jboss.org  Mon Oct 13 09:06:36 2014
From: issues at jboss.org (Bartosz Majsak (JIRA))
Date: Mon, 13 Oct 2014 09:06:36 -0400 (EDT)
Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1842) Show original exception
 instead of NullPointerExcetpion from TransactionHandler
In-Reply-To: <JIRA.12549797.1408593191000@Atlassian.JIRA>
References: <JIRA.12549797.1408593191000@Atlassian.JIRA>
	<JIRA.12549797.1408593191000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12549797.1408593191000.1513.1413205596464@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ARQ-1842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13011124#comment-13011124 ] 

Bartosz Majsak commented on ARQ-1842:
-------------------------------------

[~avsokolov] I think the easiest way would be to clone [arquillian-core|http://github.com/arquillian/arquillian-core] repository and install it locally in your maven repo and then refer to 1.1.6.Final-SNAPSHOT in your project.

> Show original exception instead of NullPointerExcetpion from TransactionHandler
> -------------------------------------------------------------------------------
>
>                 Key: ARQ-1842
>                 URL: https://issues.jboss.org/browse/ARQ-1842
>             Project: Arquillian
>          Issue Type: Sub-task
>          Components: Base Implementation
>            Reporter: Alexandr Sokolov
>             Fix For: 2.0.0.CR1
>
>
> Arquillan architecture based on observers. But now, if one of observers throws an exception and transactions are used. We are getting:
>  
> java.lang.NullPointerException: null
>   at org.jboss.arquillian.transaction.impl.lifecycle.TransactionHandler.testRequiresRollbackDueToFailure(TransactionHandler.java:170)
>  
> Although the actual exception in my case was thrown by DBUnitDataHandler.prepare().
>  
> Could you please change the logic so the original exception is displayed in the output? Otherwise we have to debug to get the actual exception. There is no way to find a solution without debugging via arquillian classes. It really takes rather long time.
> Full exception log:
> {code}
> java.lang.NullPointerException: null
> 	at org.jboss.arquillian.transaction.impl.lifecycle.TransactionHandler.testRequiresRollbackDueToFailure(TransactionHandler.java:170)
> 	at org.jboss.arquillian.transaction.impl.lifecycle.TransactionHandler.rollbackRequired(TransactionHandler.java:159)
> 	at org.jboss.arquillian.transaction.impl.lifecycle.TransactionHandler.endTransaction(TransactionHandler.java:123)
> 	at org.jboss.arquillian.transaction.impl.lifecycle.TransactionHandler.endTransactionAfterTest(TransactionHandler.java:102)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:606)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.testenricher.cdi.CreationalContextDestroyer.destory(CreationalContextDestroyer.java:44)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:606)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:102)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:606)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:84)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:606)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:65)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:606)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> 	at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.after(EventTestRunnerAdaptor.java:103)
> 	at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:277)
> 	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> 	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> 	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> 	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> 	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> 	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> 	at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:193)
> 	at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:345)
> 	at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:49)
> 	at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:207)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> 	at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:155)
> 	at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
> 	at org.junit.runner.JUnitCore.run(JUnitCore.java:138)
> 	at org.jboss.arquillian.junit.container.JUnitTestRunner.execute(JUnitTestRunner.java:66)
> 	at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.executeTest(ServletTestRunner.java:159)
> 	at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.execute(ServletTestRunner.java:125)
> 	at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.doGet(ServletTestRunner.java:89)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:734)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
> 	at org.jboss.weld.servlet.ConversationPropagationFilter.doFilter(ConversationPropagationFilter.java:62)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161)
> 	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:397)
> 	at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50)
> 	at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:165)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:372)
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877)
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:679)
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:931)
> 	at java.lang.Thread.run(Thread.java:744)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.1#6329)

From issues at jboss.org  Mon Oct 13 09:07:35 2014
From: issues at jboss.org (Bartosz Majsak (JIRA))
Date: Mon, 13 Oct 2014 09:07:35 -0400 (EDT)
Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1842) Show original exception
 instead of NullPointerExcetpion from TransactionHandler
In-Reply-To: <JIRA.12549797.1408593191000@Atlassian.JIRA>
References: <JIRA.12549797.1408593191000@Atlassian.JIRA>
	<JIRA.12549797.1408593191000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12549797.1408593191000.1531.1413205655750@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ARQ-1842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13011124#comment-13011124 ] 

Bartosz Majsak edited comment on ARQ-1842 at 10/13/14 9:07 AM:
---------------------------------------------------------------

[~avsokolov] I think the easiest way would be to clone [arquillian-core|http://github.com/arquillian/arquillian-core] repository and run {{mvn clean install}}  and then simply refer to 1.1.6.Final-SNAPSHOT in your project.


was (Author: bmajsak):
[~avsokolov] I think the easiest way would be to clone [arquillian-core|http://github.com/arquillian/arquillian-core] repository and install it locally in your maven repo and then refer to 1.1.6.Final-SNAPSHOT in your project.

> Show original exception instead of NullPointerExcetpion from TransactionHandler
> -------------------------------------------------------------------------------
>
>                 Key: ARQ-1842
>                 URL: https://issues.jboss.org/browse/ARQ-1842
>             Project: Arquillian
>          Issue Type: Sub-task
>          Components: Base Implementation
>            Reporter: Alexandr Sokolov
>             Fix For: 2.0.0.CR1
>
>
> Arquillan architecture based on observers. But now, if one of observers throws an exception and transactions are used. We are getting:
>  
> java.lang.NullPointerException: null
>   at org.jboss.arquillian.transaction.impl.lifecycle.TransactionHandler.testRequiresRollbackDueToFailure(TransactionHandler.java:170)
>  
> Although the actual exception in my case was thrown by DBUnitDataHandler.prepare().
>  
> Could you please change the logic so the original exception is displayed in the output? Otherwise we have to debug to get the actual exception. There is no way to find a solution without debugging via arquillian classes. It really takes rather long time.
> Full exception log:
> {code}
> java.lang.NullPointerException: null
> 	at org.jboss.arquillian.transaction.impl.lifecycle.TransactionHandler.testRequiresRollbackDueToFailure(TransactionHandler.java:170)
> 	at org.jboss.arquillian.transaction.impl.lifecycle.TransactionHandler.rollbackRequired(TransactionHandler.java:159)
> 	at org.jboss.arquillian.transaction.impl.lifecycle.TransactionHandler.endTransaction(TransactionHandler.java:123)
> 	at org.jboss.arquillian.transaction.impl.lifecycle.TransactionHandler.endTransactionAfterTest(TransactionHandler.java:102)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:606)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.testenricher.cdi.CreationalContextDestroyer.destory(CreationalContextDestroyer.java:44)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:606)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:102)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:606)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:84)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:606)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:65)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:606)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> 	at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.after(EventTestRunnerAdaptor.java:103)
> 	at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:277)
> 	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> 	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> 	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> 	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> 	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> 	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> 	at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:193)
> 	at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:345)
> 	at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:49)
> 	at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:207)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> 	at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:155)
> 	at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
> 	at org.junit.runner.JUnitCore.run(JUnitCore.java:138)
> 	at org.jboss.arquillian.junit.container.JUnitTestRunner.execute(JUnitTestRunner.java:66)
> 	at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.executeTest(ServletTestRunner.java:159)
> 	at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.execute(ServletTestRunner.java:125)
> 	at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.doGet(ServletTestRunner.java:89)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:734)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
> 	at org.jboss.weld.servlet.ConversationPropagationFilter.doFilter(ConversationPropagationFilter.java:62)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161)
> 	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:397)
> 	at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50)
> 	at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:165)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:372)
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877)
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:679)
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:931)
> 	at java.lang.Thread.run(Thread.java:744)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.1#6329)

From issues at jboss.org  Tue Oct 14 19:33:35 2014
From: issues at jboss.org (John Ament (JIRA))
Date: Tue, 14 Oct 2014 19:33:35 -0400 (EDT)
Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1871) Improve documentation
	in arquillian spock
In-Reply-To: <JIRA.12555168.1413329575000@Atlassian.JIRA>
References: <JIRA.12555168.1413329575000@Atlassian.JIRA>
	<JIRA.12555168.1413329575539@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12555168.1413329575000.6203.1413329615148@Atlassian.JIRA>

John Ament created ARQ-1871:
-------------------------------

             Summary: Improve documentation in arquillian spock
                 Key: ARQ-1871
                 URL: https://issues.jboss.org/browse/ARQ-1871
             Project: Arquillian
          Issue Type: Enhancement
          Components: Spock TestRunner
    Affects Versions: spock_1.0.0.Beta3
            Reporter: John Ament
            Assignee: Bartosz Majsak
            Priority: Minor






--
This message was sent by Atlassian JIRA
(v6.3.1#6329)

From issues at jboss.org  Tue Oct 14 19:36:35 2014
From: issues at jboss.org (John Ament (JIRA))
Date: Tue, 14 Oct 2014 19:36:35 -0400 (EDT)
Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1871) Improve documentation
	in arquillian spock
In-Reply-To: <JIRA.12555168.1413329575000@Atlassian.JIRA>
References: <JIRA.12555168.1413329575000@Atlassian.JIRA>
	<JIRA.12555168.1413329575000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12555168.1413329575000.6206.1413329795123@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ARQ-1871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13011859#comment-13011859 ] 

John Ament commented on ARQ-1871:
---------------------------------

I'd also like to update the examples to use gmaven instead of eclipse compiler.

> Improve documentation in arquillian spock
> -----------------------------------------
>
>                 Key: ARQ-1871
>                 URL: https://issues.jboss.org/browse/ARQ-1871
>             Project: Arquillian
>          Issue Type: Enhancement
>          Components: Spock TestRunner
>    Affects Versions: spock_1.0.0.Beta3
>            Reporter: John Ament
>            Assignee: Bartosz Majsak
>            Priority: Minor
>




--
This message was sent by Atlassian JIRA
(v6.3.1#6329)

From issues at jboss.org  Tue Oct 14 19:52:35 2014
From: issues at jboss.org (John Ament (JIRA))
Date: Tue, 14 Oct 2014 19:52:35 -0400 (EDT)
Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1871) Improve documentation
	in arquillian spock
In-Reply-To: <JIRA.12555168.1413329575000@Atlassian.JIRA>
References: <JIRA.12555168.1413329575000@Atlassian.JIRA>
	<JIRA.12555168.1413329575000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12555168.1413329575000.6209.1413330755325@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ARQ-1871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

John Ament updated ARQ-1871:
----------------------------
              Status: Pull Request Sent  (was: Open)
    Git Pull Request: https://github.com/arquillian/arquillian-testrunner-spock/pull/16


I have pulled the request.

> Improve documentation in arquillian spock
> -----------------------------------------
>
>                 Key: ARQ-1871
>                 URL: https://issues.jboss.org/browse/ARQ-1871
>             Project: Arquillian
>          Issue Type: Enhancement
>          Components: Spock TestRunner
>    Affects Versions: spock_1.0.0.Beta3
>            Reporter: John Ament
>            Assignee: Bartosz Majsak
>            Priority: Minor
>




--
This message was sent by Atlassian JIRA
(v6.3.1#6329)

From issues at jboss.org  Wed Oct 15 07:11:35 2014
From: issues at jboss.org (Bartosz Majsak (JIRA))
Date: Wed, 15 Oct 2014 07:11:35 -0400 (EDT)
Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1871) Improve documentation
	in arquillian spock
In-Reply-To: <JIRA.12555168.1413329575000@Atlassian.JIRA>
References: <JIRA.12555168.1413329575000@Atlassian.JIRA>
	<JIRA.12555168.1413329575000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12555168.1413329575000.7093.1413371495446@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ARQ-1871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13011998#comment-13011998 ] 

Bartosz Majsak commented on ARQ-1871:
-------------------------------------

Thanks [~meetoblivion]! Good spot. I put few comments in the pull request.

> Improve documentation in arquillian spock
> -----------------------------------------
>
>                 Key: ARQ-1871
>                 URL: https://issues.jboss.org/browse/ARQ-1871
>             Project: Arquillian
>          Issue Type: Enhancement
>          Components: Spock TestRunner
>    Affects Versions: spock_1.0.0.Beta3
>            Reporter: John Ament
>            Assignee: Bartosz Majsak
>            Priority: Minor
>




--
This message was sent by Atlassian JIRA
(v6.3.1#6329)

From issues at jboss.org  Wed Oct 15 07:27:36 2014
From: issues at jboss.org (John Ament (JIRA))
Date: Wed, 15 Oct 2014 07:27:36 -0400 (EDT)
Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1871) Improve documentation
	in arquillian spock
In-Reply-To: <JIRA.12555168.1413329575000@Atlassian.JIRA>
References: <JIRA.12555168.1413329575000@Atlassian.JIRA>
	<JIRA.12555168.1413329575000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12555168.1413329575000.7205.1413372456689@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ARQ-1871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13012007#comment-13012007 ] 

John Ament commented on ARQ-1871:
---------------------------------

[~bmajsak] should be good now, hopefully.

> Improve documentation in arquillian spock
> -----------------------------------------
>
>                 Key: ARQ-1871
>                 URL: https://issues.jboss.org/browse/ARQ-1871
>             Project: Arquillian
>          Issue Type: Enhancement
>          Components: Spock TestRunner
>    Affects Versions: spock_1.0.0.Beta3
>            Reporter: John Ament
>            Assignee: Bartosz Majsak
>            Priority: Minor
>




--
This message was sent by Atlassian JIRA
(v6.3.1#6329)

From issues at jboss.org  Wed Oct 15 08:11:36 2014
From: issues at jboss.org (Steven Geens (JIRA))
Date: Wed, 15 Oct 2014 08:11:36 -0400 (EDT)
Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1842) Show original exception
 instead of NullPointerExcetpion from TransactionHandler
In-Reply-To: <JIRA.12549797.1408593191000@Atlassian.JIRA>
References: <JIRA.12549797.1408593191000@Atlassian.JIRA>
	<JIRA.12549797.1408593191000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12549797.1408593191000.7458.1413375096685@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ARQ-1842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13012027#comment-13012027 ] 

Steven Geens commented on ARQ-1842:
-----------------------------------

I think I reproduced this error in my Github [arquillian-test|https://github.com/StevenGeens/arquillian-test] project.

The problem still occurs with the latest version of arquillian-core, build as suggested Bartosz.



> Show original exception instead of NullPointerExcetpion from TransactionHandler
> -------------------------------------------------------------------------------
>
>                 Key: ARQ-1842
>                 URL: https://issues.jboss.org/browse/ARQ-1842
>             Project: Arquillian
>          Issue Type: Sub-task
>          Components: Base Implementation
>            Reporter: Alexandr Sokolov
>             Fix For: 2.0.0.CR1
>
>
> Arquillan architecture based on observers. But now, if one of observers throws an exception and transactions are used. We are getting:
>  
> java.lang.NullPointerException: null
>   at org.jboss.arquillian.transaction.impl.lifecycle.TransactionHandler.testRequiresRollbackDueToFailure(TransactionHandler.java:170)
>  
> Although the actual exception in my case was thrown by DBUnitDataHandler.prepare().
>  
> Could you please change the logic so the original exception is displayed in the output? Otherwise we have to debug to get the actual exception. There is no way to find a solution without debugging via arquillian classes. It really takes rather long time.
> Full exception log:
> {code}
> java.lang.NullPointerException: null
> 	at org.jboss.arquillian.transaction.impl.lifecycle.TransactionHandler.testRequiresRollbackDueToFailure(TransactionHandler.java:170)
> 	at org.jboss.arquillian.transaction.impl.lifecycle.TransactionHandler.rollbackRequired(TransactionHandler.java:159)
> 	at org.jboss.arquillian.transaction.impl.lifecycle.TransactionHandler.endTransaction(TransactionHandler.java:123)
> 	at org.jboss.arquillian.transaction.impl.lifecycle.TransactionHandler.endTransactionAfterTest(TransactionHandler.java:102)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:606)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.testenricher.cdi.CreationalContextDestroyer.destory(CreationalContextDestroyer.java:44)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:606)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:102)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:606)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:84)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:606)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:65)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:606)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> 	at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.after(EventTestRunnerAdaptor.java:103)
> 	at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:277)
> 	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> 	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> 	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> 	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> 	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> 	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> 	at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:193)
> 	at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:345)
> 	at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:49)
> 	at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:207)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> 	at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:155)
> 	at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
> 	at org.junit.runner.JUnitCore.run(JUnitCore.java:138)
> 	at org.jboss.arquillian.junit.container.JUnitTestRunner.execute(JUnitTestRunner.java:66)
> 	at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.executeTest(ServletTestRunner.java:159)
> 	at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.execute(ServletTestRunner.java:125)
> 	at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.doGet(ServletTestRunner.java:89)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:734)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
> 	at org.jboss.weld.servlet.ConversationPropagationFilter.doFilter(ConversationPropagationFilter.java:62)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161)
> 	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:397)
> 	at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50)
> 	at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:165)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:372)
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877)
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:679)
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:931)
> 	at java.lang.Thread.run(Thread.java:744)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.1#6329)

From issues at jboss.org  Fri Oct 17 03:41:35 2014
From: issues at jboss.org (Karel Piwko (JIRA))
Date: Fri, 17 Oct 2014 03:41:35 -0400 (EDT)
Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1863) Update Spacelift
 Arquillian dependency version to 1.1.5.Final
In-Reply-To: <JIRA.12554194.1412418803000@Atlassian.JIRA>
References: <JIRA.12554194.1412418803000@Atlassian.JIRA>
	<JIRA.12554194.1412418803000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12554194.1412418803000.11955.1413531695648@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ARQ-1863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Karel Piwko updated ARQ-1863:
-----------------------------
    Affects Version/s: spacelift_1.0.0.Alpha2
                           (was: 1.0.0.Alpha2)


> Update Spacelift Arquillian dependency version to 1.1.5.Final
> -------------------------------------------------------------
>
>                 Key: ARQ-1863
>                 URL: https://issues.jboss.org/browse/ARQ-1863
>             Project: Arquillian
>          Issue Type: Enhancement
>          Components: Extension - Spacelift
>    Affects Versions: spacelift_1.0.0.Alpha2
>            Reporter: Alex Soto
>            Assignee: Alex Soto
>            Priority: Minor
>
> Currently Arquillian Spacelift uses Arquillian 1.1.4 as arquillian version but if you run in a 1.1.5, an exception is thrown. This is because both dependencies 1.14 and 1.1.5 coexists and a NoSuchMethodError exception is thrown. To avoid this you can add arquillian pom in dependency management.
> <dependency>
>             <groupId>org.jboss.arquillian</groupId>
>             <artifactId>arquillian-bom</artifactId>
>             <version>1.1.5.Final</version>
>             <scope>import</scope>
>             <type>pom</type>
> </dependency>
> Related issue https://github.com/arquillian/arquillian-spacelift/issues/13



--
This message was sent by Atlassian JIRA
(v6.3.1#6329)

From issues at jboss.org  Fri Oct 17 03:42:35 2014
From: issues at jboss.org (Karel Piwko (JIRA))
Date: Fri, 17 Oct 2014 03:42:35 -0400 (EDT)
Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1863) Update Spacelift
 Arquillian dependency version to 1.1.5.Final
In-Reply-To: <JIRA.12554194.1412418803000@Atlassian.JIRA>
References: <JIRA.12554194.1412418803000@Atlassian.JIRA>
	<JIRA.12554194.1412418803000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12554194.1412418803000.11958.1413531755673@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ARQ-1863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Karel Piwko updated ARQ-1863:
-----------------------------
    Fix Version/s: spacelift_1.0.0.Alpha3


> Update Spacelift Arquillian dependency version to 1.1.5.Final
> -------------------------------------------------------------
>
>                 Key: ARQ-1863
>                 URL: https://issues.jboss.org/browse/ARQ-1863
>             Project: Arquillian
>          Issue Type: Enhancement
>          Components: Extension - Spacelift
>    Affects Versions: spacelift_1.0.0.Alpha2
>            Reporter: Alex Soto
>            Assignee: Alex Soto
>            Priority: Minor
>             Fix For: spacelift_1.0.0.Alpha3
>
>
> Currently Arquillian Spacelift uses Arquillian 1.1.4 as arquillian version but if you run in a 1.1.5, an exception is thrown. This is because both dependencies 1.14 and 1.1.5 coexists and a NoSuchMethodError exception is thrown. To avoid this you can add arquillian pom in dependency management.
> <dependency>
>             <groupId>org.jboss.arquillian</groupId>
>             <artifactId>arquillian-bom</artifactId>
>             <version>1.1.5.Final</version>
>             <scope>import</scope>
>             <type>pom</type>
> </dependency>
> Related issue https://github.com/arquillian/arquillian-spacelift/issues/13



--
This message was sent by Atlassian JIRA
(v6.3.1#6329)

From issues at jboss.org  Fri Oct 17 03:43:36 2014
From: issues at jboss.org (Karel Piwko (JIRA))
Date: Fri, 17 Oct 2014 03:43:36 -0400 (EDT)
Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1864) Change Zip4j in favor
	of commons-compress
In-Reply-To: <JIRA.12554195.1412421448000@Atlassian.JIRA>
References: <JIRA.12554195.1412421448000@Atlassian.JIRA>
	<JIRA.12554195.1412421448000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12554195.1412421448000.11967.1413531816546@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ARQ-1864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Karel Piwko updated ARQ-1864:
-----------------------------
    Affects Version/s: spacelift_1.0.0.Alpha2


> Change Zip4j in favor of commons-compress
> -----------------------------------------
>
>                 Key: ARQ-1864
>                 URL: https://issues.jboss.org/browse/ARQ-1864
>             Project: Arquillian
>          Issue Type: Enhancement
>          Components: Extension - Spacelift
>    Affects Versions: spacelift_1.0.0.Alpha2
>            Reporter: Alex Soto
>            Assignee: Alex Soto
>
> UnZip tool is based on zip4j library. The problem is that sometimes the files are tar, gzip, 7z, or arj. I suggest to change zip4j to commons-compress which supports a lot of compress algorithms in order to be able to write some Tool like UnzipTool, UntarTool and so on and even a generic UnCompressTool which you set the algorithm to be used.
> http://search.maven.org/#artifactdetails%7Corg.apache.commons%7Ccommons-compress%7C1.8.1%7Cjar
> The good news is that this library is maintained as well (last version released is from May 2014.
> Again if you agree I will implement the change.
> Note: that I have never found this error because I download zip files but today it is the first time I have found this barrier.
> Of course another approach is to use GZipIS but because we are already using zip4j we can drop it and add this library.
> Related with https://github.com/arquillian/arquillian-spacelift/issues/15



--
This message was sent by Atlassian JIRA
(v6.3.1#6329)

From issues at jboss.org  Fri Oct 17 03:43:37 2014
From: issues at jboss.org (Karel Piwko (JIRA))
Date: Fri, 17 Oct 2014 03:43:37 -0400 (EDT)
Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1864) Change Zip4j in favor
	of commons-compress
In-Reply-To: <JIRA.12554195.1412421448000@Atlassian.JIRA>
References: <JIRA.12554195.1412421448000@Atlassian.JIRA>
	<JIRA.12554195.1412421448000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12554195.1412421448000.11970.1413531817079@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ARQ-1864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Karel Piwko updated ARQ-1864:
-----------------------------
    Fix Version/s: spacelift_1.0.0.Alpha3


> Change Zip4j in favor of commons-compress
> -----------------------------------------
>
>                 Key: ARQ-1864
>                 URL: https://issues.jboss.org/browse/ARQ-1864
>             Project: Arquillian
>          Issue Type: Enhancement
>          Components: Extension - Spacelift
>    Affects Versions: spacelift_1.0.0.Alpha2
>            Reporter: Alex Soto
>            Assignee: Alex Soto
>             Fix For: spacelift_1.0.0.Alpha3
>
>
> UnZip tool is based on zip4j library. The problem is that sometimes the files are tar, gzip, 7z, or arj. I suggest to change zip4j to commons-compress which supports a lot of compress algorithms in order to be able to write some Tool like UnzipTool, UntarTool and so on and even a generic UnCompressTool which you set the algorithm to be used.
> http://search.maven.org/#artifactdetails%7Corg.apache.commons%7Ccommons-compress%7C1.8.1%7Cjar
> The good news is that this library is maintained as well (last version released is from May 2014.
> Again if you agree I will implement the change.
> Note: that I have never found this error because I download zip files but today it is the first time I have found this barrier.
> Of course another approach is to use GZipIS but because we are already using zip4j we can drop it and add this library.
> Related with https://github.com/arquillian/arquillian-spacelift/issues/15



--
This message was sent by Atlassian JIRA
(v6.3.1#6329)

From issues at jboss.org  Fri Oct 17 03:48:35 2014
From: issues at jboss.org (Karel Piwko (JIRA))
Date: Fri, 17 Oct 2014 03:48:35 -0400 (EDT)
Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1863) Update Spacelift
 Arquillian dependency version to 1.1.5.Final
In-Reply-To: <JIRA.12554194.1412418803000@Atlassian.JIRA>
References: <JIRA.12554194.1412418803000@Atlassian.JIRA>
	<JIRA.12554194.1412418803000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12554194.1412418803000.11985.1413532115416@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ARQ-1863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Karel Piwko resolved ARQ-1863.
------------------------------
    Resolution: Done


Pushed upstream in https://github.com/arquillian/arquillian-spacelift/commit/66da963c487292e03c4f83e72c753472ba5d4857

Thanks!

> Update Spacelift Arquillian dependency version to 1.1.5.Final
> -------------------------------------------------------------
>
>                 Key: ARQ-1863
>                 URL: https://issues.jboss.org/browse/ARQ-1863
>             Project: Arquillian
>          Issue Type: Enhancement
>          Components: Extension - Spacelift
>    Affects Versions: spacelift_1.0.0.Alpha2
>            Reporter: Alex Soto
>            Assignee: Alex Soto
>            Priority: Minor
>             Fix For: spacelift_1.0.0.Alpha3
>
>
> Currently Arquillian Spacelift uses Arquillian 1.1.4 as arquillian version but if you run in a 1.1.5, an exception is thrown. This is because both dependencies 1.14 and 1.1.5 coexists and a NoSuchMethodError exception is thrown. To avoid this you can add arquillian pom in dependency management.
> <dependency>
>             <groupId>org.jboss.arquillian</groupId>
>             <artifactId>arquillian-bom</artifactId>
>             <version>1.1.5.Final</version>
>             <scope>import</scope>
>             <type>pom</type>
> </dependency>
> Related issue https://github.com/arquillian/arquillian-spacelift/issues/13



--
This message was sent by Atlassian JIRA
(v6.3.1#6329)

From issues at jboss.org  Fri Oct 17 03:57:36 2014
From: issues at jboss.org (Karel Piwko (JIRA))
Date: Fri, 17 Oct 2014 03:57:36 -0400 (EDT)
Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1864) Change Zip4j in favor
	of commons-compress
In-Reply-To: <JIRA.12554195.1412421448000@Atlassian.JIRA>
References: <JIRA.12554195.1412421448000@Atlassian.JIRA>
	<JIRA.12554195.1412421448000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12554195.1412421448000.12020.1413532656543@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ARQ-1864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Karel Piwko resolved ARQ-1864.
------------------------------
    Resolution: Done


Landed in https://github.com/arquillian/arquillian-spacelift/commit/3a2b7aca25376a73ae9d0c1bfd0b79e9965115b3

Thanks!

> Change Zip4j in favor of commons-compress
> -----------------------------------------
>
>                 Key: ARQ-1864
>                 URL: https://issues.jboss.org/browse/ARQ-1864
>             Project: Arquillian
>          Issue Type: Enhancement
>          Components: Extension - Spacelift
>    Affects Versions: spacelift_1.0.0.Alpha2
>            Reporter: Alex Soto
>            Assignee: Alex Soto
>             Fix For: spacelift_1.0.0.Alpha3
>
>
> UnZip tool is based on zip4j library. The problem is that sometimes the files are tar, gzip, 7z, or arj. I suggest to change zip4j to commons-compress which supports a lot of compress algorithms in order to be able to write some Tool like UnzipTool, UntarTool and so on and even a generic UnCompressTool which you set the algorithm to be used.
> http://search.maven.org/#artifactdetails%7Corg.apache.commons%7Ccommons-compress%7C1.8.1%7Cjar
> The good news is that this library is maintained as well (last version released is from May 2014.
> Again if you agree I will implement the change.
> Note: that I have never found this error because I download zip files but today it is the first time I have found this barrier.
> Of course another approach is to use GZipIS but because we are already using zip4j we can drop it and add this library.
> Related with https://github.com/arquillian/arquillian-spacelift/issues/15



--
This message was sent by Atlassian JIRA
(v6.3.1#6329)

From issues at jboss.org  Fri Oct 17 04:12:35 2014
From: issues at jboss.org (Karel Piwko (JIRA))
Date: Fri, 17 Oct 2014 04:12:35 -0400 (EDT)
Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1720) Command's toString()
 method does not take whitespaces into account
In-Reply-To: <JIRA.12535741.1395416607000@Atlassian.JIRA>
References: <JIRA.12535741.1395416607000@Atlassian.JIRA>
	<JIRA.12535741.1395416607000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535741.1395416607000.12091.1413533555652@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ARQ-1720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Karel Piwko closed ARQ-1720.
----------------------------


> Command's toString() method does not take whitespaces into account
> ------------------------------------------------------------------
>
>                 Key: ARQ-1720
>                 URL: https://issues.jboss.org/browse/ARQ-1720
>             Project: Arquillian
>          Issue Type: Bug
>          Components: Extension - Spacelift
>    Affects Versions: spacelift_1.0.0.Alpha1
>            Reporter: Stefan Miklosovic
>            Assignee: Karel Piwko
>             Fix For: spacelift_1.0.0.Alpha2
>
>
> In case of invocation of command like this from shell
> {code}
> android create avd -n fd930b32-69bc-4d52-8313-2c9c27bb4511 -t "Google Inc.:Google APIs:17"
> {code}
> In order to build that command in Spacelift, having
> {code}
> String target = "Google Inc.:Google APIs:17";
> {code}
> this is necessary to do in order to have the same command in Spacelift
> {code}
> Command command = new CommandBuilder().add(sdk.getAndroidPath())
>     .add("create")
>     .add("avd")
>     .add("-n")
>     .add(configuration.getAvdName())
>     .add("-t")
>     .add(target).build();
> {code}
> However, command.toString() says that Spacelift invoked this
> {code}
> android create avd -n fd930b32-69bc-4d52-8313-2c9c27bb4511 -t Google Inc.:Google APIs:17
> {code}
> But it is not true, in fact, it was executed with enclosing quotes because of present spaces in target string which command.toString() has not taken into account.



--
This message was sent by Atlassian JIRA
(v6.3.1#6329)

From issues at jboss.org  Fri Oct 17 04:12:35 2014
From: issues at jboss.org (Karel Piwko (JIRA))
Date: Fri, 17 Oct 2014 04:12:35 -0400 (EDT)
Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1712) Support for process
	identification
In-Reply-To: <JIRA.12535406.1395237630000@Atlassian.JIRA>
References: <JIRA.12535406.1395237630000@Atlassian.JIRA>
	<JIRA.12535406.1395237630000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535406.1395237630000.12093.1413533555894@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ARQ-1712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Karel Piwko closed ARQ-1712.
----------------------------


> Support for process identification
> ----------------------------------
>
>                 Key: ARQ-1712
>                 URL: https://issues.jboss.org/browse/ARQ-1712
>             Project: Arquillian
>          Issue Type: Enhancement
>          Components: Extension - Spacelift
>    Affects Versions: spacelift_1.0.0.Alpha1
>            Reporter: Karel Piwko
>            Assignee: Karel Piwko
>             Fix For: spacelift_1.0.0.Alpha2
>
>
> Spacelift currently always outputs process identification (based on first argument).
> It should be possible to:
> * make this string configurable
> * disable this altogether
> This will help make logs more readable.



--
This message was sent by Atlassian JIRA
(v6.3.1#6329)

From issues at jboss.org  Fri Oct 17 04:12:36 2014
From: issues at jboss.org (Karel Piwko (JIRA))
Date: Fri, 17 Oct 2014 04:12:36 -0400 (EDT)
Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1719) Command execution
 failure does not show command
In-Reply-To: <JIRA.12535690.1395403916000@Atlassian.JIRA>
References: <JIRA.12535690.1395403916000@Atlassian.JIRA>
	<JIRA.12535690.1395403916000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12535690.1395403916000.12095.1413533556059@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ARQ-1719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Karel Piwko closed ARQ-1719.
----------------------------


> Command execution failure does not show command
> -----------------------------------------------
>
>                 Key: ARQ-1719
>                 URL: https://issues.jboss.org/browse/ARQ-1719
>             Project: Arquillian
>          Issue Type: Feature Request
>          Components: Extension - Spacelift
>    Affects Versions: spacelift_1.0.0.Alpha1
>            Reporter: Karel Piwko
>            Assignee: Karel Piwko
>             Fix For: spacelift_1.0.0.Alpha2
>
>
> If command fails, it shows:
> {code}
> Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 23.814 sec <<< FAILURE! - in org.jboss.aerogearjs.crypto.AeroGearCryptoTestCase
> aerogearCryptoTestSuite(org.jboss.aerogearjs.crypto.AeroGearCryptoTestCase)  Time elapsed: 0.046 sec  <<< ERROR!
> org.arquillian.spacelift.process.ProcessExecutionException: Invocation of [Ljava.lang.String;@78c66962 failed with 1
> {code}
> This is useless, it should show real command.



--
This message was sent by Atlassian JIRA
(v6.3.1#6329)

From issues at jboss.org  Fri Oct 17 04:12:36 2014
From: issues at jboss.org (Karel Piwko (JIRA))
Date: Fri, 17 Oct 2014 04:12:36 -0400 (EDT)
Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1647) Allow Executor to set
	process exit code
In-Reply-To: <JIRA.12532553.1392744096000@Atlassian.JIRA>
References: <JIRA.12532553.1392744096000@Atlassian.JIRA>
	<JIRA.12532553.1392744096000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12532553.1392744096000.12097.1413533556186@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ARQ-1647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Karel Piwko closed ARQ-1647.
----------------------------


> Allow Executor to set process exit code
> ---------------------------------------
>
>                 Key: ARQ-1647
>                 URL: https://issues.jboss.org/browse/ARQ-1647
>             Project: Arquillian
>          Issue Type: Feature Request
>          Components: Extension - Spacelift
>    Affects Versions: spacelift_1.0.0.Alpha1
>            Reporter: Karel Piwko
>            Assignee: Karel Piwko
>             Fix For: spacelift_1.0.0.Alpha2
>
>
> Currently, it is not possible to setup exit code for external process. This makes handling of execution failure quite complicated.
> Figure out what API should be used to let user define allowed exit values. 0 is to be kept as default value. Additionally, there might be multiple values to be set.



--
This message was sent by Atlassian JIRA
(v6.3.1#6329)

From issues at jboss.org  Fri Oct 17 04:12:36 2014
From: issues at jboss.org (Karel Piwko (JIRA))
Date: Fri, 17 Oct 2014 04:12:36 -0400 (EDT)
Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1687) Support setting process
	basedir
In-Reply-To: <JIRA.12534533.1394452848000@Atlassian.JIRA>
References: <JIRA.12534533.1394452848000@Atlassian.JIRA>
	<JIRA.12534533.1394452848000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534533.1394452848000.12099.1413533556344@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ARQ-1687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Karel Piwko closed ARQ-1687.
----------------------------


> Support setting process basedir
> -------------------------------
>
>                 Key: ARQ-1687
>                 URL: https://issues.jboss.org/browse/ARQ-1687
>             Project: Arquillian
>          Issue Type: Feature Request
>          Components: Extension - Spacelift
>    Affects Versions: spacelift_1.0.0.Alpha1
>            Reporter: Karel Piwko
>            Assignee: Tadeas Kriz
>             Fix For: spacelift_1.0.0.Alpha2
>
>
> Is is not possible to setup a home directory of spawned/executed process.



--
This message was sent by Atlassian JIRA
(v6.3.1#6329)

From issues at jboss.org  Fri Oct 17 04:13:35 2014
From: issues at jboss.org (Karel Piwko (JIRA))
Date: Fri, 17 Oct 2014 04:13:35 -0400 (EDT)
Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1867) Recognize Spacelift
 threads from all others regarding of a thread name
In-Reply-To: <JIRA.12554458.1412721036000@Atlassian.JIRA>
References: <JIRA.12554458.1412721036000@Atlassian.JIRA>
	<JIRA.12554458.1412721036000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12554458.1412721036000.12102.1413533615350@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ARQ-1867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Karel Piwko updated ARQ-1867:
-----------------------------
        Status: Resolved  (was: Pull Request Sent)
    Resolution: Done


Landed in https://github.com/arquillian/arquillian-spacelift/commit/f54fbcf83fdccd0f5baedea74b755d0cc220c4f8

THanks!

> 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)

From issues at jboss.org  Fri Oct 17 04:13:35 2014
From: issues at jboss.org (Karel Piwko (JIRA))
Date: Fri, 17 Oct 2014 04:13:35 -0400 (EDT)
Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1867) Recognize Spacelift
 threads from all others regarding of a thread name
In-Reply-To: <JIRA.12554458.1412721036000@Atlassian.JIRA>
References: <JIRA.12554458.1412721036000@Atlassian.JIRA>
	<JIRA.12554458.1412721036000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12554458.1412721036000.12104.1413533615550@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ARQ-1867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Karel Piwko updated ARQ-1867:
-----------------------------
    Fix Version/s: spacelift_1.0.0.Alpha3


> 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
>             Fix For: spacelift_1.0.0.Alpha3
>
>
> 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)

From issues at jboss.org  Sat Oct 18 18:57:35 2014
From: issues at jboss.org (Karl Pietrzak (JIRA))
Date: Sat, 18 Oct 2014 18:57:35 -0400 (EDT)
Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1872) cannot use custom
	dialect
In-Reply-To: <JIRA.12555490.1413673044000@Atlassian.JIRA>
References: <JIRA.12555490.1413673044000@Atlassian.JIRA>
	<JIRA.12555490.1413673044087@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12555490.1413673044000.14317.1413673055243@Atlassian.JIRA>

Karl Pietrzak created ARQ-1872:
----------------------------------

             Summary: cannot use custom dialect
                 Key: ARQ-1872
                 URL: https://issues.jboss.org/browse/ARQ-1872
             Project: Arquillian
          Issue Type: Bug
          Components: JBoss AS Containers
         Environment: arquillian_core 1.1.5.Final
wildfly 8.1.0.Final
wildfly-arquillian-container-embedded 8.1.0.Final
            Reporter: Karl Pietrzak


h3. Short Description

You can't use a custom dialect because you'll get a {{HibernateException}}:

{noformat}
org.hibernate.HibernateException: Unable to construct requested dialect [com.mycompany.hibernate.MySQLBitBooleanDialect]
	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:172) [wildfly-jpa-8.1.0.Final.jar:8.1.0.Final]
	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:117) [wildfly-jpa-8.1.0.Final.jar:8.1.0.Final]
	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_67]
	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:474) [wildfly-security-manager-1.0.0.Final.jar:1.0.0.Final]
	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:182) [wildfly-jpa-8.1.0.Final.jar:8.1.0.Final]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_67]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_67]
	at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_67]
	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
Caused by: org.hibernate.HibernateException: Unable to construct requested dialect [com.mycompany.hibernate.MySQLBitBooleanDialect]
	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.constructDialect(DialectFactoryImpl.java:88) [hibernate-core-4.3.5.Final.jar:4.3.5.Final]
	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.buildDialect(DialectFactoryImpl.java:68) [hibernate-core-4.3.5.Final.jar:4.3.5.Final]
	at org.hibernate.engine.jdbc.internal.JdbcServicesImpl.configure(JdbcServicesImpl.java:165) [hibernate-core-4.3.5.Final.jar:4.3.5.Final]
	at org.hibernate.boot.registry.internal.StandardServiceRegistryImpl.configureService(StandardServiceRegistryImpl.java:111) [hibernate-core-4.3.5.Final.jar:4.3.5.Final]
	at org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService(AbstractServiceRegistryImpl.java:234) [hibernate-core-4.3.5.Final.jar:4.3.5.Final]
	at org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(AbstractServiceRegistryImpl.java:206) [hibernate-core-4.3.5.Final.jar:4.3.5.Final]
	at org.hibernate.cfg.Configuration.buildTypeRegistrations(Configuration.java:1885) [hibernate-core-4.3.5.Final.jar:4.3.5.Final]
	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1843) [hibernate-core-4.3.5.Final.jar:4.3.5.Final]
	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:850) [hibernate-entitymanager-4.3.5.Final.jar:4.3.5.Final]
	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:843) [hibernate-entitymanager-4.3.5.Final.jar:4.3.5.Final]
	at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:397) [hibernate-core-4.3.5.Final.jar:4.3.5.Final]
	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:842) [hibernate-entitymanager-4.3.5.Final.jar:4.3.5.Final]
	at org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44) [jipijapa-hibernate4-3-1.0.1.Final.jar:]
	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:154) [wildfly-jpa-8.1.0.Final.jar:8.1.0.Final]
	... 8 more
Caused by: java.lang.ClassCastException: com.mycompany.hibernate.MySQLBitBooleanDialect cannot be cast to org.hibernate.dialect.Dialect
	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.constructDialect(DialectFactoryImpl.java:78) [hibernate-core-4.3.5.Final.jar:4.3.5.Final]
	... 21 more

{noformat}

My WAG is that it's a classloader issue.

h3. Longer Version

Some more info is in server.log:

{noformat}
2014-10-18 18:26:58,736 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 17) MSC000001: Failed to start service jboss.persistenceunit."test.war#myproject_db-pu-web": org.jboss.msc.service.StartException in service jboss.persistenceunit."test.war#myproject_db-pu-web": org.hibernate.boot.registry.selector.spi.StrategySelectionException: Unable to resolve name [com.mycompany.hibernate.MySQLBitBooleanDialect] as strategy [org.hibernate.dialect.Dialect]
        at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:172) [wildfly-jpa-8.1.0.Final.jar:8.1.0.Final]
        at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:117) [wildfly-jpa-8.1.0.Final.jar:8.1.0.Final]
        at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_67]
        at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:474)
        at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:182) [wildfly-jpa-8.1.0.Final.jar:8.1.0.Final]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_67]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_67]
        at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_67]
        at org.jboss.threads.JBossThread.run(JBossThread.java:122)
Caused by: org.hibernate.boot.registry.selector.spi.StrategySelectionException: Unable to resolve name [com.mycompany.hibernate.MySQLBitBooleanDialect] as strategy [org.hibernate.dialect.Dialect]
        at org.hibernate.boot.registry.selector.internal.StrategySelectorImpl.selectStrategyImplementor(StrategySelectorImpl.java:128) [hibernate-core-4.3.5.Final.jar:4.3.5.Final]
        at org.hibernate.boot.registry.selector.internal.StrategySelectorImpl.resolveDefaultableStrategy(StrategySelectorImpl.java:155) [hibernate-core-4.3.5.Final.jar:4.3.5.Final]
        at org.hibernate.boot.registry.selector.internal.StrategySelectorImpl.resolveStrategy(StrategySelectorImpl.java:136) [hibernate-core-4.3.5.Final.jar:4.3.5.Final]
        at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.constructDialect(DialectFactoryImpl.java:78) [hibernate-core-4.3.5.Final.jar:4.3.5.Final]
        at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.buildDialect(DialectFactoryImpl.java:68) [hibernate-core-4.3.5.Final.jar:4.3.5.Final]
        at org.hibernate.engine.jdbc.internal.JdbcServicesImpl.configure(JdbcServicesImpl.java:165) [hibernate-core-4.3.5.Final.jar:4.3.5.Final]
        at org.hibernate.boot.registry.internal.StandardServiceRegistryImpl.configureService(StandardServiceRegistryImpl.java:111) [hibernate-core-4.3.5.Final.jar:4.3.5.Final]
        at org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService(AbstractServiceRegistryImpl.java:234) [hibernate-core-4.3.5.Final.jar:4.3.5.Final]
        at org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(AbstractServiceRegistryImpl.java:206) [hibernate-core-4.3.5.Final.jar:4.3.5.Final]
        at org.hibernate.cfg.Configuration.buildTypeRegistrations(Configuration.java:1885) [hibernate-core-4.3.5.Final.jar:4.3.5.Final]
        at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1843) [hibernate-core-4.3.5.Final.jar:4.3.5.Final]
        at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:850) [hibernate-entitymanager-4.3.5.Final.jar:4.3.5.Final]
        at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:843) [hibernate-entitymanager-4.3.5.Final.jar:4.3.5.Final]
        at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:397) [hibernate-core-4.3.5.Final.jar:4.3.5.Final]
        at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:842) [hibernate-entitymanager-4.3.5.Final.jar:4.3.5.Final]
        at org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44) [jipijapa-hibernate4-3-1.0.1.Final.jar:]
        at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:154) [wildfly-jpa-8.1.0.Final.jar:8.1.0.Final]
        ... 8 more
{noformat}

h3. Files

{code:xml|title=persistence.xml}
?xml version="1.0" encoding="UTF-8"?>
<persistence
    version="2.1"
    xmlns="http://xmlns.jcp.org/xml/ns/persistence"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence http://xmlns.jcp.org/xml/ns/persistence/persistence_2_1.xsd">
    
  <persistence-unit name="maars_db-pu" transaction-type="JTA">
    <jta-data-source>java:jboss/datasources/mycompany-ds</jta-data-source>
    <exclude-unlisted-classes>false</exclude-unlisted-classes>
    <properties>
         <property name="hibernate.dialect" value="com.mycompany.hibernate.MySQLBitBooleanDialect" />
     	 <property name="hibernate.hbm2ddl.auto" value="validate" />
         <property name="hibernate.show_sql" value="false" />
         <property name="hibernate.format_sql" value="false" />
    </properties>
  </persistence-unit>
</persistence>
{code}

h3. Related Issues
I thought this was because of https://hibernate.atlassian.net/browse/HHH-7084, but it looks like this was resolved a while ago.



--
This message was sent by Atlassian JIRA
(v6.3.1#6329)

From issues at jboss.org  Tue Oct 21 10:55:35 2014
From: issues at jboss.org (Bartosz Majsak (JIRA))
Date: Tue, 21 Oct 2014 10:55:35 -0400 (EDT)
Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1871) Improve documentation
	in arquillian spock
In-Reply-To: <JIRA.12555168.1413329575000@Atlassian.JIRA>
References: <JIRA.12555168.1413329575000@Atlassian.JIRA>
	<JIRA.12555168.1413329575000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12555168.1413329575000.20145.1413903335800@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ARQ-1871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bartosz Majsak updated ARQ-1871:
--------------------------------
        Status: Closed  (was: Pull Request Sent)
    Resolution: Done


[Pushed upstream|https://github.com/arquillian/arquillian-testrunner-spock/commit/fc26515aaaada16e2f91f1e348d1e8e5e9284cda].

> Improve documentation in arquillian spock
> -----------------------------------------
>
>                 Key: ARQ-1871
>                 URL: https://issues.jboss.org/browse/ARQ-1871
>             Project: Arquillian
>          Issue Type: Enhancement
>          Components: Spock TestRunner
>    Affects Versions: spock_1.0.0.Beta3
>            Reporter: John Ament
>            Assignee: Bartosz Majsak
>            Priority: Minor
>




--
This message was sent by Atlassian JIRA
(v6.3.1#6329)

From issues at jboss.org  Tue Oct 21 10:55:36 2014
From: issues at jboss.org (Bartosz Majsak (JIRA))
Date: Tue, 21 Oct 2014 10:55:36 -0400 (EDT)
Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1871) Improve documentation
	in arquillian spock
In-Reply-To: <JIRA.12555168.1413329575000@Atlassian.JIRA>
References: <JIRA.12555168.1413329575000@Atlassian.JIRA>
	<JIRA.12555168.1413329575000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12555168.1413329575000.20152.1413903336399@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ARQ-1871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bartosz Majsak reopened ARQ-1871:
---------------------------------


> Improve documentation in arquillian spock
> -----------------------------------------
>
>                 Key: ARQ-1871
>                 URL: https://issues.jboss.org/browse/ARQ-1871
>             Project: Arquillian
>          Issue Type: Enhancement
>          Components: Spock TestRunner
>    Affects Versions: spock_1.0.0.Beta3
>            Reporter: John Ament
>            Assignee: Bartosz Majsak
>            Priority: Minor
>




--
This message was sent by Atlassian JIRA
(v6.3.1#6329)

From issues at jboss.org  Tue Oct 21 10:55:36 2014
From: issues at jboss.org (Bartosz Majsak (JIRA))
Date: Tue, 21 Oct 2014 10:55:36 -0400 (EDT)
Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1871) Improve documentation
	in arquillian spock
In-Reply-To: <JIRA.12555168.1413329575000@Atlassian.JIRA>
References: <JIRA.12555168.1413329575000@Atlassian.JIRA>
	<JIRA.12555168.1413329575000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12555168.1413329575000.20156.1413903336741@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ARQ-1871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bartosz Majsak resolved ARQ-1871.
---------------------------------
    Resolution: Done


> Improve documentation in arquillian spock
> -----------------------------------------
>
>                 Key: ARQ-1871
>                 URL: https://issues.jboss.org/browse/ARQ-1871
>             Project: Arquillian
>          Issue Type: Enhancement
>          Components: Spock TestRunner
>    Affects Versions: spock_1.0.0.Beta3
>            Reporter: John Ament
>            Assignee: Bartosz Majsak
>            Priority: Minor
>




--
This message was sent by Atlassian JIRA
(v6.3.1#6329)

From issues at jboss.org  Tue Oct 21 10:56:35 2014
From: issues at jboss.org (Bartosz Majsak (JIRA))
Date: Tue, 21 Oct 2014 10:56:35 -0400 (EDT)
Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1871) Improve documentation
	in arquillian spock
In-Reply-To: <JIRA.12555168.1413329575000@Atlassian.JIRA>
References: <JIRA.12555168.1413329575000@Atlassian.JIRA>
	<JIRA.12555168.1413329575000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12555168.1413329575000.20160.1413903395577@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ARQ-1871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bartosz Majsak updated ARQ-1871:
--------------------------------
    Fix Version/s: spock_1.0.0.next


> Improve documentation in arquillian spock
> -----------------------------------------
>
>                 Key: ARQ-1871
>                 URL: https://issues.jboss.org/browse/ARQ-1871
>             Project: Arquillian
>          Issue Type: Enhancement
>          Components: Spock TestRunner
>    Affects Versions: spock_1.0.0.Beta3
>            Reporter: John Ament
>            Assignee: Bartosz Majsak
>            Priority: Minor
>             Fix For: spock_1.0.0.next
>
>




--
This message was sent by Atlassian JIRA
(v6.3.1#6329)

From issues at jboss.org  Wed Oct 22 09:17:35 2014
From: issues at jboss.org (Richard Rattigan (JIRA))
Date: Wed, 22 Oct 2014 09:17:35 -0400 (EDT)
Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1873) @ServerSetup annotation
 is not inherited by JUnit test classes.
In-Reply-To: <JIRA.12555784.1413983828000@Atlassian.JIRA>
References: <JIRA.12555784.1413983828000@Atlassian.JIRA>
	<JIRA.12555784.1413983828923@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12555784.1413983828000.22372.1413983855479@Atlassian.JIRA>

Richard Rattigan created ARQ-1873:
-------------------------------------

             Summary: @ServerSetup annotation is not inherited by JUnit test classes.
                 Key: ARQ-1873
                 URL: https://issues.jboss.org/browse/ARQ-1873
             Project: Arquillian
          Issue Type: Bug
    Affects Versions: 1.1.5.Final
         Environment: I'm using JUnit.
            Reporter: Richard Rattigan


Code below does not work as expected - {{MySetup}} is not run:

{code}
@ServerSetup(MySetup.class)
public class BaseTest {...}

public class MyTest1 extends BaseTest {...}

public class MyTest2 extends BaseTest {...}
{code}

Workaround is to repeat the annotation on every test class:

{code}
public class BaseTest {...}

@ServerSetup(MySetup.class)
public class MyTest1 extends BaseTest {...}

@ServerSetup(MySetup.class)
public class MyTest2 extends BaseTest {...}
{code}

I haven't tested this with other test frameworks, just JUnit.




--
This message was sent by Atlassian JIRA
(v6.3.1#6329)

From issues at jboss.org  Fri Oct 31 04:15:38 2014
From: issues at jboss.org (Karel Piwko (JIRA))
Date: Fri, 31 Oct 2014 04:15:38 -0400 (EDT)
Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1874) Allow Drone to skip
	session file creation
In-Reply-To: <JIRA.12556404.1414743329000@Atlassian.JIRA>
References: <JIRA.12556404.1414743329000@Atlassian.JIRA>
	<JIRA.12556404.1414743329474@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12556404.1414743329000.35993.1414743338529@Atlassian.JIRA>

Karel Piwko created ARQ-1874:
--------------------------------

             Summary: Allow Drone to skip session file creation
                 Key: ARQ-1874
                 URL: https://issues.jboss.org/browse/ARQ-1874
             Project: Arquillian
          Issue Type: Feature Request
          Components: Extension - Drone
    Affects Versions: drone_2.0.0.Alpha2
            Reporter: Karel Piwko


It should be possible not to touch filesystem and avoid creating session file if user wishes to do so.



--
This message was sent by Atlassian JIRA
(v6.3.1#6329)

From issues at jboss.org  Fri Oct 31 04:19:35 2014
From: issues at jboss.org (Karel Piwko (JIRA))
Date: Fri, 31 Oct 2014 04:19:35 -0400 (EDT)
Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1874) Allow Drone to skip
	session file creation
In-Reply-To: <JIRA.12556404.1414743329000@Atlassian.JIRA>
References: <JIRA.12556404.1414743329000@Atlassian.JIRA>
	<JIRA.12556404.1414743329000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12556404.1414743329000.35997.1414743575359@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ARQ-1874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Karel Piwko updated ARQ-1874:
-----------------------------
    Description: 
It should be possible not to touch filesystem and avoid creating session file if user wishes to do so.

Storage should be completely ignored if remoteReusable is not set.

  was:It should be possible not to touch filesystem and avoid creating session file if user wishes to do so.



> Allow Drone to skip session file creation
> -----------------------------------------
>
>                 Key: ARQ-1874
>                 URL: https://issues.jboss.org/browse/ARQ-1874
>             Project: Arquillian
>          Issue Type: Feature Request
>          Components: Extension - Drone
>    Affects Versions: drone_2.0.0.Alpha2
>            Reporter: Karel Piwko
>
> It should be possible not to touch filesystem and avoid creating session file if user wishes to do so.
> Storage should be completely ignored if remoteReusable is not set.



--
This message was sent by Atlassian JIRA
(v6.3.1#6329)

From issues at jboss.org  Fri Oct 31 04:19:35 2014
From: issues at jboss.org (Karel Piwko (JIRA))
Date: Fri, 31 Oct 2014 04:19:35 -0400 (EDT)
Subject: [arquillian-issues] [JBoss JIRA] (ARQ-1874) Allow Drone to skip
	session file creation
In-Reply-To: <JIRA.12556404.1414743329000@Atlassian.JIRA>
References: <JIRA.12556404.1414743329000@Atlassian.JIRA>
	<JIRA.12556404.1414743329000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12556404.1414743329000.35999.1414743575497@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ARQ-1874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Karel Piwko updated ARQ-1874:
-----------------------------
    Issue Type: Bug  (was: Feature Request)


> Allow Drone to skip session file creation
> -----------------------------------------
>
>                 Key: ARQ-1874
>                 URL: https://issues.jboss.org/browse/ARQ-1874
>             Project: Arquillian
>          Issue Type: Bug
>          Components: Extension - Drone
>    Affects Versions: drone_2.0.0.Alpha2
>            Reporter: Karel Piwko
>
> It should be possible not to touch filesystem and avoid creating session file if user wishes to do so.
> Storage should be completely ignored if remoteReusable is not set.



--
This message was sent by Atlassian JIRA
(v6.3.1#6329)