[JBoss JIRA] Updated: (ARQAJO-15) Implement atomic call of AjaxWaiting$waitForChangeAndReturn
by Lukas Fryc (JIRA)
[ https://issues.jboss.org/browse/ARQAJO-15?page=com.atlassian.jira.plugin.... ]
Lukas Fryc updated ARQAJO-15:
-----------------------------
Fix Version/s: 1.0.0.Alpha3
(was: 1.0.0.Alpha2)
> Implement atomic call of AjaxWaiting$waitForChangeAndReturn
> -----------------------------------------------------------
>
> Key: ARQAJO-15
> URL: https://issues.jboss.org/browse/ARQAJO-15
> Project: Arquillian Ajocado
> Issue Type: Feature Request
> Reporter: Lukas Fryc
> Assignee: Lukas Fryc
> Priority: Minor
> Fix For: 1.0.0.Alpha3
>
>
> Currently, there need to be 2 operations to run operation "waitForChangeAndReturn":
> selenium.waitForCondition(js(format("{0} != '{1}'", scriptString, oldValueString)), this.getTimeout());
> String retrieved = selenium.getEval(script);
> This idea is to implement this operation atomically in meaning of Selenium.
> It can a) made tests atomic and stable, b) improve run time a little
> All previous methods fails:
> a) call getEval evaluating doWaitForCondition followed by expression to evaluate
> b) implement own method on Selenium.prototype to call doWaitForCondition and getEval in sequence (this method also lacks the possibility of passing timeout)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 10 months
[JBoss JIRA] Created: (ARQ-399) Allow for configurable Jetty Configuration classes
by Ales Justin (JIRA)
Allow for configurable Jetty Configuration classes
--------------------------------------------------
Key: ARQ-399
URL: https://issues.jboss.org/browse/ARQ-399
Project: Arquillian
Issue Type: Task
Security Level: Public (Everyone can see)
Components: Jetty Containers
Affects Versions: 1.0.0.Alpha5
Reporter: Ales Justin
Assignee: Aslak Knutsen
Fix For: 1.0.0.Beta1
Current Jetty Embeddable Container 7 works on all v7 and v8 releases,
but its usage of Jetty Configuration classes is hardcoded,
which conflicts with renamed classes in in v7.2+.
If this was configurable, user could change which Configuration classes should be used.
Perhaps providing both default would be good;
e.g. one for pre-7.2, one for 7.2+
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 10 months