[JBoss JIRA] (ARQ-1494) Warp: fails when ProxyURLProvider is called more than once per test
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/ARQ-1494?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč updated ARQ-1494:
----------------------------
Fix Version/s: warp_1.0.0.Alpha5
(was: warp_1.0.0.Beta1)
> Warp: fails when ProxyURLProvider is called more than once per test
> -------------------------------------------------------------------
>
> Key: ARQ-1494
> URL: https://issues.jboss.org/browse/ARQ-1494
> Project: Arquillian
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Extension - Warp
> Affects Versions: warp_1.0.0.Alpha4
> Reporter: Lukáš Fryč
> Assignee: Lukáš Fryč
> Fix For: warp_1.0.0.Alpha5
>
>
> Conflicts with Graphene Beta2:
> {code}
> java.lang.RuntimeException: Could not lookup value for field private java.net.URL org.richfaces.integration.javascript.ITJavaScriptServiceAjax.contextPath
> at org.jboss.arquillian.test.impl.enricher.resource.ArquillianResourceTestEnricher.enrich(ArquillianResourceTestEnricher.java:61)
> at org.jboss.arquillian.test.impl.TestInstanceEnricher.enrich(TestInstanceEnricher.java:52)
> at org.jboss.arquillian.container.test.impl.ClientTestInstanceEnricher.enrich(ClientTestInstanceEnricher.java:51)
> 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.invokeObservers(EventContextImpl.java:99)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142)
> at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createBeforeContext(ContainerEventController.java:124)
> 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:89)
> 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:75)
> 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:60)
> 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:135)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
> at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.before(EventTestRunnerAdaptor.java:95)
> at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:222)
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
> at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
> at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:240)
> 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:185)
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
> at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
> at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:199)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
> at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
> Caused by: java.lang.IllegalStateException: The OperatiocalContext was already set for URL: http://127.0.0.1:18080
> at org.jboss.arquillian.warp.impl.client.proxy.ProxyURLToContextMapping.register(ProxyURLToContextMapping.java:38)
> at org.jboss.arquillian.warp.impl.client.proxy.ClassProxyUsageTracker.registerOperationalContextToUrl(ClassProxyUsageTracker.java:54)
> 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.invokeObservers(EventContextImpl.java:99)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
> at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> at org.jboss.arquillian.warp.impl.client.proxy.ProxyURLProvider.getProxyUrl(ProxyURLProvider.java:82)
> at org.jboss.arquillian.warp.impl.client.proxy.ProxyURLProvider.lookup(ProxyURLProvider.java:71)
> at org.jboss.arquillian.test.impl.enricher.resource.ArquillianResourceTestEnricher.lookup(ArquillianResourceTestEnricher.java:112)
> at org.jboss.arquillian.test.impl.enricher.resource.ArquillianResourceTestEnricher.enrich(ArquillianResourceTestEnricher.java:57)
> ... 65 more
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (ARQ-1422) Add support for using Warp with ear deployments
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/ARQ-1422?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč closed ARQ-1422.
---------------------------
> Add support for using Warp with ear deployments
> -----------------------------------------------
>
> Key: ARQ-1422
> URL: https://issues.jboss.org/browse/ARQ-1422
> Project: Arquillian
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Extension - Warp
> Affects Versions: warp_1.0.0.Alpha3
> Environment: Win7, JBoss AS 7.2
> Reporter: Robert Panzer
> Assignee: Robert Panzer
> Fix For: warp_1.0.0.Alpha4
>
>
> The web filter WarpFilter is currently added to the auxiliary jars that are add as ear libs in case the deployment is an ear so that the filter is not deployed.
> The WarpFilter should be deployed as a web fragment of the web application under test to function properly when testing a war that is contained in an ear.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (ARQ-1430) Warp does not take superclass into account when scanning for @WarpTest
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/ARQ-1430?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč closed ARQ-1430.
---------------------------
> Warp does not take superclass into account when scanning for @WarpTest
> -----------------------------------------------------------------------
>
> Key: ARQ-1430
> URL: https://issues.jboss.org/browse/ARQ-1430
> Project: Arquillian
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Extension - Warp
> Affects Versions: warp_1.0.0.Alpha3
> Reporter: Aslak Knutsen
> Assignee: Lukáš Fryč
> Priority: Minor
> Fix For: warp_1.0.0.Alpha4
>
> Original Estimate: 1 hour
> Remaining Estimate: 1 hour
>
> *Given*
> {code}
> @WarpTest
> @RunAsClient
> public abstract class BaseRepositoryResourceBehavior<DOMAIN extends Identifiable> {
> ...
> }
> @RunWith(Arquillian.class)
> public class ConferenceResourceBehaviorTestCase extends BaseRepositoryResourceBehavior<Conference> {
> ...
> }
> {code}
> *Then*
> {code}
> java.lang.IllegalStateException: The Warp runtime isn't initialized. You need to annotate a test class with @WarpTest in order to initialize Warp.
> at org.jboss.arquillian.warp.Warp.initiate(Warp.java:41)
> at org.cedj.geekseek.web.rest.core.test.integration.resource.BaseRepositoryResourceBehavior.shouldHandleMissingResource(BaseRepositoryResourceBehavior.java:61)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (ARQ-1534) There is no way how to set server port of Android Debug Bridge
by Stefan Miklosovic (JIRA)
[ https://issues.jboss.org/browse/ARQ-1534?page=com.atlassian.jira.plugin.s... ]
Stefan Miklosovic reassigned ARQ-1534:
--------------------------------------
Assignee: Stefan Miklosovic
> There is no way how to set server port of Android Debug Bridge
> --------------------------------------------------------------
>
> Key: ARQ-1534
> URL: https://issues.jboss.org/browse/ARQ-1534
> 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
>
> *Given*:
> I have Android tooling installed in Eclipse/JBDS.
> *When:*
> I use Droidium in tests fro IDE.
> *Expect*:
> No having any errors in DDMS output in IDE.
> *Additional information*:
> It looks like that the problem is that Droidium does not allow to set android bridge server port and hence DDMS is already connected to given port. This leads to various errors logged, as DDMS is not prepared to handle external process changing it's environment on the fly.
> See AndroidDebugBridge.determineAndValidateAdbPort() method for more details. While Drodium allows you to change adbPort for running emulator, it always runs the bridge on default port 5037.
> We need a way how to change this server port in Droidium configuration.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (ARQ-1534) There is no way how to set server port of Android Debug Bridge
by Karel Piwko (JIRA)
Karel Piwko created ARQ-1534:
--------------------------------
Summary: There is no way how to set server port of Android Debug Bridge
Key: ARQ-1534
URL: https://issues.jboss.org/browse/ARQ-1534
Project: Arquillian
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Extension - Droidium
Affects Versions: droidium_1.0.0.Alpha2
Reporter: Karel Piwko
*Given*:
I have Android tooling installed in Eclipse/JBDS.
*When:*
I use Droidium in tests fro IDE.
*Expect*:
No having any errors in DDMS output in IDE.
*Additional information*:
It looks like that the problem is that Droidium does not allow to set android bridge server port and hence DDMS is already connected to given port. This leads to various errors logged, as DDMS is not prepared to handle external process changing it's environment on the fly.
See AndroidDebugBridge.determineAndValidateAdbPort() method for more details. While Drodium allows you to change adbPort for running emulator, it always runs the bridge on default port 5037.
We need a way how to change this server port in Droidium configuration.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (ARQ-1533) Uninstall packages from device before test when they are already installed
by Stefan Miklosovic (JIRA)
[ https://issues.jboss.org/browse/ARQ-1533?page=com.atlassian.jira.plugin.s... ]
Stefan Miklosovic reassigned ARQ-1533:
--------------------------------------
Assignee: Stefan Miklosovic
> Uninstall packages from device before test when they are already installed
> --------------------------------------------------------------------------
>
> Key: ARQ-1533
> URL: https://issues.jboss.org/browse/ARQ-1533
> Project: Arquillian
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Extension - Droidium
> Affects Versions: droidium_1.0.0.Alpha2
> Reporter: Stefan Miklosovic
> Assignee: Stefan Miklosovic
>
> Given: Android device prior to test.
> When: I run test with packages to be installed which are already in Android device.
> I expect: old packages will be uninstalled and packages from current test run will be installed
> This situation can happen if something really horrible happens and whole test fails in the middle so packages are not uninstalled (Selendroid server and ordinary apks as well). When I run tests for the second time, I want that packages will be removed and installed once again to get them fresh.
> Example: We could use different rebuilt Selendroid server which has the same package name but it is rebuilt for another application.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (ARQ-1533) Uninstall packages from device before test when they are already installed
by Stefan Miklosovic (JIRA)
Stefan Miklosovic created ARQ-1533:
--------------------------------------
Summary: Uninstall packages from device before test when they are already installed
Key: ARQ-1533
URL: https://issues.jboss.org/browse/ARQ-1533
Project: Arquillian
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Extension - Droidium
Affects Versions: droidium_1.0.0.Alpha2
Reporter: Stefan Miklosovic
Given: Android device prior to test.
When: I run test with packages to be installed which are already in Android device.
I expect: old packages will be uninstalled and packages from current test run will be installed
This situation can happen if something really horrible happens and whole test fails in the middle so packages are not uninstalled (Selendroid server and ordinary apks as well). When I run tests for the second time, I want that packages will be removed and installed once again to get them fresh.
Example: We could use different rebuilt Selendroid server which has the same package name but it is rebuilt for another application.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months