[JBoss JIRA] (ARQ-197) Research support for @Deployment on multiple levels
by MINNA HU (JIRA)
[ https://issues.jboss.org/browse/ARQ-197?page=com.atlassian.jira.plugin.sy... ]
MINNA HU commented on ARQ-197:
------------------------------
Our team is using Arquillian for our feature test, we would like to deploy the whole system at one time, and then run test classes that are created for different features. It will be really helpful to run @Deployment at test suite level. If the community can fix this feature test, it will benefit lots of users. Thank you~
> Research support for @Deployment on multiple levels
> ---------------------------------------------------
>
> Key: ARQ-197
> URL: https://issues.jboss.org/browse/ARQ-197
> Project: Arquillian
> Issue Type: Feature Request
> Components: Base Implementation
> Reporter: Aslak Knutsen
> Priority: Critical
> Fix For: 2.0.0.CR1
>
>
> One deployment pr TestCase might not always be the ideal solution. Research how we can deploy multiple TestCases with one Deployment and test them all at once.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 6 months
[JBoss JIRA] (ARQGRA-454) NPE in WebElementEnricher.enrich() with Arquillian 1.1.5.Final
by Juraj Húska (JIRA)
[ https://issues.jboss.org/browse/ARQGRA-454?page=com.atlassian.jira.plugin... ]
Juraj Húska commented on ARQGRA-454:
------------------------------------
Hello Juergen,
all tests for Graphene work with Arquillian core {{1.1.5.Final}} and {{Arquillian Drone 1.3.1.Final}}.
Could you please provide us a test case where you are getting this error ?
> NPE in WebElementEnricher.enrich() with Arquillian 1.1.5.Final
> --------------------------------------------------------------
>
> Key: ARQGRA-454
> URL: https://issues.jboss.org/browse/ARQGRA-454
> Project: Arquillian Graphene
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: core
> Affects Versions: 2.0.3.Final
> Reporter: Juergen Zimmermann
>
> I'm getting a GrapheneTestEnricherException caused by a NPE (see stacktrace below) after upgrading Arquillian to 1.1.5.Final. The issue doesn't exist with Arquillian 1.1.4.Final.
> The stacktrace:
> {code}
> org.jboss.arquillian.graphene.enricher.exception.GrapheneTestEnricherException:
> Error while initializing: class de.shop.util.IndexPage
> at org.jboss.arquillian.graphene.location.LocationEnricher.goTo(LocationEnricher.java:78)
> at org.jboss.arquillian.graphene.DefaultGrapheneRuntime.goTo(DefaultGrapheneRuntime.java:125)
> at org.jboss.arquillian.graphene.DefaultGrapheneRuntime.goTo(DefaultGrapheneRuntime.java:120)
> at org.jboss.arquillian.graphene.Graphene.goTo(Graphene.java:291)
> at de.shop.util.AbstractWebTest.before(AbstractWebTest.java:54)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:483)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:267)
> 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.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> Caused by: java.lang.NullPointerException
> at org.jboss.arquillian.graphene.enricher.WebElementEnricher.enrich(WebElementEnricher.java:68)
> at org.jboss.arquillian.graphene.enricher.AbstractSearchContextEnricher.enrichRecursively(AbstractSearchContextEnricher.java:73)
> at org.jboss.arquillian.graphene.enricher.PageObjectEnricher.setupPage(PageObjectEnricher.java:97)
> at org.jboss.arquillian.graphene.location.LocationEnricher.goTo(LocationEnricher.java:76)
> ... 34 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 6 months
[JBoss JIRA] (ARQGRA-454) NPE in WebElementEnricher.enrich() with Arquillian 1.1.5.Final
by Juraj Húska (JIRA)
[ https://issues.jboss.org/browse/ARQGRA-454?page=com.atlassian.jira.plugin... ]
Juraj Húska edited comment on ARQGRA-454 at 6/30/14 11:49 AM:
--------------------------------------------------------------
Hello Juergen,
all tests for Graphene pass with Arquillian core {{1.1.5.Final}} and {{Arquillian Drone 1.3.1.Final}}.
Could you please provide us a test case where you are getting this error ?
was (Author: jhuska):
Hello Juergen,
all tests for Graphene work with Arquillian core {{1.1.5.Final}} and {{Arquillian Drone 1.3.1.Final}}.
Could you please provide us a test case where you are getting this error ?
> NPE in WebElementEnricher.enrich() with Arquillian 1.1.5.Final
> --------------------------------------------------------------
>
> Key: ARQGRA-454
> URL: https://issues.jboss.org/browse/ARQGRA-454
> Project: Arquillian Graphene
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: core
> Affects Versions: 2.0.3.Final
> Reporter: Juergen Zimmermann
>
> I'm getting a GrapheneTestEnricherException caused by a NPE (see stacktrace below) after upgrading Arquillian to 1.1.5.Final. The issue doesn't exist with Arquillian 1.1.4.Final.
> The stacktrace:
> {code}
> org.jboss.arquillian.graphene.enricher.exception.GrapheneTestEnricherException:
> Error while initializing: class de.shop.util.IndexPage
> at org.jboss.arquillian.graphene.location.LocationEnricher.goTo(LocationEnricher.java:78)
> at org.jboss.arquillian.graphene.DefaultGrapheneRuntime.goTo(DefaultGrapheneRuntime.java:125)
> at org.jboss.arquillian.graphene.DefaultGrapheneRuntime.goTo(DefaultGrapheneRuntime.java:120)
> at org.jboss.arquillian.graphene.Graphene.goTo(Graphene.java:291)
> at de.shop.util.AbstractWebTest.before(AbstractWebTest.java:54)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:483)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:267)
> 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.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> Caused by: java.lang.NullPointerException
> at org.jboss.arquillian.graphene.enricher.WebElementEnricher.enrich(WebElementEnricher.java:68)
> at org.jboss.arquillian.graphene.enricher.AbstractSearchContextEnricher.enrichRecursively(AbstractSearchContextEnricher.java:73)
> at org.jboss.arquillian.graphene.enricher.PageObjectEnricher.setupPage(PageObjectEnricher.java:97)
> at org.jboss.arquillian.graphene.location.LocationEnricher.goTo(LocationEnricher.java:76)
> ... 34 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 6 months
[JBoss JIRA] (ARQ-453) Support Apache HTTPD as a DeployableContainer in Managed mode
by Stefan Miklosovic (JIRA)
[ https://issues.jboss.org/browse/ARQ-453?page=com.atlassian.jira.plugin.sy... ]
Stefan Miklosovic commented on ARQ-453:
---------------------------------------
[~ozizka] [~rrajesh] ([~aslak])
feel free to extend https://github.com/smiklosovic/arquillian-container-apache, I am done with this as I do not know how to advance with problems I described there, maybe some topic for gsoc or bachelor thesis?
> Support Apache HTTPD as a DeployableContainer in Managed mode
> -------------------------------------------------------------
>
> Key: ARQ-453
> URL: https://issues.jboss.org/browse/ARQ-453
> Project: Arquillian
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Apache HTTPD Containers
> Reporter: Ondrej Zizka
> Fix For: httpd_1.0.0.next
>
>
> The DeployableContainer interface provided by Arquillian offer a simple abstraction over something that you can setup, start or stop. In addition it can support deploy and undeploy.
> The same logic can be applied to pure services, e.g. Mail, Database or FTP servers.
> The Apache HTTPD server adapter is a DeployableContainer implementation that control the lifecycle of a local Apache HTTP Server. The Adapter support adding additional HTTPD configuration during setup, and rely on calling out to the command line when starting and stopping the server. The Adapter work with both Windows and Linux based systems.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 6 months
[JBoss JIRA] (ARQ-453) Support Apache HTTPD as a DeployableContainer in Managed mode
by Stefan Miklosovic (JIRA)
[ https://issues.jboss.org/browse/ARQ-453?page=com.atlassian.jira.plugin.sy... ]
Stefan Miklosovic edited comment on ARQ-453 at 6/29/14 7:09 PM:
----------------------------------------------------------------
[~ozizka]
I am willing to code this adapter since with the existence of Arquillian Spacelift project it should be easy, however I do not know how to deal with these problems:
1) In case of managed container, this container has to exist prior to test execution so Apache server has to be installed somewhere in file system. When you take out-of-box installation of http server (e.g. in Fedora) you have to have root permissions to copy some files to /var/www. However, when you run a test, you do not have these write permissions. You would have to somehow manually tweak them before and it is just error prone approach.
Starting and stopping of HTTPD server needs root as well.
2) In case you would take HTTP server with you in container adapter itself, you would have to compile it in advance with some prefix (1) but you do not know in advance how this prefix should look like. And you would have to potentially take into consideration various architectures when compiling (x86_64, i686 ... you name it)
(1) https://httpd.apache.org/docs/2.4/install.html#configure
was (Author: smikloso):
[~ozizka]
I am willing to code this adapter since with the existence of Arquillian Spacelift project it should be easy, however I do not know how to deal with these problems:
1) In case of managed container, this container has to exist prior to test execution so Apache server has to be installed somewhere in file system. When you take out-of-box installation of http server (e.g. in Fedora) you have to have root permissions to copy some files to /var/www. However, when you run a test, you do not have these write permissions. You would have to somehow manually tweak them before and it is just error prone approach.
2) In case you would take HTTP server with you in container adapter itself, you would have to compile it in advance with some prefix (1) but you do not know in advance how this prefix should look like. And you would have to potentially take into consideration various architectures when compiling (x86_64, i686 ... you name it)
(1) https://httpd.apache.org/docs/2.4/install.html#configure
> Support Apache HTTPD as a DeployableContainer in Managed mode
> -------------------------------------------------------------
>
> Key: ARQ-453
> URL: https://issues.jboss.org/browse/ARQ-453
> Project: Arquillian
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Apache HTTPD Containers
> Reporter: Ondrej Zizka
> Fix For: httpd_1.0.0.next
>
>
> The DeployableContainer interface provided by Arquillian offer a simple abstraction over something that you can setup, start or stop. In addition it can support deploy and undeploy.
> The same logic can be applied to pure services, e.g. Mail, Database or FTP servers.
> The Apache HTTPD server adapter is a DeployableContainer implementation that control the lifecycle of a local Apache HTTP Server. The Adapter support adding additional HTTPD configuration during setup, and rely on calling out to the command line when starting and stopping the server. The Adapter work with both Windows and Linux based systems.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 6 months
[JBoss JIRA] (ARQ-453) Support Apache HTTPD as a DeployableContainer in Managed mode
by Stefan Miklosovic (JIRA)
[ https://issues.jboss.org/browse/ARQ-453?page=com.atlassian.jira.plugin.sy... ]
Stefan Miklosovic commented on ARQ-453:
---------------------------------------
[~ozizka]
I am willing to code this adapter since with the existence of Arquillian Spacelift project it should be easy, however I do not know how to deal with these problems:
1) In case of managed container, this container has to exist prior to test execution so Apache server has to be installed somewhere in file system. When you take out-of-box installation of http server (e.g. in Fedora) you have to have root permissions to copy some files to /var/www. However, when you run a test, you do not have these write permissions. You would have to somehow manually tweak them before and it is just error prone approach.
2) In case you would take HTTP server with you in container adapter itself, you would have to compile it in advance with some prefix (1) but you do not know in advance how this prefix should look like. And you would have to potentially take into consideration various architectures when compiling (x86_64, i686 ... you name it)
(1) https://httpd.apache.org/docs/2.4/install.html#configure
> Support Apache HTTPD as a DeployableContainer in Managed mode
> -------------------------------------------------------------
>
> Key: ARQ-453
> URL: https://issues.jboss.org/browse/ARQ-453
> Project: Arquillian
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Apache HTTPD Containers
> Reporter: Ondrej Zizka
> Fix For: httpd_1.0.0.next
>
>
> The DeployableContainer interface provided by Arquillian offer a simple abstraction over something that you can setup, start or stop. In addition it can support deploy and undeploy.
> The same logic can be applied to pure services, e.g. Mail, Database or FTP servers.
> The Apache HTTPD server adapter is a DeployableContainer implementation that control the lifecycle of a local Apache HTTP Server. The Adapter support adding additional HTTPD configuration during setup, and rely on calling out to the command line when starting and stopping the server. The Adapter work with both Windows and Linux based systems.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 6 months
[JBoss JIRA] (ARQ-453) Support Apache HTTPD as a DeployableContainer in Managed mode
by Stefan Miklosovic (JIRA)
[ https://issues.jboss.org/browse/ARQ-453?page=com.atlassian.jira.plugin.sy... ]
Stefan Miklosovic updated ARQ-453:
----------------------------------
Assignee: (was: Stefan Miklosovic)
> Support Apache HTTPD as a DeployableContainer in Managed mode
> -------------------------------------------------------------
>
> Key: ARQ-453
> URL: https://issues.jboss.org/browse/ARQ-453
> Project: Arquillian
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Apache HTTPD Containers
> Reporter: Ondrej Zizka
> Fix For: httpd_1.0.0.next
>
>
> The DeployableContainer interface provided by Arquillian offer a simple abstraction over something that you can setup, start or stop. In addition it can support deploy and undeploy.
> The same logic can be applied to pure services, e.g. Mail, Database or FTP servers.
> The Apache HTTPD server adapter is a DeployableContainer implementation that control the lifecycle of a local Apache HTTP Server. The Adapter support adding additional HTTPD configuration during setup, and rely on calling out to the command line when starting and stopping the server. The Adapter work with both Windows and Linux based systems.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 6 months
[JBoss JIRA] (ARQ-453) Support Apache HTTPD as a DeployableContainer in Managed mode
by Stefan Miklosovic (JIRA)
[ https://issues.jboss.org/browse/ARQ-453?page=com.atlassian.jira.plugin.sy... ]
Stefan Miklosovic reassigned ARQ-453:
-------------------------------------
Assignee: Stefan Miklosovic
> Support Apache HTTPD as a DeployableContainer in Managed mode
> -------------------------------------------------------------
>
> Key: ARQ-453
> URL: https://issues.jboss.org/browse/ARQ-453
> Project: Arquillian
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Apache HTTPD Containers
> Reporter: Ondrej Zizka
> Assignee: Stefan Miklosovic
> Fix For: httpd_1.0.0.next
>
>
> The DeployableContainer interface provided by Arquillian offer a simple abstraction over something that you can setup, start or stop. In addition it can support deploy and undeploy.
> The same logic can be applied to pure services, e.g. Mail, Database or FTP servers.
> The Apache HTTPD server adapter is a DeployableContainer implementation that control the lifecycle of a local Apache HTTP Server. The Adapter support adding additional HTTPD configuration during setup, and rely on calling out to the command line when starting and stopping the server. The Adapter work with both Windows and Linux based systems.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 6 months
[JBoss JIRA] (ARQ-1581) Droidium does not work with remote emulators
by Stefan Miklosovic (JIRA)
[ https://issues.jboss.org/browse/ARQ-1581?page=com.atlassian.jira.plugin.s... ]
Stefan Miklosovic closed ARQ-1581.
----------------------------------
> Droidium does not work with remote emulators
> --------------------------------------------
>
> Key: ARQ-1581
> URL: https://issues.jboss.org/browse/ARQ-1581
> Project: Arquillian
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Extension - Droidium
> Affects Versions: droidium_1.0.0.Alpha2
> Reporter: Karel Piwko
> Assignee: Stefan Miklosovic
>
> *When*:
> I use Android Jenkins Plugin to start the device
> *Then*:
> It starts the emulator using remote syntax, that is including --port port1,port2
> *Expect*:
> Drodium will connect to already running emulator.
> *Actual problem*:
> AndroidDevice and IDevice isEmulator() call is not able to parse the data retrieved from adb devices. This results into Droidium trying to start emulator with the same name, however this emulator is already started so event marking correct startup is never send and test fails.
> Output:
> {code}
> export ANDROID_ADB_SERVER_PORT=52892
> [tester@fedora19 ~]$ ANDROID_SDK_HOME=`pwd`/workspace/mobile-eap-test ./tools/android-sdk/platform-tools/adb devices
> List of devices attached
> localhost:46689 device
> {code}
> However, emulators are expected to be in format of emulator-XYZ.
> Drodium should be able to modify the behavior to handle this correctly.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 6 months