Dropwizard/Jersey: manca la dipendenza per il metodo pubblico durante l'esecuzione dei test

Question

Ho riscontrato un'eccezione "Dipendenza mancante" durante l'esecuzione di resourceTest utilizzando Dropwizard: 0.6.1 (jersey 1.15), qualcuno ha esperienza in questo caso?

mio file di prova:

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

Eccezione:

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

Il mio problema era che, ho iniettato un HttpServletRequest che è supportato dal contenitore InMemory, avrei bisogno di usare jetty grizzlyWebTestContainer o molo come contatatore di test in questo caso. Non ho nemmeno capito che non funzionasse nemmeno, perché introdurre in jersey-test-framework-grizzly ha portato molti conflitti di dipendenza contro il dropwizard stesso. Ricordo che non vale la pena provare a risolvere tutti i conflitti, perché quando aggiornerò il dropwizard in futuro, questo potrebbe accadere di nuovo.

Alla fine del giorno, ho finito per avere un lavoro jenkins con alcuni test di integrazione (in python) per testare i miei servizi web. per esempio. dopo la distribuzione, attivare alcune richieste http, controllare il codice di risposta e il contenuto della risposta. Risulta molto più facile.

Answer 2

Sembra Jersey non è in grado di iniettare un HttpServletRequest

è uno dei vostri endpoint configurato come questo?

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

Se è così, si potrebbe voler ripensare il vostro disegno, e optare invece per

@Context 
private HttpContext context; 

public StreamingOutput something(String a, String b) { 

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

} 

che può produrre un approccio più pulito. Finché ci si basa sulla registrazione delle risorse Class, si garantisce una nuova istanza per richiesta che dovrebbe evitare problemi di threading.

Answer 3

Il modo in cui ho risolto questo problema era di definire una risorsa di classe base astratta senza il contesto iniettato, quindi implementare una piccola classe derivata per il tuo vero servizio.

@Path("/contextMethod") 
@Produces(MediaType.APPLICATION_JSON) 
@Consumes(MediaType.APPLICATION_JSON) 
public class MyResourceWithContext extends BaseResource { 
    @Context 
    private HttpServletRequest request; 

    protected String getUserID() 
    { 
     return request.getRemoteUser(); 
    } 
} 

Quando si esegue il test, è quindi implementare una classe derivata alternativo solo per i test, che non usa il HttpServletRequest. Il vantaggio del bonus qui è che la classe testabile derivata può inserire un valore codificato nel contesto per creare alcuni scenari di test adatti.