Support Spring AnnotationConfigApplicationContext

Hi Boris,

I've upgraded jbehave-spring to version 3.1.x (but still keeping backward compat with 2.5.x).

As for adding support for the AnnotationConfigApplicationContext, my preference would be do it via the SpringApplicationContextFactory (they are both instances of ConfigurableApplicationContext).

Two options: either we overload the meaning of "resources" for both XML and annotated class configuration resources or we use a separate list for the annotated classes (in the latter case we cannot use the varargs). I'd be tempted to go for the former overloading option. We could pass in as the "resource" the fully qualified class name and let the classloader load the class which is pass on to the AnnotationConfigApplicationContext.

Comments welcome! Either way, it'd be useful if you could fork a repo on Github (from https://github.com/jbehave/jbehave-core) and share commit links which I can pull more easily.

Hi Mauro

I've implemented changes you'd recommended

Here's the link: https://github.com/borispavlovic/jbehave-core/commit/d29353ad2995d803b6213d09e1d5611e1ffec67b

Pulled and applied patch with minor cosmetic changes.

It'd be great if you could add an example in the trader-spring module too!

Thanks!

Spring 3.1 now supports lots more features in this world and frankly I'm not sure that SpringApplicationContextFactory should have to keep up with all of them. A good overview can be found at http://blog.chariotsolutions.com/2012/01/spring-31-cool-new-features.html

One thing that I would point out (I rarely use this class by the way - I rewrite things to use my own ApplicationContext) is that if you look at the ContextConfiguration annotation used by Spring Test - that would be a good guide for what we need. That annotation takes 3 main things - a loader value (with the default ContextLoader class), locations - the set of XML files and classes - the set of @Configuration classes. That's really what's needed - the way to designate a ContextLoader and then pass it classes or locations. The ContextLoader interface is what the loader has to support.

That way we can do all kinds of things like environment support etc using the built-in ContextLoaders from Spring and the JBehave Spring factory class doesn't have to keep up with all the changes.

When running via JUnit, I use the @RunsWith(SpringJUnit4ClassRunner.class) and @ContextConfiguration. That doesn't work with the maven plugin.

With the @RunsWith(SpringAnnotatedPathRunner.class), if the @UsingSpring annotation looked like @ContextConfiguration - you might get it to work that way as the "standard" Spring way.

Hi Brian, in fact we're not using all the features of Spring 3.1, just the ones that are required to create the application context. So the idea of the SpringApplicationContextFactory is to create a facade that focuses on what we need. We can evolve it on a case-by-case basis.

Mauro - sure - we could mark this item as complete - support for Spring java-based config and I could write up a design as another improvement item on the backlog for things like environment support etc. via ContextLoader.

Added TraderStoriesUsingSpringWithAnnotationConfiguration in trader-spring example to verify behaviour of annotation-based configuration.