[JBoss JIRA] (ARQ-1569) CLONE - domain container - exception when connecting to existing domain without any servers
by Martin Simka (JIRA)
[ https://issues.jboss.org/browse/ARQ-1569?page=com.atlassian.jira.plugin.s... ]
Martin Simka resolved ARQ-1569.
-------------------------------
Resolution: Rejected
sorry about this, cloned issue created by mistake
> CLONE - domain container - exception when connecting to existing domain without any servers
> -------------------------------------------------------------------------------------------
>
> Key: ARQ-1569
> URL: https://issues.jboss.org/browse/ARQ-1569
> Project: Arquillian
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JBoss AS Containers
> Affects Versions: 1.1.1.Final
> Environment: remote domain without any servers
> arquillian-bom 1.1.1.Final
> jboss-as-arquillian-container-domain-remote 7.2.0.Final
> Reporter: Martin Simka
>
> {noformat}
> (E) ManagerProcessing
> (O) LoadableExtensionLoader.load
> (E) ServiceLoader
> (E) ManagerStarted
> (O) ConfigurationRegistrar.loadConfiguration
> (E) ArquillianDescriptor
> (O) ContainerRegistryCreator.createRegistry
> (E) ContainerRegistry
> (O) ProtocolRegistryCreator.createRegistry
> (E) ProtocolRegistry
> (E) BeforeSuite
> (I) TestContextHandler.createSuiteContext
> (O) ContainerEventController.execute
> (E) ContainerMultiControlEvent
> (O) ContainerLifecycleController.setupContainers
> (E) SetupContainer
> (I) ContainerDeploymentContextHandler.createContainerContext
> (O) ContainerLifecycleController.setupContainer
> (E) BeforeSetup
> (E) Container
> (E) AfterSetup
> (O) ClientContainerControllerCreator.createClientSideContainerController
> (E) ContainerController
> (O) ClientDeployerCreator.createClientSideDeployer
> (E) Deployer
> (E) ContainerMultiControlEvent
> (O) ContainerLifecycleController.startSuiteContainers
> (E) StartContainer
> (I) ContainerDeploymentContextHandler.createContainerContext
> (O) ContainerLifecycleController.startContainer
> (E) BeforeStart
> (E) ManagementClient
> (E) ArchiveDeployer
> (E) IllegalArgumentException
> (E) IllegalArgumentException
> (E) IllegalArgumentException
> (E) IllegalArgumentException
> (E) IllegalArgumentException
> (E) IllegalArgumentException
> java.lang.IllegalArgumentException: null
> at org.jboss.dmr.ModelValue.getKeys(ModelValue.java:124)
> at org.jboss.dmr.ModelNode.keys(ModelNode.java:1194)
> at org.jboss.as.arquillian.container.domain.ManagementClient.createDomain(ManagementClient.java:116)
> at org.jboss.as.arquillian.container.domain.CommonDomainDeployableContainer.start(CommonDomainDeployableContainer.java:126)
> at org.jboss.arquillian.container.impl.ContainerImpl.start(ContainerImpl.java:199)
> at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:163)
> at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:157)
> at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forContainer(ContainerLifecycleController.java:255)
> at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startContainer(ContainerLifecycleController.java:156)
> 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:601)
> 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.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57)
> 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:601)
> 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.core.impl.EventImpl.fire(EventImpl.java:67)
> at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:77)
> at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:70)
> at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forEachSuiteContainer(ContainerLifecycleController.java:221)
> at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startSuiteContainers(ContainerLifecycleController.java:69)
> 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:601)
> 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.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:86)
> 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:601)
> 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.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:601)
> 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.beforeSuite(EventTestRunnerAdaptor.java:68)
> at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:97)
> 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 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:601)
> at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray2(ReflectionUtils.java:208)
> at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:159)
> at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:87)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:95)
> {noformat}
--
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
11 years, 2 months
[JBoss JIRA] (ARQ-1569) CLONE - domain container - exception when connecting to existing domain without any servers
by Martin Simka (JIRA)
Martin Simka created ARQ-1569:
---------------------------------
Summary: CLONE - domain container - exception when connecting to existing domain without any servers
Key: ARQ-1569
URL: https://issues.jboss.org/browse/ARQ-1569
Project: Arquillian
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: JBoss AS Containers
Affects Versions: 1.1.1.Final
Environment: remote domain without any servers
arquillian-bom 1.1.1.Final
jboss-as-arquillian-container-domain-remote 7.2.0.Final
Reporter: Martin Simka
{noformat}
(E) ManagerProcessing
(O) LoadableExtensionLoader.load
(E) ServiceLoader
(E) ManagerStarted
(O) ConfigurationRegistrar.loadConfiguration
(E) ArquillianDescriptor
(O) ContainerRegistryCreator.createRegistry
(E) ContainerRegistry
(O) ProtocolRegistryCreator.createRegistry
(E) ProtocolRegistry
(E) BeforeSuite
(I) TestContextHandler.createSuiteContext
(O) ContainerEventController.execute
(E) ContainerMultiControlEvent
(O) ContainerLifecycleController.setupContainers
(E) SetupContainer
(I) ContainerDeploymentContextHandler.createContainerContext
(O) ContainerLifecycleController.setupContainer
(E) BeforeSetup
(E) Container
(E) AfterSetup
(O) ClientContainerControllerCreator.createClientSideContainerController
(E) ContainerController
(O) ClientDeployerCreator.createClientSideDeployer
(E) Deployer
(E) ContainerMultiControlEvent
(O) ContainerLifecycleController.startSuiteContainers
(E) StartContainer
(I) ContainerDeploymentContextHandler.createContainerContext
(O) ContainerLifecycleController.startContainer
(E) BeforeStart
(E) ManagementClient
(E) ArchiveDeployer
(E) IllegalArgumentException
(E) IllegalArgumentException
(E) IllegalArgumentException
(E) IllegalArgumentException
(E) IllegalArgumentException
(E) IllegalArgumentException
java.lang.IllegalArgumentException: null
at org.jboss.dmr.ModelValue.getKeys(ModelValue.java:124)
at org.jboss.dmr.ModelNode.keys(ModelNode.java:1194)
at org.jboss.as.arquillian.container.domain.ManagementClient.createDomain(ManagementClient.java:116)
at org.jboss.as.arquillian.container.domain.CommonDomainDeployableContainer.start(CommonDomainDeployableContainer.java:126)
at org.jboss.arquillian.container.impl.ContainerImpl.start(ContainerImpl.java:199)
at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:163)
at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:157)
at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forContainer(ContainerLifecycleController.java:255)
at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startContainer(ContainerLifecycleController.java:156)
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:601)
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.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57)
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:601)
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.core.impl.EventImpl.fire(EventImpl.java:67)
at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:77)
at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:70)
at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forEachSuiteContainer(ContainerLifecycleController.java:221)
at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startSuiteContainers(ContainerLifecycleController.java:69)
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:601)
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.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:86)
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:601)
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.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:601)
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.beforeSuite(EventTestRunnerAdaptor.java:68)
at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:97)
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 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:601)
at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray2(ReflectionUtils.java:208)
at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:159)
at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:87)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:95)
{noformat}
--
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
11 years, 2 months
[JBoss JIRA] (ARQ-1568) Droidium fails if emulator is about to start and there is not API level 10 and apiLevel is not in config
by Stefan Miklosovic (JIRA)
[ https://issues.jboss.org/browse/ARQ-1568?page=com.atlassian.jira.plugin.s... ]
Stefan Miklosovic resolved ARQ-1568.
------------------------------------
Resolution: Done
https://github.com/arquillian/arquillian-droidium/commit/7538803ac3b017a0...
> Droidium fails if emulator is about to start and there is not API level 10 and apiLevel is not in config
> --------------------------------------------------------------------------------------------------------
>
> Key: ARQ-1568
> URL: https://issues.jboss.org/browse/ARQ-1568
> Project: Arquillian
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Extension - Droidium
> Affects Versions: droidium_1.0.0.Alpha2
> Reporter: Stefan Miklosovic
> Assignee: Stefan Miklosovic
> Fix For: droidium_1.0.0.Alpha3
>
>
> Given:
> 1. Already existing emulator with API level != 10 available
> 2. Emulator is not started prior to tests
> 3. API level 10 is not installed locally on developers machine
> 4. apiLevel configuration option is not set in arquillian.xml
> When:
> I want to start emulator with the environment above
> Then:
> Droidium does not fail.
> The reason why it fails is that in case AVD of such name in avdName property does not exist, Droidium tries to create AVD dynamically and it is deleted after tests. Default API level is 10 so when apiLevel is not specified, it attempts to create emulator with that API level, but it might not be present on the system - so it fails.
> The workaround could be to filter all available API level and choose the lowest one as the default one and not API level 10 which is set statically.
--
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
11 years, 2 months
[JBoss JIRA] (ARQ-1568) Droidium fails if emulator is about to start and there is not API level 10 and apiLevel is not in config
by Stefan Miklosovic (JIRA)
[ https://issues.jboss.org/browse/ARQ-1568?page=com.atlassian.jira.plugin.s... ]
Stefan Miklosovic updated ARQ-1568:
-----------------------------------
Fix Version/s: droidium_1.0.0.Alpha3
> Droidium fails if emulator is about to start and there is not API level 10 and apiLevel is not in config
> --------------------------------------------------------------------------------------------------------
>
> Key: ARQ-1568
> URL: https://issues.jboss.org/browse/ARQ-1568
> Project: Arquillian
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Extension - Droidium
> Affects Versions: droidium_1.0.0.Alpha2
> Reporter: Stefan Miklosovic
> Assignee: Stefan Miklosovic
> Fix For: droidium_1.0.0.Alpha3
>
>
> Given:
> 1. Already existing emulator with API level != 10 available
> 2. Emulator is not started prior to tests
> 3. API level 10 is not installed locally on developers machine
> 4. apiLevel configuration option is not set in arquillian.xml
> When:
> I want to start emulator with the environment above
> Then:
> Droidium does not fail.
> The reason why it fails is that in case AVD of such name in avdName property does not exist, Droidium tries to create AVD dynamically and it is deleted after tests. Default API level is 10 so when apiLevel is not specified, it attempts to create emulator with that API level, but it might not be present on the system - so it fails.
> The workaround could be to filter all available API level and choose the lowest one as the default one and not API level 10 which is set statically.
--
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
11 years, 2 months
[JBoss JIRA] (ARQ-1568) Droidium fails if emulator is about to start and there is not API level 10 and apiLevel is not in config
by Stefan Miklosovic (JIRA)
[ https://issues.jboss.org/browse/ARQ-1568?page=com.atlassian.jira.plugin.s... ]
Stefan Miklosovic updated ARQ-1568:
-----------------------------------
Affects Version/s: droidium_1.0.0.Alpha2
> Droidium fails if emulator is about to start and there is not API level 10 and apiLevel is not in config
> --------------------------------------------------------------------------------------------------------
>
> Key: ARQ-1568
> URL: https://issues.jboss.org/browse/ARQ-1568
> Project: Arquillian
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Extension - Droidium
> Affects Versions: droidium_1.0.0.Alpha2
> Reporter: Stefan Miklosovic
> Assignee: Stefan Miklosovic
>
> Given:
> 1. Already existing emulator with API level != 10 available
> 2. Emulator is not started prior to tests
> 3. API level 10 is not installed locally on developers machine
> 4. apiLevel configuration option is not set in arquillian.xml
> When:
> I want to start emulator with the environment above
> Then:
> Droidium does not fail.
> The reason why it fails is that in case AVD of such name in avdName property does not exist, Droidium tries to create AVD dynamically and it is deleted after tests. Default API level is 10 so when apiLevel is not specified, it attempts to create emulator with that API level, but it might not be present on the system - so it fails.
> The workaround could be to filter all available API level and choose the lowest one as the default one and not API level 10 which is set statically.
--
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
11 years, 2 months
[JBoss JIRA] (ARQ-1568) Droidium fails if emulator is about to start and there is not API level 10 and apiLevel is not in config
by Stefan Miklosovic (JIRA)
[ https://issues.jboss.org/browse/ARQ-1568?page=com.atlassian.jira.plugin.s... ]
Stefan Miklosovic reassigned ARQ-1568:
--------------------------------------
Assignee: Stefan Miklosovic
> Droidium fails if emulator is about to start and there is not API level 10 and apiLevel is not in config
> --------------------------------------------------------------------------------------------------------
>
> Key: ARQ-1568
> URL: https://issues.jboss.org/browse/ARQ-1568
> Project: Arquillian
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Extension - Droidium
> Reporter: Stefan Miklosovic
> Assignee: Stefan Miklosovic
>
> Given:
> 1. Already existing emulator with API level != 10 available
> 2. Emulator is not started prior to tests
> 3. API level 10 is not installed locally on developers machine
> 4. apiLevel configuration option is not set in arquillian.xml
> When:
> I want to start emulator with the environment above
> Then:
> Droidium does not fail.
> The reason why it fails is that in case AVD of such name in avdName property does not exist, Droidium tries to create AVD dynamically and it is deleted after tests. Default API level is 10 so when apiLevel is not specified, it attempts to create emulator with that API level, but it might not be present on the system - so it fails.
> The workaround could be to filter all available API level and choose the lowest one as the default one and not API level 10 which is set statically.
--
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
11 years, 2 months
[JBoss JIRA] (ARQ-1568) Droidium fails if emulator is about to start and there is not API level 10 and apiLevel is not in config
by Stefan Miklosovic (JIRA)
Stefan Miklosovic created ARQ-1568:
--------------------------------------
Summary: Droidium fails if emulator is about to start and there is not API level 10 and apiLevel is not in config
Key: ARQ-1568
URL: https://issues.jboss.org/browse/ARQ-1568
Project: Arquillian
Issue Type: Enhancement
Security Level: Public (Everyone can see)
Components: Extension - Droidium
Reporter: Stefan Miklosovic
Given:
1. Already existing emulator with API level != 10 available
2. Emulator is not started prior to tests
3. API level 10 is not installed locally on developers machine
4. apiLevel configuration option is not set in arquillian.xml
When:
I want to start emulator with the environment above
Then:
Droidium does not fail.
The reason why it fails is that in case AVD of such name in avdName property does not exist, Droidium tries to create AVD dynamically and it is deleted after tests. Default API level is 10 so when apiLevel is not specified, it attempts to create emulator with that API level, but it might not be present on the system - so it fails.
The workaround could be to filter all available API level and choose the lowest one as the default one and not API level 10 which is set statically.
--
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
11 years, 2 months
[JBoss JIRA] (ARQGRA-411) GrapheneElement methods should wait until element is present
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/ARQGRA-411?page=com.atlassian.jira.plugin... ]
Lukáš Fryč commented on ARQGRA-411:
-----------------------------------
Emil, afaik GrapheneElement should wait for an element to be present,
could you please provide more details, i.e. stacktrace?
> GrapheneElement methods should wait until element is present
> ------------------------------------------------------------
>
> Key: ARQGRA-411
> URL: https://issues.jboss.org/browse/ARQGRA-411
> Project: Arquillian Graphene
> Issue Type: Feature Request
> Reporter: Emil Cervenan
>
> Scenarios when element is generated by javascript and performance is low leads to situations when method of element which is not present is called. Unwanted exception is thrown. When you are trying to simulate users behaviour it is clear you are not expecting clicking, typing and so on to elements which are not present. Therefore each GrapheneElement method should wait until element is present.
--
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
11 years, 2 months
[JBoss JIRA] (ARQGRA-411) GrapheneElement methods should wait until element is present
by Emil Cervenan (JIRA)
Emil Cervenan created ARQGRA-411:
------------------------------------
Summary: GrapheneElement methods should wait until element is present
Key: ARQGRA-411
URL: https://issues.jboss.org/browse/ARQGRA-411
Project: Arquillian Graphene
Issue Type: Feature Request
Reporter: Emil Cervenan
Scenarios when element is generated by javascript and performance is low leads to situations when method of element which is not present is called. Unwanted exception is thrown. When you are trying to simulate users behaviour it is clear you are not expecting clicking, typing and so on to elements which are not present. Therefore each GrapheneElement method should wait until element is present.
--
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
11 years, 2 months
[JBoss JIRA] (ARQ-1567) Explain validation errors in more depth
by Karel Piwko (JIRA)
[ https://issues.jboss.org/browse/ARQ-1567?page=com.atlassian.jira.plugin.s... ]
Karel Piwko commented on ARQ-1567:
----------------------------------
[~smikloso], would it be possible to check system property java.home as well? While this might point to JRE in some cases, it might make setup easier.
> Explain validation errors in more depth
> ---------------------------------------
>
> Key: ARQ-1567
> URL: https://issues.jboss.org/browse/ARQ-1567
> Project: Arquillian
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Extension - Droidium
> Affects Versions: droidium_1.0.0.Alpha2
> Reporter: Stefan Miklosovic
>
> In many cases, it is not sufficient to provide a user just with stack trace when something goes wrong, for example, from this one:
> {code}
> java.lang.IllegalStateException: Directory to check against readability is null object or empty string.
> at org.arquillian.droidium.container.configuration.Validate.notNullOrEmpty(Validate.java:98)
> at org.arquillian.droidium.container.configuration.Validate.isReadableDirectory(Validate.java:147)
> at org.arquillian.droidium.container.configuration.AndroidSDK.<init>(AndroidSDK.java:189)
> at org.arquillian.droidium.container.AndroidDeployableContainer.setup(AndroidDeployableContainer.java:153)
> {code}
> It basically says that user does not have specified JAVA_HOME but he can not know that without looking into sources which is *totally* not desired.
> Review all crucial configuration properties and its setters / getters and be sure that when it fails user knows whats going on.
--
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
11 years, 2 months