I upgraded my project appdriver to Spring 3.2.9.RELEASE and so had to change the versions of Spring Data also.

It took a while to find the right combination of versions, some Spring projects use completely different version numbers.

As far as I know, there exists no compatibility matrix anywhere. The following table shows a combination of versions that fit together, I hope it helps :

artifact version
spring-aop 3.2.9.RELEASE
spring-aspects 3.2.9.RELEASE
spring-beans 3.2.9.RELEASE
spring-context 3.2.9.RELEASE
spring-core 3.2.9.RELEASE
spring-data-commons 1.8.0.RELEASE
spring-data-jpa 1.6.0.RELEASE
spring-data-rest-core 2.1.0.RELEASE
spring-data-rest-webmvc 2.1.0.RELEASE
spring-expression 3.2.9.RELEASE
spring-hateoas 0.12.0.RELEASE
spring-jdbc 3.2.9.RELEASE
spring-orm 3.2.9.RELEASE
spring-plugin-core 1.1.0.RELEASE
spring-test 3.2.9.RELEASE
spring-tx 3.2.9.RELEASE
spring-web 3.2.9.RELEASE
spring-webmvc 3.2.9.RELEASE

DOH is a javascript unit test framework for dojo.
It provides support for asynchrounus test, visual tests, has a robot to automate UI tests and other features.
Tests are organized in test modules, each test module is a single javascript file. For Example :

MyTests.js
define(["doh/runner"], function(doh){
    doh.register("MyTests", [     
      { name: "test one",
        setUp: function(){...},
        runTest: function(){...},
        tearDown: function(){...}
      },
      { name: "test two",
        setUp: function(){...},
        runTest: function(){...},
        tearDown: function(){...}
      },
      { name: "test three",
        setUp: function(){...},
        runTest: function(){...},
        tearDown: function(){...}
      },
  ]);
});

What I was allways missing is something comparable to @Ignore for JUnit tests, that will ommit a single testmethod from excution. What you can do with DOH, is rename the runTest method of one test for example

...
{ name: "test two",
  setUp: function(){...},
  ignoreRunTest: function(){...},
  tearDown: function(){...}
},
...

In that case ignoreRunTest will not be executed and also its 'setUp' and 'tearDown' will be ignored. Additionally all following tests like 'test three' will also be ignored.
This can be helpfull, if you have to run a test again and again when you are hunting a bug.

Startup of servlet contexts without web.xml

Servlets of release 3 can be configured programatically, without any web.xml.
With Spring and its Java-configuration you create a configuration class that implements org.springframework.web.WebApplicationInitializer.
Spring will automatically find all classes that implement this interface and start the according servlet contexts. More excatly its not Spring that searches for those classes, its the servlet container (e.g. jetty or tomcat ).
The class org.springframework.web.SpringServletContainerInitializer is annotated with
@javax.servlet.annotation.HandlesTypes(WebApplicationInitializer.class)
and implements javax.servlet.ServletContainerInitializer
According to the Servlet 3 specification the container will call org.springframework.web.SpringServletContainerInitializer.onStartup(Set<Class<?>>, ServletContext) on every class in the classpath implementing that interface, suppling a set of classes as defined in HandlesTypes

Startup order, if there is more than one context

If there is more than one class that implements WebApplicationInitializer, the order in which they are started can be controlled with the annotation org.springframework.core.Ordered .

Things that may go wrong

Different Spring versions in the classpath

If you have different versions of WebApplicationInitializer in the classpath, the servlet container may scan for the classes implementing WebApplicationInitializer of version 'A' while your configuration classes implement WebApplicationInitializer of version 'B'. And than your configuration classes will not be found and the sercletontexts will not be started.

Unexpected WebApplicationInitializers in the classpath

Do not package any WebApplicationInitializers into jars or wars that you later may have in the classpath of other web applications. They may get found and started when you do not expect it. This happend to me when I packed WebApplicationInitializers with Maven into test-jars, which were resued by other tests.

To many classes in the classpath

The servlet container has to scan the classpath, and the more classes, the longer it takes.
At least Jetty has a build in timeout, so you may get an
javax.websocket.DeploymentException thrown by
org.eclipse.jetty.websocket.jsr356.server.deploy.WebSocketServerContainerInitializer

The solution is to tell jetty which jars to scan. This will make the startup much faster and avoids the timeout. In Maven you can do it like this :

pom.xml
<plugin>
     <groupId> org.eclipse.jetty</groupId >
     <artifactId> jetty-maven-plugin</artifactId >
     <configuration>
     <webAppConfig>
         <contextPath> /${project.artifactId}</contextPath >
         <webInfIncludeJarPattern> busines-letter-*.</webInfIncludeJarPattern >
     </webAppConfig>
...

Spring logging

When you have logging configured you should find one of the following entries in your log :
If Spring finds no WebApplicationInitializer at all, you will see in the log :
No Spring WebApplicationInitializer types detected on classpath

If Spring finds at least one WebApplicationInitializer you will see :
Spring WebApplicationInitializers detected on classpath: " + initializers

By default Jetty locks files with static content on Windows, so you cannot edit and reload them by just refreshing the browser hitting F5.
To overcome this, you have to change the init-parms of the default servlet. You can do this in the web.xml by setting the parameter useFileMappedBuffer to false.
Example :

web.xml
<?xml version= "1.0" encoding ="UTF-8"?>
<web-app xmlns:xsi= "http://www.w3.org/2001/XMLSchema-instance"
        xmlns= "http://java.sun.com/xml/ns/javaee" xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
        xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
        id= "WebApp_ID" version ="3.0">
         <display-name>my-app</display-name >
         <servlet>
                <servlet-name>default</ servlet-name>
                <servlet-class>org.eclipse.jetty.servlet.DefaultServlet</servlet-class >
                <init-param>
                        <param-name>useFileMappedBuffer</param-name >
                        <param-value>false</ param-value>
                </init-param>
         </servlet>
</web-app>

Dependency injection is a software design pattern that supports inversion of control and seperation of concerns. See Wikipedia Dependency injection for an introduction.
One way to do this is to inject dependencies into the constructor of a Javascript (Constructor injection). Another way is to inject the dependencies into the properties of the Javascript object.( lets call it property injection).

Both approaches need an object called Injector that allows to register dependencies that others depend on.

//create the injector

var injector=new prefabware.injector.Injector();

An example for a dependency may be some kind of service

var logger={      
        log:function(text){console.log(text);}
    };

and an object that depends on a service may be a client

var client={
        //the injector will find this property and set it to the according service

        logger:null,  
        //using the looger..

        log:function(text){this.logger.log(text);}
        };

Constructor injection parses the signature of the constructor function for the argument names and uses call the constructor using the according dependencies as parameters. This doenst work, when the code is compressed or obfuscated, because the names of the arguments are changed. There is a workaround for that, but it requires to repeat the argument names as a string list. A bigger problem I had when using constructor injection, is that you need all dependencies ('services') instantiated before creating an object, a 'client'. In a complex application, the dependencies form a tree and determining the order of instantiation can get complicated.

So for me it turned out to be much easier to use property injection, where you create the instances in one step and inject dependencies later. The trick is to set the properties to an initial value, that enables the injector to inject the desired dependency.
register the service using an id :

injector.register({id:'prefabware.logger'},logger);

and mark the property, with the same id, so the injector can inject the dependency

..
logger:{inject:'prefabware.logger'} 
..

finally let the injector inject the dependencies

injector.injectInto(client);

You can find a working example in jsbin .
The Injector uses dojo and is part of appdriver appdriver