Dropwizard/Jersey - missing dependency for public method when running tests

Question

I've encountered "Missing dependency" exception when running resourceTest using Dropwizard: 0.6.1 (jersey 1.15), has anybody had experience on this case?

My test file:

public class MyResourceImplTest extends ResourceTest {
   ........
    @Override
    protected void setUpResources() throws Exception {
        addResource(new MyResourceImpl(new myConfiguration()));
    }
}

Exception:

Dec 13, 2012 2:10:41 PM com.sun.jersey.test.framework.spi.container.inmemory.InMemoryTestContainerFactory$InMemoryTestContainer <init>
INFO: Creating low level InMemory test container configured at the base URI http://localhost:9998/
Dec 13, 2012 2:10:42 PM com.sun.jersey.test.framework.spi.container.inmemory.InMemoryTestContainerFactory$InMemoryTestContainer start
INFO: Starting low level InMemory test container
Dec 13, 2012 2:10:42 PM com.sun.jersey.server.impl.application.WebApplicationImpl _initiate
INFO: Initiating Jersey application, version 'Jersey: 1.15 10/30/2012 02:40 PM'
Dec 13, 2012 2:10:42 PM com.sun.jersey.spi.inject.Errors processErrorMessages
SEVERE: The following errors and warnings have been detected with resource and/or provider classes:
  SEVERE: Missing dependency for method public javax.ws.rs.core.StreamingOutput com.****************.********(javax.servlet.http.HttpServletRequest,java.lang.String,java.lang.String) at parameter at index 0
Dec 13, 2012 2:10:42 PM com.sun.jersey.test.framework.spi.container.inmemory.InMemoryTestContainerFactory$InMemoryTestContainer stop
INFO: Stopping low level InMemory test container

Answer 1

Looks like Jersey is not able to inject a HttpServletRequest

Is one of your endpoints configured like this?

public StreamingOutput something(@Context HttpServletRequest request, String a, String b) {}

If so, you may want to rethink your design, and opt instead for

@Context
private HttpContext context;

public StreamingOutput something(String a, String b) {

  System.out.println("Request info "+context.getRequest().getAbsolutePath());

}

which may yield a cleaner approach. So long as you rely on the Class resource registration then you're guaranteed a new instance per request which should avoid threading issues.

Answer 2

My problem was that, I injected a HttpServletRequest which is supported by InMemory container, I'd need to use jetty grizzlyWebTestContainer or jetty as the test contatiner in this case. I didn't quite get that working neither, because introducing in jersey-test-framework-grizzly did bring a lot of dependency conflicts against dropwizard itself. I recon it's not worthwhile trying to resolve all the conflicts, because when I upgrade dropwizard in the future, this might happen again.

At the end of day, I ended up having a jenkins job with some integration tests(in python) to test my web services. eg. after the deployment, fire in some http requests, check the response code and response content. It turns out way much easier.