[jbehave-dev] [jira] Updated: (JBEHAVE-492) ConfigurableEmbedder.addSteps(..) should take classes not instances.
[ http://jira.codehaus.org/browse/JBEHAVE-492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi updated JBEHAVE-492: - Fix Version/s: 3.x Issue Type: New Feature (was: Bug) Summary: ConfigurableEmbedder.addSteps(..) should take classes not instances. (was: ConfigurableSteps.addSteps(..) should take classes not instances.) ConfigurableEmbedder.addSteps(..) should take classes not instances. 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(ListClass 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 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 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 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) ConfigurableEmbedder.addSteps(..) should take classes not instances.
[ http://jira.codehaus.org/browse/JBEHAVE-492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi updated JBEHAVE-492: - Paul, why do you say the instance of a steps class is never used? How are the methods executed? And as Brian was rightfully noting, how would DI work? Isn't your usecase too influenced by the use of Groovy to drive WebDriver? ConfigurableEmbedder.addSteps(..) should take classes not instances. 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(ListClass 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 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 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 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) ConfigurableEmbedder.addSteps(..) should take classes not instances.
[ http://jira.codehaus.org/browse/JBEHAVE-492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Hammant updated JBEHAVE-492: - Description: public void addSteps(ListClass 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. was: public void addSteps(ListClass 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 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 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 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. Added word **initial** 3x to decrease confusion about problem/solution ConfigurableEmbedder.addSteps(..) should take classes not instances. 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(ListClass 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