[JBoss JIRA] (ARQ-1593) Missing Desired Capabilities for PhantomJS
by Karel Piwko (JIRA)
[ https://issues.jboss.org/browse/ARQ-1593?page=com.atlassian.jira.plugin.s... ]
Karel Piwko closed ARQ-1593.
----------------------------
> Missing Desired Capabilities for PhantomJS
> ------------------------------------------
>
> Key: ARQ-1593
> URL: https://issues.jboss.org/browse/ARQ-1593
> Project: Arquillian
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Extension - Drone
> Affects Versions: drone_1.2.0.Final
> Reporter: Karel Piwko
> Assignee: Karel Piwko
> Priority: Critical
> Fix For: drone_1.2.1.Final
>
>
> *When*:
> I use phantomjs as a remote driver.
> *Then*:
> I expect everything will work, given that remote server is aware of phantomjs binary location.
> *Current Behavior*:
> PhantomJS does not have capabilities set, which leads to remote server itself choosing browser capabilities itself, returning a different browser in reusing is enabled.
--
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
10 years, 10 months
[JBoss JIRA] (ARQ-1561) Warp proxy tries to rewrite binary files
by Tilmann Kuhn (JIRA)
[ https://issues.jboss.org/browse/ARQ-1561?page=com.atlassian.jira.plugin.s... ]
Tilmann Kuhn edited comment on ARQ-1561 at 12/3/13 11:00 AM:
-------------------------------------------------------------
I can confirm that the proxy corrupts png and jpg files. Without @WarpTest the images are transferred correctly. Since my tests depend on the images being available to the client (simulating cicks on coordinates on them) this does not work at the moment.
was (Author: tilm4nn):
I can confirm that the proxy corrupts png and jpg files. Without @WarpTest the images are trensferred correctly. Since my tests depend on the images being available to the client (simulating cicks on coordinates on them) this does not work at the moment.
> Warp proxy tries to rewrite binary files
> ----------------------------------------
>
> Key: ARQ-1561
> URL: https://issues.jboss.org/browse/ARQ-1561
> Project: Arquillian
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Extension - Warp
> Affects Versions: 1.0.0.Alpha5
> Reporter: Jan Dosoudil
> Priority: Critical
> Fix For: warp_1.0.0.Alpha6
>
> Attachments: empty.png, empty2.png
>
>
> It's related to ARQ-1552 - rewrite calls new String(byte[]) on response byte[] which may fail on binary files.
--
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
10 years, 10 months
[JBoss JIRA] (ARQ-1561) Warp proxy tries to rewrite binary files
by Tilmann Kuhn (JIRA)
[ https://issues.jboss.org/browse/ARQ-1561?page=com.atlassian.jira.plugin.s... ]
Tilmann Kuhn commented on ARQ-1561:
-----------------------------------
I can confirm that the proxy corrupts png and jpg files. Without @WarpTest the images are trensferred correctly. Since my tests depend on the images being available to the client (simulating cicks on coordinates on them) this does not work at the moment.
> Warp proxy tries to rewrite binary files
> ----------------------------------------
>
> Key: ARQ-1561
> URL: https://issues.jboss.org/browse/ARQ-1561
> Project: Arquillian
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Extension - Warp
> Affects Versions: 1.0.0.Alpha5
> Reporter: Jan Dosoudil
> Priority: Critical
> Fix For: warp_1.0.0.Alpha6
>
> Attachments: empty.png, empty2.png
>
>
> It's related to ARQ-1552 - rewrite calls new String(byte[]) on response byte[] which may fail on binary files.
--
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
10 years, 10 months
[JBoss JIRA] (ARQ-1509) Arquillian Droidium Multiple Container does not work correctly when used standalone
by Stefan Miklosovic (JIRA)
[ https://issues.jboss.org/browse/ARQ-1509?page=com.atlassian.jira.plugin.s... ]
Stefan Miklosovic closed ARQ-1509.
----------------------------------
> Arquillian Droidium Multiple Container does not work correctly when used standalone
> -----------------------------------------------------------------------------------
>
> Key: ARQ-1509
> URL: https://issues.jboss.org/browse/ARQ-1509
> Project: Arquillian
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Extension - Droidium
> Affects Versions: droidium_1.0.0.Alpha1
> Reporter: Karel Piwko
> Priority: Critical
> Fix For: droidium_1.0.0.Alpha3
>
>
> Supposing you want to use web based testing with Droidium.
> In such case, you have a pretty specific configuration in arquillian.xml, as you need to enable multiple containers.
> However, if you don't want to run Android - you are for instance testing with Firefox, so no Android container is needed, then you need to create a separate <group> in order to do that.
> Otherwise, MultipleContainer Extension will let Arquillian create container def for each <container> in the group, leading to attempt to create JBoss AS - or whatever is you web container - using Android container configuration.
> This will obvisously fail, for instance with
> {code}
> org.jboss.arquillian.container.spi.ConfigurationException: jbossHome 'null' must exist
> at org.jboss.arquillian.container.spi.client.deployment.Validate.configurationDirectoryExists(Validate.java:139)
> {code}
> So, if you put only multicontainer extension jar into <dependencies>, behavior is broken. If you don't put anything there, you already have tailed arq.xml to be used with multiple container. If you indeed put Android container there, it is started even if it would actually never be used due to fact you asked for Firefox Browser.
> This represents a serious usability issues, hence marked as Critical.
--
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
10 years, 10 months
[JBoss JIRA] (ARQ-1583) Emulator does not figure out process had died
by Stefan Miklosovic (JIRA)
[ https://issues.jboss.org/browse/ARQ-1583?page=com.atlassian.jira.plugin.s... ]
Stefan Miklosovic closed ARQ-1583.
----------------------------------
> Emulator does not figure out process had died
> ---------------------------------------------
>
> Key: ARQ-1583
> URL: https://issues.jboss.org/browse/ARQ-1583
> 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: Karel Piwko
> Priority: Critical
> Fix For: droidium_1.0.0.Alpha3
>
>
> *When*:
> I let Droidium start emulator.
> *Given*:
> Emulator command fails, for instance when DISPLAY is not set.
> *Then*:
> Droidium waits up to emulator start time, then fails.
> *Expected*:
> Droidium will figure out command had failed - emulator actually outputs *SDL init failure, reason is: No available video device* and let user know what happened wrong.
--
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
10 years, 10 months
[JBoss JIRA] (ARQ-1582) Honor ANDROID_SDK_HOME, deprecate generatedAvdPath
by Stefan Miklosovic (JIRA)
[ https://issues.jboss.org/browse/ARQ-1582?page=com.atlassian.jira.plugin.s... ]
Stefan Miklosovic closed ARQ-1582.
----------------------------------
> Honor ANDROID_SDK_HOME, deprecate generatedAvdPath
> --------------------------------------------------
>
> Key: ARQ-1582
> URL: https://issues.jboss.org/browse/ARQ-1582
> Project: Arquillian
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Extension - Droidium
> Affects Versions: droidium_1.0.0.Alpha2
> Reporter: Karel Piwko
> Assignee: Stefan Miklosovic
> Priority: Critical
> Fix For: droidium_1.0.0.Alpha3
>
>
> ANDROID_SDK_HOME represents a top level directory that is used to store metadata of AVDs. By default, this directory equals $HOME.
> However, various plugins and tools - such as Jenkins Android Plugin, allow to change ANDROID_SDK_HOME to better isolate jobs.
> Droidium should be able to:
> * pass androidSdkHome in arquillian.xml with default = user.home
> * honor this directoryand create generated AVDs there - this will limit write access to single location - e.g. pattern would be ${androidSdkHome}/.android/${avdName}.avd
> Then, *generatedAvdPath* can be dropped altogether - reasoning is that Android UI does not allow that neither and it does not make much sense to split metadata and AVD itself.
--
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
10 years, 10 months
[JBoss JIRA] (ARQ-1585) Droidium does not figure out AVD is broken
by Stefan Miklosovic (JIRA)
[ https://issues.jboss.org/browse/ARQ-1585?page=com.atlassian.jira.plugin.s... ]
Stefan Miklosovic closed ARQ-1585.
----------------------------------
> Droidium does not figure out AVD is broken
> ------------------------------------------
>
> Key: ARQ-1585
> URL: https://issues.jboss.org/browse/ARQ-1585
> Project: Arquillian
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Extension - Droidium
> Affects Versions: droidium_1.0.0.Alpha2
> Reporter: Karel Piwko
> Priority: Blocker
> Fix For: droidium_1.0.0.Alpha3
>
>
> Current AVD name parsing is broken, it won't figure out that AVD is actually broken - for instance metadata point to AVD images that are no longer on filesystem. Even in such situations Drodium starts emulator, which is deemed to fail and Droidium waits up to all timeout to fail the test.
> Ideally, Droidium should handle such situation and figure out that metadata of broken device should be deleted if user requested that AVD by name.
--
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
10 years, 10 months
[JBoss JIRA] (ARQ-1570) Provide better parsing of ABI in connection with API level for Droidium
by Stefan Miklosovic (JIRA)
[ https://issues.jboss.org/browse/ARQ-1570?page=com.atlassian.jira.plugin.s... ]
Stefan Miklosovic closed ARQ-1570.
----------------------------------
> Provide better parsing of ABI in connection with API level for Droidium
> -----------------------------------------------------------------------
>
> Key: ARQ-1570
> URL: https://issues.jboss.org/browse/ARQ-1570
> 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
>
>
> Right now, there is not any tracking between available API levels and their respective ABI present in the system.
> For example, when some AVD is not present in the system, Droidium tries to create it. While creating, it uses API level and when there exists ABI in configuration, it creates it with that ABI level.
> For every API level present in the system, there should be information as which system images for that particular API level can be used while creating of AVD takes place.
> Because of speed, default ABI will be choosen as x86 for some particular API level of users choice when he has not specified it explicitly. It is needed to filter available ABIs for some API level dynamically upon AVD creation.
--
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
10 years, 10 months