Hi Sebastian,
as far I can see this is still Guice-specific. There is no guarantee
that other DI containers would actually support scopes.
I can understand your syntactical preference for Guice-centric
solutions, but I think it's not a very generic path to follow.
What about trying to implement the other more generic solution we
discussed with controls via @Before/After annotations?
Cheers
On 11/06/2013 21:59, Sebastian Sickelmann wrote:
Hi Mauro,
i created a new POC which now don't misuse the StepCollector for
inserting pseudo-steps that tells the Guice-Scopes to start and stop.
I now use a part of an implementation in found in a fork by andreiserea
https://github.com/andreiserea/jbehave-core/commits/jbehave-3.7.5-arquillian
I cherry-picked e3dee13f49321067d33993a207d9fc8f2d5a4a5c and
e0b15759d478fbd80f34ece3e8e0628b9a889f3e and removed all unneeded
functionality and just leave the LifecycleOberservers.
My new POC is in my branch DependencyInjectionScopesWithLifecycle
at my fork git://github.com/picpromusic/jbehave-core.git
Use can see a quick diff here:
https://github.com/picpromusic/jbehave-core/compare/master...DependencyInjectionScopesWithLifecycle
The POC shows a solution for providing the same scopes also for
the other containers. Every Container-Impl should subclass
org.jbehave.core.configuration.AbstractDependencyInjectionAnnotationBuilder
see createScopeModule() in
org.jbehave.core.configuration.guice.GuiceAnnotationBuilder and
org.jbehave.core.configuration.guice.GuiceScopeModule and
org.jbehave.core.guice.ScopeLifecycleListener for an example.
Pico, Spring and Weld are not implemented but are prepared to do so.
Just implement the custom scope and create/return additional Modul in
createScopeModule()
Kind regards
Sebastian
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.
Also, could you give the generic approach a go? As said, anything that
is specific to Guice only will not make it to the core.
But 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.
-- Sebastian
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
