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.
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).
Then 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
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
