[JBoss JIRA] (ARQ-1429) Spock Appender is missing org.objectweb.asm package
by Aslak Knutsen (JIRA)
[ https://issues.jboss.org/browse/ARQ-1429?page=com.atlassian.jira.plugin.s... ]
Aslak Knutsen updated ARQ-1429:
-------------------------------
Fix Version/s: spock_1.0.0.Beta2
(was: spock_1.0.0.next)
> Spock Appender is missing org.objectweb.asm package
> ---------------------------------------------------
>
> Key: ARQ-1429
> URL: https://issues.jboss.org/browse/ARQ-1429
> Project: Arquillian
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Spock TestRunner
> Affects Versions: spock_1.0.0.Beta1
> Reporter: Karel Piwko
> Assignee: Karel Piwko
> Priority: Blocker
> Fix For: spock_1.0.0.Beta2
>
>
> ASM is used in Groovy, which leads to CNFE when run in server.
> {code}
> @Produces
> @PersistenceContext(unitName = "pushee-default", type = PersistenceContextType.EXTENDED)
> @Default
> EntityManager entityManager;
> @Inject
> PushApplicationDao pushAppDao;
> def "find all registered apps"() {
> when: "Check for all registered apps"
> List<PushApplication> apps = pushAppDao.findAll();
> then: "DAO was injected"
> pushAppDao!=null
> and: "No applications were defined"
> apps.size()==0
> }
> {code}
> leads to:
> {code}
> 17:19:55,691 INFO [org.jboss.web] (MSC service thread 1-1) JBAS018210: Registering web context: /test
> 17:19:55,742 INFO [org.jboss.as.server] (management-handler-thread - 2) JBAS018559: Deployed "test.war"
> 17:19:56,485 WARN [org.jboss.modules] (http--127.0.0.1-8080-1) Failed to define class org.codehaus.groovy.ast.FieldNode in Module "deployment.test.war:main" from Service Module Loader: java.lang.LinkageError: Failed to link org/codehaus/groovy/ast/FieldNode (Module "deployment.test.war:main" from Service Module Loader)
> at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:396)
> at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:243)
> at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:73)
> at org.jboss.modules.Module.loadModuleClass(Module.java:517)
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:182)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:120)
> at java.lang.Class.getDeclaredConstructors0(Native Method) [rt.jar:1.7.0_21]
> at java.lang.Class.privateGetDeclaredConstructors(Class.java:2413) [rt.jar:1.7.0_21]
> at java.lang.Class.getConstructor0(Class.java:2723) [rt.jar:1.7.0_21]
> at java.lang.Class.newInstance0(Class.java:345) [rt.jar:1.7.0_21]
> at java.lang.Class.newInstance(Class.java:327) [rt.jar:1.7.0_21]
> at org.codehaus.groovy.vmplugin.VMPluginFactory.createPlugin(VMPluginFactory.java:56) [arquillian-spock.jar:]
> at org.codehaus.groovy.vmplugin.VMPluginFactory.<clinit>(VMPluginFactory.java:41) [arquillian-spock.jar:]
> at org.codehaus.groovy.runtime.metaclass.MetaClassRegistryImpl.<init>(MetaClassRegistryImpl.java:99) [arquillian-spock.jar:]
> at org.codehaus.groovy.runtime.metaclass.MetaClassRegistryImpl.<init>(MetaClassRegistryImpl.java:71) [arquillian-spock.jar:]
> at groovy.lang.GroovySystem.<clinit>(GroovySystem.java:33) [arquillian-spock.jar:]
> at org.codehaus.groovy.reflection.ClassInfo.getMetaClassUnderLock(ClassInfo.java:162) [arquillian-spock.jar:]
> at org.codehaus.groovy.reflection.ClassInfo.getMetaClass(ClassInfo.java:192) [arquillian-spock.jar:]
> at org.jboss.aerogear.connectivity.jpa.dao.impl.PushDaoSpecification.$getStaticMetaClass(PushDaoSpecification.groovy) [3728ce10-7709-4805-ac00-a0983db929fd.jar:]
> at org.jboss.aerogear.connectivity.jpa.dao.impl.PushDaoSpecification.<init>(PushDaoSpecification.groovy) [3728ce10-7709-4805-ac00-a0983db929fd.jar:]
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [rt.jar:1.7.0_21]
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) [rt.jar:1.7.0_21]
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) [rt.jar:1.7.0_21]
> at java.lang.reflect.Constructor.newInstance(Constructor.java:525) [rt.jar:1.7.0_21]
> at java.lang.Class.newInstance0(Class.java:374) [rt.jar:1.7.0_21]
> at java.lang.Class.newInstance(Class.java:327) [rt.jar:1.7.0_21]
> at org.spockframework.runtime.BaseSpecRunner.createSpecInstance(BaseSpecRunner.java:121) [arquillian-spock.jar:]
> at org.spockframework.runtime.BaseSpecRunner.run(BaseSpecRunner.java:80) [arquillian-spock.jar:]
> at org.spockframework.runtime.Sputnik.run(Sputnik.java:63) [arquillian-spock.jar:]
> at org.jboss.arquillian.spock.container.SpockTestRunner.runTest(SpockTestRunner.java:81) [arquillian-spock.jar:]
> at org.jboss.arquillian.spock.container.SpockTestRunner.execute(SpockTestRunner.java:61) [arquillian-spock.jar:]
> at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.executeTest(ServletTestRunner.java:160) [arquillian-protocol.jar:]
> at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.execute(ServletTestRunner.java:126) [arquillian-protocol.jar:]
> at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.doGet(ServletTestRunner.java:90) [arquillian-protocol.jar:]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:734) [jboss-servlet-api_3.0_spec-1.0.0.Final.jar:1.0.0.Final]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.0.Final.jar:1.0.0.Final]
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329) [jbossweb-7.0.13.Final.jar:]
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.13.Final.jar:]
> at org.jboss.weld.servlet.ConversationPropagationFilter.doFilter(ConversationPropagationFilter.java:62) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280) [jbossweb-7.0.13.Final.jar:]
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.13.Final.jar:]
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) [jbossweb-7.0.13.Final.jar:]
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) [jbossweb-7.0.13.Final.jar:]
> at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50) [jboss-as-jpa-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:153) [jboss-as-web-7.1.1.Final.jar:7.1.1.Final]
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155) [jbossweb-7.0.13.Final.jar:]
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.13.Final.jar:]
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.13.Final.jar:]
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) [jbossweb-7.0.13.Final.jar:]
> at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.13.Final.jar:]
> at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:671) [jbossweb-7.0.13.Final.jar:]
> at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:930) [jbossweb-7.0.13.Final.jar:]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> Caused by: java.lang.NoClassDefFoundError: org/objectweb/asm/Opcodes
> at java.lang.ClassLoader.defineClass1(Native Method) [rt.jar:1.7.0_21]
> at java.lang.ClassLoader.defineClass(ClassLoader.java:791) [rt.jar:1.7.0_21]
> at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) [rt.jar:1.7.0_21]
> at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:327)
> at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:391)
> ... 55 more
> Caused by: java.lang.ClassNotFoundException: org.objectweb.asm.Opcodes from [Module "deployment.test.war:main" from Service Module Loader]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:120)
> ... 60 more
> {code}
> The problematic part is that asm suffers the same problem as Groovy pre 2.1.4 version (http://jira.codehaus.org/browse/GROOVY-6158)
--
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] (ARQGRA-397) Add support for host (ActiveX) objects
by Petr Andreev (JIRA)
[ https://issues.jboss.org/browse/ARQGRA-397?page=com.atlassian.jira.plugin... ]
Petr Andreev updated ARQGRA-397:
--------------------------------
Estimated Difficulty: Medium
> Add support for host (ActiveX) objects
> --------------------------------------
>
> Key: ARQGRA-397
> URL: https://issues.jboss.org/browse/ARQGRA-397
> Project: Arquillian Graphene
> Issue Type: Feature Request
> Components: core
> Affects Versions: 2.0.0.CR2
> Environment: WIn7 x64, msxml3.dll (8.110.7601.17988), msxml6.dll (6.30.7601.17988)
> IE9 (IE9 in compat mode->IE7)
> Richfaces 3.3.4 (Sarissa 0.9.9.3)
> Reporter: Petr Andreev
> Attachments: Graphene.Page.RequestGuard.js.patch, Graphene.xhrInterception.js.patch, test_ActiveXObject.js, test_setTimeout.js
>
>
> Graphene JavaScript RequestGuard interceptors cause failure of all AJAX requests with Richfaces 3 on InternetExplorer with ActiveXObject version of XMLHttpRequest (overriden by Sarissa included in RF3). There are several issues:
> 1. While wrapping the underlying XMLHttpRequest (provided by Sarissa and being actually the ActiveXObject) the InterceptedXMLHttpRequest accesses the response fields of XHR, which is illegal for windows-host objects. I.e. responseText throws an error '#575: This method cannot be called until the send method has been called.' The solution would be to not to read the response properties in constructor of InterceptedXMLHttpRequest since at this phase it makes no sense.
> 2. The bracket- style calls (xhr['send']) on host objects lead to immediate invocation of affected functions without any parameters. Therefore it is impossible to make any reflection-like invocations or checks for existence on them (i.e. if(xhr['send']) or xhr['send'].apply(.....)). The proposed solution is to wrap the host and native objects before 'apply' calls and expand argument list, in that way avoiding failures and ugly browser detection. On the other hand, the invocation of interceptor chain could be refactored (but there could be still problems passing function pointers of host objects: needs to be checked).
> IE9 errors: "#450: Wrong number of arguments or invalid property assignment" or "#87: The parameter is incorrect."
> 3. The scoping of "this" while attaching "onreadystatchange" callback to original (host) XHR is unspecified in contrary to the case with native JS objects. That`s why the interceptors and RF components don`t get notified about completed AJAX request .The solution is simple - just use the wrappers member variable.
> 4. Overriding the "window.setTimeout" method in RequestGuard causes JS error in IE9 + IE compat mode since there are no 'apply' and 'call' functions defined on window`s host object. The solution is to borrow both functions from Function.prototype- works for native objects too.
> Test cases attached (can be ran in http://jsfiddle.net)
> Proposed patches attached.
--
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] (ARQGRA-331) Graphene guards fails when page stores reference to XMLHttpRequest before Graphene rewrites them
by Petr Andreev (JIRA)
[ https://issues.jboss.org/browse/ARQGRA-331?page=com.atlassian.jira.plugin... ]
Petr Andreev commented on ARQGRA-331:
-------------------------------------
Hi Lukáš, it took a while to find out what`s wrong, but i got it- it`s all about the strange windows host objects which doesn`t comply (and actually don`t have to ) to the spec. I opened an issue ARQGRA-397 with possible patches. I`m testing on Win7x64 with IE9(comp IE7 since RF3 require it) , FF ESR 24.0, Chrome 29.0.1547.66 m the AJAX things look good there. Graphene tests are also successful. Can you please verify it? Thank you.
> Graphene guards fails when page stores reference to XMLHttpRequest before Graphene rewrites them
> ------------------------------------------------------------------------------------------------
>
> Key: ARQGRA-331
> URL: https://issues.jboss.org/browse/ARQGRA-331
> Project: Arquillian Graphene
> Issue Type: Bug
> Components: core
> Affects Versions: 2.0.0.Alpha4
> Reporter: Oliver Kišš
> Assignee: Lukáš Fryč
> Priority: Critical
> Fix For: 2.1-Tracking
>
>
> Graphene guards do not work correctly in the [AngularJS Kitchensink quickstart|https://github.com/jboss-jdf/jboss-as-quickstart/tree/master/k...].
> The registration form sends a XHR POST request on submit, but this is not recognized and clicking on the submit button with {{guardAjax(registerButton).click()}} throws an exception: "{{RequestGuardException: Request type 'XHR' was expected, but type 'NONE' was done instead}}".
--
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-1505) Wrong handling of Android Debug Bridge initialization
by Stefan Miklosovic (JIRA)
[ https://issues.jboss.org/browse/ARQ-1505?page=com.atlassian.jira.plugin.s... ]
Stefan Miklosovic closed ARQ-1505.
----------------------------------
> Wrong handling of Android Debug Bridge initialization
> -----------------------------------------------------
>
> Key: ARQ-1505
> URL: https://issues.jboss.org/browse/ARQ-1505
> Project: Arquillian
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Extension - Droidium
> Affects Versions: droidium_1.0.0.Alpha1
> Reporter: Karel Piwko
> Assignee: Stefan Miklosovic
> Fix For: droidium_1.0.0.Alpha2
>
>
> When ADB is started, but the port is already occupied by a different tooling, it logs an E/ddms message, however it continues with the execution.
> This is indeed faulty behaviour. The port should be configurable, if the port is occupied - it should fail with Unable to start container or unable to connect to the running container exception - similar to behavior you experience with other remote / managed containers.
> {code}
> org.arquillian.droidium.container.impl.AndroidBridgeImpl connect
> INFO: Connecting to the Android Debug Bridge at /home/kpiwko/apps/android-sdk-linux_x86/platform-tools/adb forceNewBridge = true
> 10:01:23 E/ddms: Could not open Selected VM debug port (8700). Make sure you do not have another instance of DDMS or of the eclipse plugin running. If it's being used by
> something else, choose a new port number in the preferences.
> Sep 27, 2013 10:01:23 PM org.arquillian.droidium.container.impl.AndroidBridgeConnector initAndroidDebugBridge
> INFO: Android Debug Bridge was initialized in 350ms.
> {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-1521) Implement default activity manager when native plugin is not on the class path
by Stefan Miklosovic (JIRA)
[ https://issues.jboss.org/browse/ARQ-1521?page=com.atlassian.jira.plugin.s... ]
Stefan Miklosovic closed ARQ-1521.
----------------------------------
> Implement default activity manager when native plugin is not on the class path
> ------------------------------------------------------------------------------
>
> Key: ARQ-1521
> URL: https://issues.jboss.org/browse/ARQ-1521
> Project: Arquillian
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Extension - Droidium
> Affects Versions: droidium_1.0.0.Alpha1
> Reporter: Stefan Miklosovic
> Assignee: Stefan Miklosovic
> Fix For: droidium_1.0.0.Alpha2
>
>
> Once user puts native plugin on class path, he can manage activities via NativeActivityManager however when he does no put this plugin on the class path, after he injects AndroidDevice, he is not able to start activities because ActivityManager implementation is null.
> In order to be able to start activities even when native plugin is missing, there has to be default ActivityManager implementation which does not uses WebDriver or Selendroid but it executes shell commands instead of that.
> However, even after implementing this, it is questionable for what reason a user would start the activity when he can not control it by any means since WebDriver is missing and we can not inject it via Drone as well.
--
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-1522) Should be able to start activity without FQDN format
by Stefan Miklosovic (JIRA)
[ https://issues.jboss.org/browse/ARQ-1522?page=com.atlassian.jira.plugin.s... ]
Stefan Miklosovic closed ARQ-1522.
----------------------------------
> Should be able to start activity without FQDN format
> ----------------------------------------------------
>
> Key: ARQ-1522
> URL: https://issues.jboss.org/browse/ARQ-1522
> Project: Arquillian
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Extension - Droidium
> Affects Versions: droidium_1.0.0.Alpha1
> Reporter: Stefan Miklosovic
> Assignee: Stefan Miklosovic
> Priority: Minor
> Fix For: droidium_1.0.0.Alpha2
>
>
> Given:
> I have activities which can be started via activity manager.
> When:
> I want to start some activity
> Expect:
> It is sufficient to use its simple name instead of FQDN.
> Example:
> {code}android.getActivityManagerProvider().getActivityManager().startActivity("io.selendroid.testapp.HomeScreenActivity");{code}
> should equal to
> {code}android.getActivityManagerProvider().getActivityManager().startActivity("HomeScreenActivity");{code}
> In case there are two activities with same simple name, exception has to be thrown.
--
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-1524) Implement deployment logic when native plugin is not on class path
by Stefan Miklosovic (JIRA)
[ https://issues.jboss.org/browse/ARQ-1524?page=com.atlassian.jira.plugin.s... ]
Stefan Miklosovic closed ARQ-1524.
----------------------------------
> Implement deployment logic when native plugin is not on class path
> ------------------------------------------------------------------
>
> Key: ARQ-1524
> URL: https://issues.jboss.org/browse/ARQ-1524
> Project: Arquillian
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Extension - Droidium
> Affects Versions: droidium_1.0.0.Alpha1
> Reporter: Stefan Miklosovic
> Assignee: Stefan Miklosovic
> Fix For: droidium_1.0.0.Alpha2
>
>
> When native plugin is not on class path, we can install packages to Android device directly via Android's injection install and uninstall methods however since Android container without native plugin is not capable to follow Arquillian deployment logic, we have to use these methods so @Deployment method has to be kind of dummy.
> There has to be deployment logic implemented when native plugin is not on class path. This has to be investigated further.
> This is the logical continuation of ARQ-1521
--
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-1525) Be able to deploy APKs when doing web testing with web plugin
by Stefan Miklosovic (JIRA)
[ https://issues.jboss.org/browse/ARQ-1525?page=com.atlassian.jira.plugin.s... ]
Stefan Miklosovic closed ARQ-1525.
----------------------------------
> Be able to deploy APKs when doing web testing with web plugin
> -------------------------------------------------------------
>
> Key: ARQ-1525
> URL: https://issues.jboss.org/browse/ARQ-1525
> Project: Arquillian
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Extension - Droidium
> Affects Versions: droidium_1.0.0.Alpha1
> Reporter: Stefan Miklosovic
> Fix For: droidium_1.0.0.Alpha2
>
>
> Now, user can not deploy packages to Android device when he uses web plugin. Even the usage and profit of having Android packages installed on device when doing web testing against application container is quite questionable, it is needed anyway. There is not any reason why user should not be able to install packages as normal deployments to Android device even he is focused on web testing mainly.
--
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-1511) Wrong Android container identification in logs
by Stefan Miklosovic (JIRA)
[ https://issues.jboss.org/browse/ARQ-1511?page=com.atlassian.jira.plugin.s... ]
Stefan Miklosovic closed ARQ-1511.
----------------------------------
> Wrong Android container identification in logs
> ----------------------------------------------
>
> Key: ARQ-1511
> URL: https://issues.jboss.org/browse/ARQ-1511
> Project: Arquillian
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Extension - Droidium
> Affects Versions: droidium_1.0.0.Alpha1
> Reporter: Karel Piwko
> Assignee: Stefan Miklosovic
> Priority: Minor
> Fix For: droidium_1.0.0.Alpha2
>
>
> Despite the fact I have physical device attached and tests are running on that device, Droidium logs following:
> {code}
> Sep 29, 2013 4:30:14 PM org.arquillian.droidium.container.configuration.AndroidContainerConfiguration validate
> WARNING: Both "avdName" and "serialId" properties are defined, the device specified by "serialId" will get priority if connected.
> Sep 29, 2013 4:30:14 PM org.arquillian.droidium.container.AndroidDeployableContainer start
> INFO: Starting the container Nexus4.
> Sep 29, 2013 4:30:14 PM org.arquillian.droidium.container.impl.AndroidBridgeConnector initAndroidDebugBridge
> INFO: Initializing Android Debug Bridge.
> Sep 29, 2013 4:30:14 PM org.arquillian.droidium.container.impl.AndroidBridgeImpl connect
> INFO: Connecting to the Android Debug Bridge at /home/kpiwko/apps/android-sdk-linux_x86/platform-tools/adb forceNewBridge = true
> Sep 29, 2013 4:30:14 PM org.arquillian.droidium.container.impl.AndroidBridgeConnector initAndroidDebugBridge
> INFO: Android Debug Bridge was initialized in 323ms.
> Sep 29, 2013 4:30:14 PM org.arquillian.droidium.container.impl.AndroidDeviceSelectorImpl getPhysicalDevice
> INFO: Detected physical device with serial ID e8fd5c98.
> {code}
> *Starting the container Nexus4.* is a wrong log output.
--
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