Hi,i created another POC in which i try to show how scopes can be implemented without makeing jbehave-core to specific.
I suggest to start investigating my change at GuiceAnnotationBuilder https://github.com/picpromusic/jbehave-core/blob/DependencyInjectionScopes/jbehave-guice/src/main/java/org/jbehave/core/configuration/guice/GuiceAnnotationBuilder.java diff: https://github.com/picpromusic/jbehave-core/compare/jbehave:master...DependencyInjectionScopes#diff-33 over GuiceAnnotatedEmbedderRunner https://github.com/picpromusic/jbehave-core/blob/DependencyInjectionScopes/jbehave-guice/src/main/java/org/jbehave/core/junit/guice/GuiceAnnotatedEmbedderRunner.java diff: https://github.com/picpromusic/jbehave-core/compare/jbehave:master...DependencyInjectionScopes#diff-45up to AbstractDependencyInjectionEmbedderRunner and AbstractDependencyInjectionAnnotationBuilder
https://github.com/picpromusic/jbehave-core/blob/DependencyInjectionScopes/jbehave-core/src/main/java/org/jbehave/core/junit/AbstractDependencyInjectionEmbedderRunner.java https://github.com/picpromusic/jbehave-core/blob/DependencyInjectionScopes/jbehave-core/src/main/java/org/jbehave/core/configuration/AbstractDependencyInjectionAnnotationBuilder.java For every Dependency Injection Framework the class ScopedStepCollector https://github.com/picpromusic/jbehave-core/blob/DependencyInjectionScopes/jbehave-core/src/main/java/org/jbehave/core/steps/ScopedStepCollector.java should be subclassed. See GuiceScopedStepCollector for the guice implementation. https://github.com/picpromusic/jbehave-core/blob/DependencyInjectionScopes/jbehave-guice/src/main/java/org/jbehave/core/configuration/guice/GuiceScopedStepCollector.java For any questions, feel free to contact me. Kind regards Sebastian Am 04.06.2013 22:25, schrieb Sebastian Sickelmann:
Am 03.06.2013 09:00, schrieb Mauro Talevi:Can you try expressing your need in a textual scenario? I'm not sure I fully understand the focus.I have some problems to express it. Here is try which i can add more information if needed. https://gist.github.com/picpromusic/5709019Also, could you give the generic approach a go? As said, anything that is specific to Guice only will not make it to the core.I have got an idea. But let us first try to clear the use case. Till now the changes to guice-core are small. Search for /jbehave/core/ in https://github.com/picpromusic/jbehave-core/compare/master...GuiceScenarioScope -- SebastianBut we can use your usecase to drive the behaviour. Cheers On 02/06/2013 23:44, Sebastian Sickelmann wrote:Hi, here is my small example: https://github.com/picpromusic/jbehave-core/tree/GuiceScenarioScope/examples/guice/src/main/java/org/jbehave/examples/core/guice/scope/servlet The example isn't that realistic. But it shows the need for different scope in "jbehave-test-mode" to "real-application-mode" scope (here: session) while injecting. Naturally you can also achieve this with @BeforeScenario and don't use DI at all, but i like this type of tests while working with jbehave. -- Sebastian Am 02.06.2013 21:59, schrieb Sebastian Sickelmann:Am 02.06.2013 20:23, schrieb Mauro Talevi:Hi Sebastian, there is a balance to be struck between supporting a feature and the way one can do in several DI containers. I'd rather look for a generic solution that rely on features of the DI containers.That is my expected answer to my question. It is not that easy to implement this in general.For example, if we created a context object that could be declared in each container at singleton scope, this single context could manage several scopes (rather than the containers themselves).Interessting idea. But i think it missing one point. The Focus is not on thinks that get injected in step-instances (injection in step-instance or not out of focus but it is not the main focus). The main focus lies on injections in application-code that are normally in some scope (let's say SINGLETON or SESSION) and now i want to test it. Let me try to create a small example. I will be back soon and post a link to it. -- SebastianThen we could use @Before/@After annotations to reset the state of each context-managed scope. Eg, class Context { enum Scope { SCENARIO, STORY}; void add(String name, Object o, Scope toScope); Object get(String name, Scope fromScope); void reset(Scope scope); } class ScopedLifecycle { Context context; // injected by container @BeforeScenario public void reset(){ context.reset(Scope.SCENARIO); } } Would this approproach work for you? Cheers On 02/06/2013 19:56, Sebastian Sickelmann wrote:2013/6/1 Mauro Talevi <mauro.tal...@aquilonia.org>:Hi, first of all thanks for the contribution of the prototype and the suggestion of the new feature. Here are some initial comments: - if I can resume your goal, it'd be to provide a context map - scoped at scenario or story level - via which to share objects in the implementations of the steps.That was not my intension but a solution to JBEHAVE-921 as i had understand it a few days ago. But i think i missed the intenssion of JBEHAVE-921.- as such it's not something that is necessarily tied to feature of Guice, although DI containers may support in different ways.My idea was to have DI-Scopes at the Scenario- and Story-Levels. So that i can test a system, that is Guice-enabled, more easily with jbehave. I don't have trouble with shared mutable state between Step-Instances, as Barrie McGuire in JBEHAVE-921, but i need to manage "reset of state" at story- and scenarion-level for my instances more easily. Normally these instances are in SINGLETON-Scope in the real application, .Now, taking a step back, would it be conceptually equivalent to defining a context map object (which different keys for different scopes) and simply declaring it and having it available in the DI containers?The question i have is, what is with other DI containers? Do they also have Scopes? What would be the procedure to bring such new concepts to jbehave if it could be implemented for all supported DI-containers?In this case, it could be in principle supported entirely by the user configuration (albeit using some common context classes). I'd like to understand better the use case that's driving this requirement.Ok. I also think that's the best way to unterstand it. So here is my usecase: I ran into same problem while I created test cases for a guice-enabled application. I got multiple step-instances that need to share state to implement the teststeps. So i created the step-instances with Guice(that was before i detected jbehave-guice) and let inject my system under test to the step-instances. But i run into problems at Scenario and Story-Boundaries, Where i need to reset my system-state. So i started to implement Scenario-Scope with Guice. Hope that help to understand my requirement. It has nothing to do with JBEHAVE-921. -- Sebastian
--------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
