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.
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-mo
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/5709019
Also, could y
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/
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
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
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 im
