[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áš, i have the similar problem with tests using Richfaces 3.3.4 (Sarissa 0.9.9.3 tru 0.9.9.6 redefines the XMLHttpRequest for all IEs, jQuery 1.3.2 is involved too). Do you have any idea how to do a workaround? I'm currently working with Graphene 2.0.0.Final-SNAPSHOT. The problem appears on IE9: Sarissa defines an XMLHttpRequest as ActiveXObject (by the way jQuery as well, up to v1.7). After all the Graphene interceptions (seems to happen in xhrInterception.js) on such ActiveXObject the browser JS console says:
"SCRIPT575: This method cannot be called until the send method has been called." or something like that, depending on XMLHTTP ActiveX version. The test on FF runs flawlessly!
I know, the RF 3 is not supported, BUT: in order to migrate to the current RF the regression tests should work(;( If we just could load and init the Graphene JS BEFORE the application´s one. By the way- perfect job implementing Graphene!
> 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-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 reassigned ARQ-1524:
--------------------------------------
Assignee: Stefan Miklosovic
> 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
>
> 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-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 commented on ARQ-1524:
----------------------------------------
The trick here is to isolate deployment logic into services and get them all upon container start and sort them according to precedence. Deployment services in native plugin will have higher precedence than these in container adapter so once native is on cp, these will be used, otherwise default deployment services from container itself will be used.
> 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
>
> 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-1524) Implement deployment logic when native plugin is not on class path
by Stefan Miklosovic (JIRA)
Stefan Miklosovic created ARQ-1524:
--------------------------------------
Summary: 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
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 {code}@Deployment{code} 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 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 updated ARQ-1524:
-----------------------------------
Description:
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
was:
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 {code}@Deployment{code} 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.
> 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
>
> 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] (ARQGRA-392) Update and enhance Graphene guide
by Juraj Húska (JIRA)
Juraj Húska created ARQGRA-392:
----------------------------------
Summary: Update and enhance Graphene guide
Key: ARQGRA-392
URL: https://issues.jboss.org/browse/ARQGRA-392
Project: Arquillian Graphene
Issue Type: Enhancement
Components: doc
Affects Versions: 2.0.0.CR2
Reporter: Juraj Húska
Priority: Minor
The Graphene guide at arquillian.org deserves couple of enhancements and updates:
*enhancements*:
* make the reference to the reference documentation more explicit - put it under own header, so it appears in the right menu
* consider referencing a link how to use jboss boms, or boms in general
*updates*
* update the versions of the artifacts once the Final is out
I would suggest to incorporate this improvements after Graphene 2.0.0.Final is released.
--
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