CandidateSteps instances should be created by StoryRunner context allowing for multi-threaded stateful steps logic

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

catch (Exception e)

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.

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?

Added word *initial* 3x to decrease confusion about problem/solution

Sorry, still no wiser about this use case What do you mean by "initial instance"?

Is this more related to multi-threading? Perhaps the design for multi-threaded execution needs to be worked out more?

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.

If you don't believe me, add a break-point to, say, CartContent's constructor and run the three tests on SauceLabs.

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?

Here's the initial stack trace (EtsyStories constructor): http://pastebin.com/RXNFR157

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...

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...)

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

> 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.

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.

I'm still digging through code. I think things (around multi-threadedness) is worse that I thought.

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

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.