It provides support for asynchrounus test, visual tests, has a robot to automate UI tests and other features.
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
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.
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
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 :
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.
Dependency injection is a software design pattern that supports inversion of control and seperation of concerns. See Wikipedia Dependency injection for an introduction.
Both approaches need an object called Injector that allows to register dependencies that others depend on.
An example for a dependency may be some kind of service
and an object that depends on a service may be a client
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 :
and mark the property, with the same id, so the injector can inject the dependency
finally let the injector inject the dependencies
You can find a working example in jsbin .
The Injector uses dojo and is part of appdriver appdriver