[JBoss JIRA] (ARQGRA-269) Argument is of an illegal type, when attempting to switchTo an iframe
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/ARQGRA-269?page=com.atlassian.jira.plugin... ]
Lukáš Fryč updated ARQGRA-269:
------------------------------
Fix Version/s: 2.0.0.Beta1
> Argument is of an illegal type, when attempting to switchTo an iframe
> ---------------------------------------------------------------------
>
> Key: ARQGRA-269
> URL: https://issues.jboss.org/browse/ARQGRA-269
> Project: Arquillian Graphene
> Issue Type: Bug
> Components: core
> Affects Versions: 2.0.0.Alpha3
> Environment: Windows 7
> JDK 1.7U10 64-bit
> Drone 1.2.0Alpha
> Graphen 2.0.0.Alpha3
> Reporter: Simon Knott
> Fix For: 2.0.0.Beta1
>
>
> I am getting the following exception thrown when attempting to switchTo() an iframe:
> {code}java.lang.IllegalArgumentException: Argument is of an illegal type: $Proxy26
> at org.openqa.selenium.remote.internal.WebElementToJsonConverter.apply(WebElementToJsonConverter.java:78)
> at org.openqa.selenium.remote.RemoteWebDriver$RemoteTargetLocator.frame(RemoteWebDriver.java:797)
> 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.graphene.proxy.GrapheneProxyHandler.invokeReal(GrapheneProxyHandler.java:209)
> at org.jboss.arquillian.graphene.proxy.GrapheneProxyHandler$1.invoke(GrapheneProxyHandler.java:140)
> at org.jboss.arquillian.graphene.proxy.GrapheneProxyHandler.invoke(GrapheneProxyHandler.java:170)
> at $Proxy27.frame(Unknown Source){code}
> The test code which is causing the exception looks like:
> {code}WebElement iframe = driver.findElement(By.tagName("iframe"));
> TargetLocator targetLocator = driver.switchTo();
> targetLocator.frame(iframe);{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
11 years, 10 months
[JBoss JIRA] (ARQGRA-269) Argument is of an illegal type, when attempting to switchTo an iframe
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/ARQGRA-269?page=com.atlassian.jira.plugin... ]
Lukáš Fryč updated ARQGRA-269:
------------------------------
Priority: Critical (was: Major)
> Argument is of an illegal type, when attempting to switchTo an iframe
> ---------------------------------------------------------------------
>
> Key: ARQGRA-269
> URL: https://issues.jboss.org/browse/ARQGRA-269
> Project: Arquillian Graphene
> Issue Type: Bug
> Components: core
> Affects Versions: 2.0.0.Alpha3
> Environment: Windows 7
> JDK 1.7U10 64-bit
> Drone 1.2.0Alpha
> Graphen 2.0.0.Alpha3
> Reporter: Simon Knott
> Priority: Critical
> Fix For: 2.0.0.Beta1
>
>
> I am getting the following exception thrown when attempting to switchTo() an iframe:
> {code}java.lang.IllegalArgumentException: Argument is of an illegal type: $Proxy26
> at org.openqa.selenium.remote.internal.WebElementToJsonConverter.apply(WebElementToJsonConverter.java:78)
> at org.openqa.selenium.remote.RemoteWebDriver$RemoteTargetLocator.frame(RemoteWebDriver.java:797)
> 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.graphene.proxy.GrapheneProxyHandler.invokeReal(GrapheneProxyHandler.java:209)
> at org.jboss.arquillian.graphene.proxy.GrapheneProxyHandler$1.invoke(GrapheneProxyHandler.java:140)
> at org.jboss.arquillian.graphene.proxy.GrapheneProxyHandler.invoke(GrapheneProxyHandler.java:170)
> at $Proxy27.frame(Unknown Source){code}
> The test code which is causing the exception looks like:
> {code}WebElement iframe = driver.findElement(By.tagName("iframe"));
> TargetLocator targetLocator = driver.switchTo();
> targetLocator.frame(iframe);{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
11 years, 10 months
[JBoss JIRA] (ARQ-1315) Make possible to configure firefox preferences via arquillian.xml
by Fabian Schwarzer (JIRA)
[ https://issues.jboss.org/browse/ARQ-1315?page=com.atlassian.jira.plugin.s... ]
Fabian Schwarzer edited comment on ARQ-1315 at 2/27/13 5:17 AM:
----------------------------------------------------------------
Yes, if I get it right, one can pass all of [these FF properties/capabilities|http://code.google.com/p/selenium/wiki/DesiredCap...] to selenium via the arquillian.xml. All, but firefox_profiles as described above. So it would be great if you could somehow make the firefox_profiles property work again...I'm not sure yet if this is a bug or a feauture. :)
If this can't be fixed or in addition to the a solution to the problem above it would be nice if you could set FirefoxProfile#setPreference(...) in the arquillian.xml, similarily to the solution that you implemented in [commit dd850e7|https://github.com/arquillian/arquillian-extension-drone/commit/d...] for FirefoxProfile#addExtension(...). I don't have a specific answer to the question how this should look like in the arquillian.xml. Maybe an arquillian.xml property like <property name="firefox_properties">/path/to/a/properties/file</property> could link to a file that contains FF-properties like you can see on the FF about:config page...
was (Author: pogopaule):
Yes, if I get it right, one can pass all of [these FF properties/capabilities|http://code.google.com/p/selenium/wiki/DesiredCap...] to selenium via the arquillian.xml. All, but firefox_profiles as described above. So it would be great if you could somehow make the firefox_profiles property work again...I'm not sure yet if this is a bug or a feauture. :)
If this can't be fixed or in addition to the solution above it would be nice if you could set FirefoxProfile#setPreference(...) in the arquillian.xml, similarily to the solution that you implemented in [commit dd850e7|https://github.com/arquillian/arquillian-extension-drone/commit/d...] for FirefoxProfile#addExtension(...). I don't have a specific answer to the question how this should look like in the arquillian.xml. Maybe an arquillian.xml property like <property name="firefox_properties">/path/to/a/properties/file</property> could link to a file that contains FF-properties like you can see on the FF about:config page...
> Make possible to configure firefox preferences via arquillian.xml
> -----------------------------------------------------------------
>
> Key: ARQ-1315
> URL: https://issues.jboss.org/browse/ARQ-1315
> Project: Arquillian
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Extension - Drone
> Affects Versions: drone_1.1.1.Final
> Reporter: Fabian Schwarzer
> Assignee: Karel Piwko
>
> In order to configure a FF extension (see ARQ-1259) one needs to add properties to FF (like on the about:config page) via arquillian.xml. This could be done by preparing a FF profile and configure this in arquillian.xml. Unfortunately drone does not seem to pick up the firefox_profile property in arquillian.xml (propably due to org.openqa.selenium.firefox.FirefoxDriver.java:184)
> So it would be great if there were some means to configure FF properties; either by configuring them in the arquillian.xml like done in ARQ-1259, or by making it possible to pass a profile via
> <extension qualifier="webdriver">
> <property name="browserCapabilities">firefox</property>
> <property name="firefox_profile">/path/to/profile</property>
> </extension>
> see also ARQ-1245
--
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, 10 months
[JBoss JIRA] (ARQ-1315) Make possible to configure firefox preferences via arquillian.xml
by Fabian Schwarzer (JIRA)
[ https://issues.jboss.org/browse/ARQ-1315?page=com.atlassian.jira.plugin.s... ]
Fabian Schwarzer commented on ARQ-1315:
---------------------------------------
Yes, if I get it right, one can pass all of [these FF properties/capabilities|http://code.google.com/p/selenium/wiki/DesiredCap...] to selenium via the arquillian.xml. All, but firefox_profiles as described above. So it would be great if you could somehow make the firefox_profiles property work again...I'm not sure yet if this is a bug or a feauture. :)
If this can't be fixed or in addition to the solution above it would be nice if you could set FirefoxProfile#setPreference(...) in the arquillian.xml, similarily to the solution that you implemented in [commit dd850e7|https://github.com/arquillian/arquillian-extension-drone/commit/d...] for FirefoxProfile#addExtension(...). I don't have a specific answer to the question how this should look like in the arquillian.xml. Maybe an arquillian.xml property like <property name="firefox_properties">/path/to/a/properties/file</property> could link to a file that contains FF-properties like you can see on the FF about:config page...
> Make possible to configure firefox preferences via arquillian.xml
> -----------------------------------------------------------------
>
> Key: ARQ-1315
> URL: https://issues.jboss.org/browse/ARQ-1315
> Project: Arquillian
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Extension - Drone
> Affects Versions: drone_1.1.1.Final
> Reporter: Fabian Schwarzer
> Assignee: Karel Piwko
>
> In order to configure a FF extension (see ARQ-1259) one needs to add properties to FF (like on the about:config page) via arquillian.xml. This could be done by preparing a FF profile and configure this in arquillian.xml. Unfortunately drone does not seem to pick up the firefox_profile property in arquillian.xml (propably due to org.openqa.selenium.firefox.FirefoxDriver.java:184)
> So it would be great if there were some means to configure FF properties; either by configuring them in the arquillian.xml like done in ARQ-1259, or by making it possible to pass a profile via
> <extension qualifier="webdriver">
> <property name="browserCapabilities">firefox</property>
> <property name="firefox_profile">/path/to/profile</property>
> </extension>
> see also ARQ-1245
--
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, 10 months
[JBoss JIRA] (ARQ-1318) Test Intitialisation Time Sensitive to Classpath Dependencies
by Chris Lowe (JIRA)
[ https://issues.jboss.org/browse/ARQ-1318?page=com.atlassian.jira.plugin.s... ]
Chris Lowe updated ARQ-1318:
----------------------------
Attachment: arquillian-tutorial.zip
I've attached a modified version of the Arquillian getting started test with extra Maven dependencies that high light the issue.
> Test Intitialisation Time Sensitive to Classpath Dependencies
> -------------------------------------------------------------
>
> Key: ARQ-1318
> URL: https://issues.jboss.org/browse/ARQ-1318
> Project: Arquillian
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Affects Versions: 1.0.3.Final
> Environment: Fully patched Windows 7 64 bit OS. JDK 7.0_13 (x86). CPU i7 X940, 8GiB RAM, SSD storage.
> Reporter: Chris Lowe
> Attachments: arquillian-tutorial.zip
>
>
> My test is making use of JBoss AS7 remote deployment and takes 11+ seconds before any output is received by the AS instance. Test initialisation times appear to be sensitive to the number of classpath dependencies. Of this time:
> 2.5 seconds is spent loading auxiliary archives;
> 8 seconds is spent making the final internal in-memory deployment before sending a byte buffer over to AS7.
> Inclusion of Arquillian persistence along with JMeter (which has many transitive dependencies) results in tests shipping with an arquillian-persistence.jar that is 9MiB in size. This JAR file is produced and compressed on the fly as part of the test EAR construction. The jar files are compressed again when added to the final EAR.
> My typical usage scenario is to run a test from Eclipse which spawns a JVM each time so test runs are from standing start (little hotspot optimisation).
> Some of the generated Arquillian jars include dependencies like log4j and slf4j which will be available in the target server. As far as I can tell, I have no control over this process.
> It would be ideal if I could create an Arquillian module in AS7 to eliminate the need to ship Arquillian run time classes entirely.
--
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, 10 months
[JBoss JIRA] (ARQ-1318) Test Intitialisation Time Sensitive to Classpath Dependencies
by Chris Lowe (JIRA)
[ https://issues.jboss.org/browse/ARQ-1318?page=com.atlassian.jira.plugin.s... ]
Chris Lowe updated ARQ-1318:
----------------------------
Environment: Fully patched Windows 7 64 bit OS. JDK 7.0_13 (x86). CPU i7 X940, 8GiB RAM, SSD storage.
> Test Intitialisation Time Sensitive to Classpath Dependencies
> -------------------------------------------------------------
>
> Key: ARQ-1318
> URL: https://issues.jboss.org/browse/ARQ-1318
> Project: Arquillian
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Affects Versions: 1.0.3.Final
> Environment: Fully patched Windows 7 64 bit OS. JDK 7.0_13 (x86). CPU i7 X940, 8GiB RAM, SSD storage.
> Reporter: Chris Lowe
>
> My test is making use of JBoss AS7 remote deployment and takes 11+ seconds before any output is received by the AS instance. Test initialisation times appear to be sensitive to the number of classpath dependencies. Of this time:
> 2.5 seconds is spent loading auxiliary archives;
> 8 seconds is spent making the final internal in-memory deployment before sending a byte buffer over to AS7.
> Inclusion of Arquillian persistence along with JMeter (which has many transitive dependencies) results in tests shipping with an arquillian-persistence.jar that is 9MiB in size. This JAR file is produced and compressed on the fly as part of the test EAR construction. The jar files are compressed again when added to the final EAR.
> My typical usage scenario is to run a test from Eclipse which spawns a JVM each time so test runs are from standing start (little hotspot optimisation).
> Some of the generated Arquillian jars include dependencies like log4j and slf4j which will be available in the target server. As far as I can tell, I have no control over this process.
> It would be ideal if I could create an Arquillian module in AS7 to eliminate the need to ship Arquillian run time classes entirely.
--
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, 10 months
[JBoss JIRA] (ARQ-1318) Test Intitialisation Time Sensitive to Classpath Dependencies
by Chris Lowe (JIRA)
Chris Lowe created ARQ-1318:
-------------------------------
Summary: Test Intitialisation Time Sensitive to Classpath Dependencies
Key: ARQ-1318
URL: https://issues.jboss.org/browse/ARQ-1318
Project: Arquillian
Issue Type: Enhancement
Security Level: Public (Everyone can see)
Affects Versions: 1.0.3.Final
Reporter: Chris Lowe
My test is making use of JBoss AS7 remote deployment and takes 11+ seconds before any output is received by the AS instance. Test initialisation times appear to be sensitive to the number of classpath dependencies. Of this time:
2.5 seconds is spent loading auxiliary archives;
8 seconds is spent making the final internal in-memory deployment before sending a byte buffer over to AS7.
Inclusion of Arquillian persistence along with JMeter (which has many transitive dependencies) results in tests shipping with an arquillian-persistence.jar that is 9MiB in size. This JAR file is produced and compressed on the fly as part of the test EAR construction. The jar files are compressed again when added to the final EAR.
My typical usage scenario is to run a test from Eclipse which spawns a JVM each time so test runs are from standing start (little hotspot optimisation).
Some of the generated Arquillian jars include dependencies like log4j and slf4j which will be available in the target server. As far as I can tell, I have no control over this process.
It would be ideal if I could create an Arquillian module in AS7 to eliminate the need to ship Arquillian run time classes entirely.
--
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, 10 months