[jbehave-dev] [jira] Resolved: (JBEHAVE-493) Split Firefox logic out of generic Type provider and into own class.
[ http://jira.codehaus.org/browse/JBEHAVE-493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Hammant resolved JBEHAVE-493. -- Resolution: Fixed > Split Firefox logic out of generic Type provider and into own class. > > > Key: JBEHAVE-493 > URL: http://jira.codehaus.org/browse/JBEHAVE-493 > Project: JBehave > Issue Type: Improvement > Components: Web Selenium >Reporter: Paul Hammant >Assignee: Paul Hammant > Fix For: web-3.4 > > -- 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] Resolved: (JBEHAVE-494) Create LazyWebDriver to allow for WebDriver canonical PageFactory.initElements(..) processing of annotated fields.
[ http://jira.codehaus.org/browse/JBEHAVE-494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Hammant resolved JBEHAVE-494. -- Resolution: Fixed > Create LazyWebDriver to allow for WebDriver canonical > PageFactory.initElements(..) processing of annotated fields. > -- > > Key: JBEHAVE-494 > URL: http://jira.codehaus.org/browse/JBEHAVE-494 > Project: JBehave > Issue Type: Improvement > Components: Web Selenium >Reporter: Paul Hammant >Assignee: Paul Hammant > Fix For: web-3.4 > > -- 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-scm] jbehave-tutorial branch, master, updated. fbfe439b894181b57f3ea8a1e3dd481567d5df2b
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "jbehave-tutorial". The branch, master has been updated via fbfe439b894181b57f3ea8a1e3dd481567d5df2b (commit) from 1c54274ac822675f4d72bc6d2004ef66216dad39 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - commit fbfe439b894181b57f3ea8a1e3dd481567d5df2b Author: Paul Hammant Date: Tue Apr 26 14:55:07 2011 -0500 JBEHAVE-494: use LazyWebDriver --- Summary of changes: .../src/main/groovy/pages/AdvancedSearch.groovy|5 +++-- etsy-stories/src/main/groovy/pages/BasePage.groovy |5 +++-- etsy-stories/src/main/groovy/pages/Buy.groovy |6 -- .../src/main/groovy/pages/CartContents.groovy |7 --- etsy-stories/src/main/groovy/pages/Home.groovy |5 +++-- .../src/main/groovy/pages/SearchResults.groovy |5 +++-- etsy-stories/src/main/groovy/pages/Site.groovy |5 +++-- etsy-stories/src/main/groovy/pages/Treasury.groovy |6 -- .../jbehave/tutorials/etsy/EtsyDotComStories.java | 10 ++ 9 files changed, 33 insertions(+), 21 deletions(-) hooks/post-receive -- jbehave-tutorial To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email";>http://xircles.codehaus.org/manage_email
[jbehave-scm] jbehave-web branch, master, updated. jbehave-web-3.3.1-6-gd7fd308
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "jbehave-web". The branch, master has been updated via d7fd308f426f954aeff6fd4c9c0487fa2a1dc5bc (commit) from fd3bb06b3206a7184a8d540acda8ab01cc5c0b59 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - commit d7fd308f426f954aeff6fd4c9c0487fa2a1dc5bc Author: Paul Hammant Date: Tue Apr 26 14:51:33 2011 -0500 JBEHAVE-493: separate FF logic, JBEHAVE-494 to allow LazyWebDriver in lieu of a provider --- Summary of changes: .../web/selenium/FirefoxWebDriverProvider.java | 30 +++ .../org/jbehave/web/selenium/LazyWebDriver.java| 69 .../web/selenium/TypeWebDriverProvider.java| 27 ++- .../org/jbehave/web/selenium/WebDriverPage.java|8 +- .../jbehave/web/selenium/LazyWebDriverTest.java| 83 5 files changed, 193 insertions(+), 24 deletions(-) create mode 100644 web-selenium/src/main/java/org/jbehave/web/selenium/FirefoxWebDriverProvider.java create mode 100644 web-selenium/src/main/java/org/jbehave/web/selenium/LazyWebDriver.java create mode 100644 web-selenium/src/test/java/org/jbehave/web/selenium/LazyWebDriverTest.java hooks/post-receive -- jbehave-web To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email";>http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Updated: (JBEHAVE-493) Split Firefox logic out of generic Type provider and into own class.
[ http://jira.codehaus.org/browse/JBEHAVE-493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi updated JBEHAVE-493: - Fix Version/s: (was: 3.4) web-3.4 > Split Firefox logic out of generic Type provider and into own class. > > > Key: JBEHAVE-493 > URL: http://jira.codehaus.org/browse/JBEHAVE-493 > Project: JBehave > Issue Type: Improvement > Components: Web Selenium >Reporter: Paul Hammant >Assignee: Paul Hammant > Fix For: web-3.4 > > -- 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-494) Create LazyWebDriver to allow for WebDriver canonical PageFactory.initElements(..) processing of annotated fields.
[ http://jira.codehaus.org/browse/JBEHAVE-494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi updated JBEHAVE-494: - Fix Version/s: (was: 3.4) web-3.4 > Create LazyWebDriver to allow for WebDriver canonical > PageFactory.initElements(..) processing of annotated fields. > -- > > Key: JBEHAVE-494 > URL: http://jira.codehaus.org/browse/JBEHAVE-494 > Project: JBehave > Issue Type: Improvement > Components: Web Selenium >Reporter: Paul Hammant >Assignee: Paul Hammant > Fix For: web-3.4 > > -- 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] Created: (JBEHAVE-494) Create LazyWebDriver to allow for WebDriver canonical PageFactory.initElements(..) processing of annotated fields.
Create LazyWebDriver to allow for WebDriver canonical PageFactory.initElements(..) processing of annotated fields. -- Key: JBEHAVE-494 URL: http://jira.codehaus.org/browse/JBEHAVE-494 Project: JBehave Issue Type: Improvement Components: Web Selenium Reporter: Paul Hammant Assignee: Paul Hammant Fix For: 3.4 -- 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] Created: (JBEHAVE-493) Split Firefox logic out of generic Type provider and into own class.
Split Firefox logic out of generic Type provider and into own class. Key: JBEHAVE-493 URL: http://jira.codehaus.org/browse/JBEHAVE-493 Project: JBehave Issue Type: Improvement Components: Web Selenium Reporter: Paul Hammant Assignee: Paul Hammant Fix For: 3.4 -- 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] Commented: (JBEHAVE-492) ConfigurableEmbedder.addSteps(..) should take classes not instances.
[
http://jira.codehaus.org/browse/JBEHAVE-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=264766#action_264766
]
Paul Hammant commented on JBEHAVE-492:
--
OK, here's the unfortunate way we'll have to do this I think :-
https://github.com/jbehave/jbehave-tutorial/commit/7b642bc1d692edfd2dffe098c642e29cba856ab4
The steps containers cannot attempt to do ThreadLocal because JBehave works
with instances instantiated up front.
However, injected deps (into pages and/or steps classes depending on the number
of containers) can be ThreadLocal managed (ThreadCached for PicoContainer).
This commit illustrates that.
Unfortunately, this means the end-user needs to think about statelessness in at
least steps classes.
> 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(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-scm] jbehave-tutorial branch, master, updated. 1c54274ac822675f4d72bc6d2004ef66216dad39
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "jbehave-tutorial". The branch, master has been updated via 1c54274ac822675f4d72bc6d2004ef66216dad39 (commit) via 7b642bc1d692edfd2dffe098c642e29cba856ab4 (commit) from 4b9f1d6dbe25c7bc364c59ca56214f5d8eab1d56 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - commit 1c54274ac822675f4d72bc6d2004ef66216dad39 Merge: 7b642bc1d692edfd2dffe098c642e29cba856ab4 4b9f1d6dbe25c7bc364c59ca56214f5d8eab1d56 Author: Paul Hammant Date: Tue Apr 26 13:13:28 2011 -0500 Merge branch 'master' of ssh://git.codehaus.org/jbehave-tutorial commit 7b642bc1d692edfd2dffe098c642e29cba856ab4 Author: Paul Hammant Date: Tue Apr 26 12:57:31 2011 -0500 different example for those wanting to maintan state for multi-threaded running --- Summary of changes: .../jbehave/tutorials/etsy/EtsyDotComStories.java | 17 + 1 files changed, 13 insertions(+), 4 deletions(-) hooks/post-receive -- jbehave-tutorial To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email";>http://xircles.codehaus.org/manage_email
[jbehave-dev] [jira] Commented: (JBEHAVE-492) ConfigurableEmbedder.addSteps(..) should take classes not instances.
[
http://jira.codehaus.org/browse/JBEHAVE-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=264747#action_264747
]
Paul Hammant commented on JBEHAVE-492:
--
You guys may be right - only the fist instance made by implementors of
AbstractStepsFactory.stepsInstances() is used. Attempts to make separate
instances available on ThreadLocal are ignored :(
> 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(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] Commented: (JBEHAVE-492) ConfigurableEmbedder.addSteps(..) should take classes not instances.
[
http://jira.codehaus.org/browse/JBEHAVE-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=264744#action_264744
]
Paul Hammant commented on JBEHAVE-492:
--
I'm still digging through code. I think things (around multi-threadedness) is
worse that I thought.
> 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(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] Commented: (JBEHAVE-492) ConfigurableEmbedder.addSteps(..) should take classes not instances.
[
http://jira.codehaus.org/browse/JBEHAVE-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=264738#action_264738
]
Mauro Talevi commented on JBEHAVE-492:
--
To do that, we'd loose the nice abstraction that we have wrt multiple DI
containers. And not at all easy given the current design.
Rather, it seems to me that we should focus on making the configuration
thread-specific.
Passing the classes instead of the instances is not necessarily the only way to
achieve the stated goal.
> 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(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] Commented: (JBEHAVE-492) ConfigurableEmbedder.addSteps(..) should take classes not instances.
[
http://jira.codehaus.org/browse/JBEHAVE-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=264735#action_264735
]
Paul Hammant commented on JBEHAVE-492:
--
> So if you really need new steps classes (and others)
> per thread - then what I'm not sure about is how we
> get the candidate steps in the configuration to be
> thread-specific...I'd have to think about that
> design a bit more...
My ideal is that the startup phase of JBehave deals with class-defs (kinda like
DI containers do). Later when instances are needed for step execution, they are
acquired from one of: Pico, Spring, Guice, Weld ... or a default non-DI JBehave
container where everything was pre-instantiated.
> 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(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] Commented: (JBEHAVE-492) ConfigurableEmbedder.addSteps(..) should take classes not instances.
[
http://jira.codehaus.org/browse/JBEHAVE-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=264734#action_264734
]
Paul Hammant commented on JBEHAVE-492:
--
In Pico-land you could register a component by a) instance to avoid the
ThreadCaching stuff, b) have an even more primordial container that is plain
'Caching' (equiv to Spring's Singleton scope), or c) register something by type
in the otherwise ThreadCaching container, but with an explicit Cached behavior
(for that there's about three ways), but here is one way:
steps1.as(CACHED).addComponent(new
ClassName("housekeeping.EmptyCartIfNotAlready"));
My problem right now is that I'm pinging back and forth from the case in work
(that's busted on WebDriverProvider.get() in BasePage's ctor) and equivalent
stuff in the Etsy tutorial which is not as sophisticated :-(
> 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(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] Commented: (JBEHAVE-492) ConfigurableEmbedder.addSteps(..) should take classes not instances.
[
http://jira.codehaus.org/browse/JBEHAVE-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=264732#action_264732
]
Brian Repko commented on JBEHAVE-492:
-
Take that back - Spring 3.0 has thread scope per bean. I'm assuming you don't
want to try that in Spring? (he laughs as he writes...)
> 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(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] Commented: (JBEHAVE-492) ConfigurableEmbedder.addSteps(..) should take classes not instances.
[
http://jira.codehaus.org/browse/JBEHAVE-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=264730#action_264730
]
Brian Repko commented on JBEHAVE-492:
-
Got it - thanks, Paul.
ThreadCaching is interesting - in Spring, bean scopes are singleton, prototype
(new bean for each get call) and a bunch related to web
(request/session/global-session-for-portlets) but nothing like once-per-thread.
Problem I see with that is that its a global policy on all objects in the
container rather than per-bean.
And obviously the kicker is the instance variables during multi-threaded
execution. One could make the steps classes singletons that then reach out to
threadlocals (or threadlocal wrappers) to get data that would be instance
variables. But then the global nature of the ThreadCaching will hit you (some
objects are thread-specific and some aren't).
So if you really need new steps classes (and others) per thread - then what I'm
not sure about is how we get the candidate steps in the configuration to be
thread-specific...I'd have to think about that design a bit more...
> 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(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] Commented: (JBEHAVE-492) ConfigurableEmbedder.addSteps(..) should take classes not instances.
[
http://jira.codehaus.org/browse/JBEHAVE-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=264727#action_264727
]
Paul Hammant commented on JBEHAVE-492:
--
Here's the initial stack trace (EtsyStories constructor):
http://pastebin.com/RXNFR157
> 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(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] Commented: (JBEHAVE-492) ConfigurableEmbedder.addSteps(..) should take classes not instances.
[
http://jira.codehaus.org/browse/JBEHAVE-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=264726#action_264726
]
Mauro Talevi commented on JBEHAVE-492:
--
So when are the steps classes instantiated when running in SauceLabs? Is this
specific to the use of Groovy (effectively you're using a default constructor
and GrooBe to autowire your pages) or generic for all Java classes?
> 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(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] Issue Comment Edited: (JBEHAVE-492) ConfigurableEmbedder.addSteps(..) should take classes not instances.
[
http://jira.codehaus.org/browse/JBEHAVE-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=264724#action_264724
]
Paul Hammant edited comment on JBEHAVE-492 at 4/26/11 11:32 AM:
If you don't believe me, add a break-point to, say, CartContent's constructor
and run the three tests on SauceLabs.
was (Author: paul):
If you don't believe me, add a break-point to BasePage's constructor and
run the three tests on SauceLabs.
> 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(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] Issue Comment Edited: (JBEHAVE-492) ConfigurableEmbedder.addSteps(..) should take classes not instances.
[
http://jira.codehaus.org/browse/JBEHAVE-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=264723#action_264723
]
Paul Hammant edited comment on JBEHAVE-492 at 4/26/11 11:24 AM:
So the Etsy-Stories module in 'tutorial' is using a ThreadLocal caching
mechanism. This is to allow the multi-threaded running of tests on stacks like
SauceLabs.com. As any of the page objects or steps classes may maintain state,
they need to be separate instances.
JBehave (as correctly suggested by Brian) does not instantiate page objects,
steps classes or other dependent components. PicoContainer does (for the
Etsy example).
Refer
https://github.com/jbehave/jbehave-tutorial/blob/master/etsy-stories/src/main/java/org/jbehave/tutorials/etsy/EtsyDotComStories.java.
Search in page for ThreadCaching, see that it is used in a container's
instantiation (all comps in that container will be 'new' per thread). the
makeContainer() invocation makes a child container with the same spec
(ThreadCaching). Thus the comps registered at that level are newed up per
thread too.
Thus, and I am 100% sure about this. Any instances made by PicoStepsFactory
(line 126 presently) are not used by actual step invocation, nor those steps
instances invocation into page objects. At least when in multithreaded mode.
In regular single-threaded mode, because we coded a class
'NonThreadingExecutorService' the (serial) execution thread will be the same as
the thread that passed through the constructor of EtsyStories.
So. In my use-case, these are not singletons because of the multithreaded needs
because of the concurrent leasing of browsers from SauceLabs. In my use-case
I'm 100% that EtsyDotComSteps, housekeeping.EmptyCartIfNotAlready and the seven
Groovy classes in the pages package are instantiated needlessly at during the
construction phase of EtsyStories.
was (Author: paul):
So the Etsy-Stories module in 'tutorial' is using a ThreadLocal caching
mechanism. This is to allow the multi-threaded running of tests on stacks like
SauceLabs.com. As any of the page objects or steps classes may maintain state,
they need to be separate instances.
JBehave (as correctly suggested by Brian) does not instantiate page objects,
steps classes or other dependent components. PicoContainer does.
Refer
https://github.com/jbehave/jbehave-tutorial/blob/master/etsy-stories/src/main/java/org/jbehave/tutorials/etsy/EtsyDotComStories.java.
Search in page for ThreadCaching, see that it is used in a container's
instantiation (all comps in that container will be 'new' per thread). the
makeContainer() invocation makes a child container with the same spec
(ThreadCaching). Thus the comps registered at that level are newed up per
thread too.
Thus, and I am 100% sure about this. Any instances made by PicoStepsFactory
(line 126 presently) are not used by actual step invocation, nor those steps
instances invocation into page objects. At least when in multithreaded mode.
In regular single-threaded mode, because we coded a class
'NonThreadingExecutorService' the (serial) execution thread will be the same as
the thread that passed through the constructor of EtsyStories.
So. In my use-case, these are not singletons because of the multithreaded needs
because of the concurrent leasing of browsers from SauceLabs. In my use-case
I'm 100% that EtsyDotComSteps, housekeeping.EmptyCartIfNotAlready and the seven
Groovy classes in the pages package are instantiated needlessly at during the
construction phase of EtsyStories.
> 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(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 p
[jbehave-dev] [jira] Commented: (JBEHAVE-492) ConfigurableEmbedder.addSteps(..) should take classes not instances.
[
http://jira.codehaus.org/browse/JBEHAVE-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=264723#action_264723
]
Paul Hammant commented on JBEHAVE-492:
--
So the Etsy-Stories module in 'tutorial' is using a ThreadLocal caching
mechanism. This is to allow the multi-threaded running of tests on stacks like
SauceLabs.com. As any of the page objects or steps classes may maintain state,
they need to be separate instances.
JBehave (as correctly suggested by Brian) does not instantiate page objects,
steps classes or other dependent components. PicoContainer does.
Refer
https://github.com/jbehave/jbehave-tutorial/blob/master/etsy-stories/src/main/java/org/jbehave/tutorials/etsy/EtsyDotComStories.java.
Search in page for ThreadCaching, see that it is used in a container's
instantiation (all comps in that container will be 'new' per thread). the
makeContainer() invocation makes a child container with the same spec
(ThreadCaching). Thus the comps registered at that level are newed up per
thread too.
Thus, and I am 100% sure about this. Any instances made by PicoStepsFactory
(line 126 presently) are not used by actual step invocation, nor those steps
instances invocation into page objects. At least when in multithreaded mode.
In regular single-threaded mode, because we coded a class
'NonThreadingExecutorService' the (serial) execution thread will be the same as
the thread that passed through the constructor of EtsyStories.
So. In my use-case, these are not singletons because of the multithreaded needs
because of the concurrent leasing of browsers from SauceLabs. In my use-case
I'm 100% that EtsyDotComSteps, housekeeping.EmptyCartIfNotAlready and the seven
Groovy classes in the pages package are instantiated needlessly at during the
construction phase of EtsyStories.
> 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(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] Commented: (JBEHAVE-492) ConfigurableEmbedder.addSteps(..) should take classes not instances.
[
http://jira.codehaus.org/browse/JBEHAVE-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=264724#action_264724
]
Paul Hammant commented on JBEHAVE-492:
--
If you don't believe me, add a break-point to BasePage's constructor and run
the three tests on SauceLabs.
> 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(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] Commented: (JBEHAVE-492) ConfigurableEmbedder.addSteps(..) should take classes not instances.
[
http://jira.codehaus.org/browse/JBEHAVE-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=264719#action_264719
]
Brian Repko commented on JBEHAVE-492:
-
Is this more related to multi-threading? Perhaps the design for multi-threaded
execution needs to be worked out more?
> 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(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] Commented: (JBEHAVE-492) ConfigurableEmbedder.addSteps(..) should take classes not instances.
[
http://jira.codehaus.org/browse/JBEHAVE-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=264715#action_264715
]
Mauro Talevi commented on JBEHAVE-492:
--
Sorry, still no wiser about this use case :-( What do you mean by "initial
instance"?
> 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(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) 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(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.
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 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(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) 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(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 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] Commented: (JBEHAVE-492) ConfigurableEmbedder.addSteps(..) should take classes not instances.
[
http://jira.codehaus.org/browse/JBEHAVE-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=264708#action_264708
]
Brian Repko commented on JBEHAVE-492:
-
Hunh? When using the DI/IoC container the steps classes are created with the
container and we pass in instances. They are singletons for the most part and
should work just fine in a multi-threaded environment but they aren't created
by JBehave.
The Spring-Security example shows this with spring but I think the general
trader examples do this as well. I'm pretty sure you don't want JBehave to get
into the fun intricacies of object creation.
> 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(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 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] Commented: (JBEHAVE-492) ConfigurableEmbedder.addSteps(..) should take classes not instances.
[
http://jira.codehaus.org/browse/JBEHAVE-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=264677#action_264677
]
Paul Hammant commented on JBEHAVE-492:
--
End-users. In the meantime, if you're trying to do the WebDriver PageFactory
style of field initialization in the constructor to BasePage (refer
http://code.google.com/p/selenium/wiki/PageFactory), change from this style:
PageFactory.initElements(driverProvider.get(), this);
.. to this style:
try {
PageFactory.initElements(driverProvider.get(), this);
} catch (Exception e) {
// this is OK, the first instance of each page is created by JBehave for the
purposes of inspecting the methods of steps classes. The instance itself is
not needed. Therefore other methods in this class are not called for an
instance that has skipped the WebDriver PageFactory style field initialization.
}
> 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(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 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:
-
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(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 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] Created: (JBEHAVE-492) ConfigurableSteps.addSteps(..) should take classes not instances.
ConfigurableSteps.addSteps(..) should take classes not instances.
-
Key: JBEHAVE-492
URL: http://jira.codehaus.org/browse/JBEHAVE-492
Project: JBehave
Issue Type: Bug
Components: Core
Affects Versions: 3.x
Reporter: Paul Hammant
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 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
