JBehave
  1. JBehave
  2. JBEHAVE-492

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

    Details

    • Type: New Feature New Feature
    • Status: Resolved Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 3.x
    • Fix Version/s: 3.4
    • Component/s: Core
    • Labels:
      None
    • Number of attachments :
      0

      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.

        Activity

        Hide
        Paul Hammant added a comment -

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

        Show
        Paul Hammant added a comment - > 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.
        Hide
        Mauro Talevi added a comment -

        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.

        Show
        Mauro Talevi added a comment - 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.
        Hide
        Paul Hammant added a comment -

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

        Show
        Paul Hammant added a comment - I'm still digging through code. I think things (around multi-threadedness) is worse that I thought.
        Hide
        Paul Hammant added a comment -

        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

        Show
        Paul Hammant added a comment - 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
        Hide
        Paul Hammant added a comment -

        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.

        Show
        Paul Hammant added a comment - 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.

          People

          • Assignee:
            Mauro Talevi
            Reporter:
            Paul Hammant
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: