[
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<Class> 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
