[jbehave-dev] [jira] Updated: (JBEHAVE-492) CandidateSteps instances should be created by StoryRunner context allowing for multi-threaded stateful steps logic
[
http://jira.codehaus.org/browse/JBEHAVE-492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mauro Talevi updated JBEHAVE-492:
-
Description:
In multi-threaded mode, the steps instances need to be instantiated per thread.
A way to do this is to pass the InjectableStepsFactory to the StoryRunner run
context and let the context instantiate the candidate steps per thread.
was:
public void addSteps(List steps) {
}
... would be better.
Why? There's an instance that's made during the setup of a suite (refer
EtsyStories). If you are running in multi-threaded mode, that **initial**
instance is **never** used during the running of scenarios.
In multi-threaded mode, there's a constructor for BasePage that takes a
WebDriverProvider. When it is passed in during the primordial instantiation
phase, no WebDriver has been initialized. We don't want to do that of course
because (a) we know this **initial** instance is going to be garbage collected
and never used, and (b) on SauceLabs at least it would result in browser
opening in the cloud then closing (or maybe not closing, but never used; I'm
not sure).
JBehave does not actually need the **initial** instance. I believe this is
provable. Instead it could perfectly well use the class definition without the
instance ref somehow.
Proposal: Long overdue, I think, but could for 4.x we shift to using
class-defs. Either rework CandidateSteps to hold a Class rather than an
instance. Or further do a away (move the logic elsewhere) with CandidateSteps,
and use the POJO Step's class-def directly.
> CandidateSteps instances should be created by StoryRunner context allowing
> for multi-threaded stateful steps logic
> --
>
> Key: JBEHAVE-492
> URL: http://jira.codehaus.org/browse/JBEHAVE-492
> Project: JBehave
> Issue Type: New Feature
> Components: Core
>Affects Versions: 3.x
>Reporter: Paul Hammant
>Assignee: Mauro Talevi
> Fix For: 3.4
>
>
> In multi-threaded mode, the steps instances need to be instantiated per
> thread.
> A way to do this is to pass the InjectableStepsFactory to the StoryRunner run
> context and let the context instantiate the candidate steps per thread.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Updated: (JBEHAVE-492) CandidateSteps instances should be created by StoryRunner context allowing for multi-threaded stateful steps logic
[
http://jira.codehaus.org/browse/JBEHAVE-492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mauro Talevi updated JBEHAVE-492:
-
Fix Version/s: (was: 3.x)
3.4
Assignee: Mauro Talevi
> CandidateSteps instances should be created by StoryRunner context allowing
> for multi-threaded stateful steps logic
> --
>
> Key: JBEHAVE-492
> URL: http://jira.codehaus.org/browse/JBEHAVE-492
> Project: JBehave
> Issue Type: New Feature
> Components: Core
>Affects Versions: 3.x
>Reporter: Paul Hammant
>Assignee: Mauro Talevi
> Fix For: 3.4
>
>
> public void addSteps(List steps) {
> }
> ... would be better.
> Why? There's an instance that's made during the setup of a suite (refer
> EtsyStories). If you are running in multi-threaded mode, that **initial**
> instance is **never** used during the running of scenarios.
> In multi-threaded mode, there's a constructor for BasePage that takes a
> WebDriverProvider. When it is passed in during the primordial instantiation
> phase, no WebDriver has been initialized. We don't want to do that of course
> because (a) we know this **initial** instance is going to be garbage
> collected and never used, and (b) on SauceLabs at least it would result in
> browser opening in the cloud then closing (or maybe not closing, but never
> used; I'm not sure).
> JBehave does not actually need the **initial** instance. I believe this is
> provable. Instead it could perfectly well use the class definition without
> the instance ref somehow.
> Proposal: Long overdue, I think, but could for 4.x we shift to using
> class-defs. Either rework CandidateSteps to hold a Class rather than an
> instance. Or further do a away (move the logic elsewhere) with
> CandidateSteps, and use the POJO Step's class-def directly.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Updated: (JBEHAVE-492) CandidateSteps instances should be created by StoryRunner context allowing for multi-threaded stateful steps logic
[
http://jira.codehaus.org/browse/JBEHAVE-492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mauro Talevi updated JBEHAVE-492:
-
Summary: CandidateSteps instances should be created by StoryRunner context
allowing for multi-threaded stateful steps logic (was:
ConfigurableEmbedder.addSteps(..) should take classes not instances.)
> CandidateSteps instances should be created by StoryRunner context allowing
> for multi-threaded stateful steps logic
> --
>
> Key: JBEHAVE-492
> URL: http://jira.codehaus.org/browse/JBEHAVE-492
> Project: JBehave
> Issue Type: New Feature
> Components: Core
>Affects Versions: 3.x
>Reporter: Paul Hammant
> Fix For: 3.x
>
>
> public void addSteps(List steps) {
> }
> ... would be better.
> Why? There's an instance that's made during the setup of a suite (refer
> EtsyStories). If you are running in multi-threaded mode, that **initial**
> instance is **never** used during the running of scenarios.
> In multi-threaded mode, there's a constructor for BasePage that takes a
> WebDriverProvider. When it is passed in during the primordial instantiation
> phase, no WebDriver has been initialized. We don't want to do that of course
> because (a) we know this **initial** instance is going to be garbage
> collected and never used, and (b) on SauceLabs at least it would result in
> browser opening in the cloud then closing (or maybe not closing, but never
> used; I'm not sure).
> JBehave does not actually need the **initial** instance. I believe this is
> provable. Instead it could perfectly well use the class definition without
> the instance ref somehow.
> Proposal: Long overdue, I think, but could for 4.x we shift to using
> class-defs. Either rework CandidateSteps to hold a Class rather than an
> instance. Or further do a away (move the logic elsewhere) with
> CandidateSteps, and use the POJO Step's class-def directly.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
