Support for Weld/Context and Dependency Injection framework

This is the commit with the initial support
https://github.com/aaronwalker/jbehave-core/commit/03884a58b58164675d569186166db7e7d3ad38a9

I still need to add an example but I thought I send this to get some feedback

Feel free to assign this issue to me

Hi Aaron, thanks for your proposed contribution.

We're happy to support Weld, but as there are competing JSRs in the same space, the emphasis should be on the implementing framework rather than the JSR it implements. Each framework would declare the JSR it needs as a dependency.

Hence, could you please:

1. Renamed the module to jbehave-weld and rename all CDI references to Weld (amongst other things CDI for most people means something else: Constructor Dependency Injection)
2. Remove all static access to logging frameworks (use a monitor pattern instead which can accommodate a logging implementation if so desired)

I'm confused - I thought CDI was the spec and Spring/Guice/Weld (Pico?) all support it.

And then for logging - we capture that all through a Monitor. Probably best to direct Aaron to sample of that code. But we don't use a logging framework.

neither Spring or Guice support JSR-299. Weld is the reference implementation of this JSR.

JSR-330 is the one supported by Guice/Spring/Weld but it's really just a standardization of the annotations used by these frameworks. By itself it's not very useful. It just means it should be less work to port code between DI frameworks.

I'm in the process of re-working the code as per your suggestions

cheers

Aaron

I've created a pull request on github https://github.com/jbehave/jbehave-core/pull/9 it incorporates the changes based on the feedback.

Other than the examples what other documentation is needed. I'm planning to write a blog post on how to best use it.

cheers

Aaron

Hi Aaron, pulled request and pushed out new snapshot.

As for docs, it'd be fantastic if you could update the distribution/src/site/content/dependency-injection.html page.

Great job so far - thanks!

Hi Aaron, can you please test the latest snapshot or beta and let us know if you are happy to resolve?

I've been using 3.3-SNAPSHOT for my own jbehave test and have now tested them with 3.3-beta-3 and everything is working. I getting 1 unexpected failure with the trader-weld example

org/jbehave/examples/trader/stories/examples_table_loaded_from_classpath.story
Scenario: Table parameter loaded from a classpath resource

org.jbehave.core.io.InvalidStoryResource: Invalid story resource for org/jbehave/examples/trader/stories/traders.table
at org.jbehave.core.io.LoadFromURL.loadResourceAsText(LoadFromURL.java:17)
at org.jbehave.core.model.ExamplesTableFactory.createExamplesTable(ExamplesTableFactory.java:64)
at org.jbehave.core.steps.ParameterConverters$ExamplesTableConverter.convertValue(ParameterConverters.java:540)
at org.jbehave.core.steps.ParameterConverters.convert(ParameterConverters.java:112)
at org.jbehave.core.steps.StepCreator.convertParameters(StepCreator.java:183)
at org.jbehave.core.steps.StepCreator.access$1200(StepCreator.java:21)
at org.jbehave.core.steps.StepCreator$ParameterizedStep.parametriseStep(StepCreator.java:463)
at org.jbehave.core.steps.StepCreator$ParameterizedStep.perform(StepCreator.java:427)
at org.jbehave.core.embedder.StoryRunner$FineSoFar.run(StoryRunner.java:281)

I haven't had a chance to look into this one yet but I suspect it's just a configuration issue. Other than this failure it's all looking good.

That's due to the default ResourceLoader of the ExampleTableFactory, which looks up resources as URLs.

I've now changed that so that the default resources are looked up on the classpath (JBEHAVE-456).