java.lang.NoSuchMethodError: javax.servlet.http.HttpServletRequest.isAsyncStarted() durante l'utilizzo di Mockito con Junit

Question

Sto cercando di bagnarmi i piedi con TDD. Sto provando a scrivere casi di test unitari per controller usando Mockito in congiunzione con MockMvc e Junit.

Ma sto ottenendo un errore di runtime con conseguente fallimento del mio test. All'inizio ho riscontrato problemi nell'inizializzazione dell'istanza MockMvc nell'installazione a causa di un errore nel trovare javax.servlet.SessionCookieConfig.

Questo l'ho risolto scaricando il javax.servlet api e la configurazione è nel percorso di generazione del progetto, ma poi io sono di fronte al

java.lang.NoSuchMethodError: javax.servlet.http.HttpServletRequest.isAsyncStarted() 

durante l'utilizzo perform() sull'istanza MockMvc.

Qualcuno può dirmi cosa fare con questo tipo di dipendenze come penso che stia succedendo a causa del server incompatibile servlet-API e javax.servlet api.

EDIT: Vi metto il codice che sto usando utilizzando per il test unità, ma non credo che sarebbe stato alcun aiuto, ma solo nel caso in cui:

@RunWith(MockitoJUnitRunner.class) 
public class MyControllerTest { 

    @InjectMocks 
    private MyController myController = new MyController(); 

    @Mock 
    private MyService myService = new MyServiceImpl(); 

    private MockMvc mockMvc; 

    @Before 
    public void setUp(){ 
     this.mockMvc = MockMvcBuilders.standaloneSetup(myController).build(); 
    } 

    @Test 
    public void testList() throws Exception{ 
     A a = new A(); 
     a = createMockClassA(); 

     Mockito.when(myService.getServiceForA(Mockito.anyMapOf(String.class, String.class))).thenReturn(a); 

     MvcResult result = this.mockMvc.perform(get("/somePath/")).param("someExpectedParam","value").andReturn(); 

     System.out.println(result.getResponse().getContentAsString()); 

    } 



    private static A createMockClassA(){ 
     A a = new A(); 
     a.setId(i); 
     a.setTitle("mock-" + i); 
     return a; 
    } 
} 

Answer 1

Questo suona molto come hai sbagliato versione dell'API del servlet nel percorso della classe.

Controllare quando isAsyncStarted è stato aggiunto all'API e assicurarsi che quello che si fa riferimento nel classpath sia almeno di quella versione o superiore.

Al fine di trovare la posizione in cui la versione della classe 'sbagliato' sta venendo da voi possibile utilizzare l'argomento

-verbose:class 

per Java. Elencherà tutte le classi caricate e se ricordo correttamente da dove vengono caricate. Vedi http://docs.oracle.com/javase/7/docs/technotes/tools/windows/java.html per i dettagli.

Answer 2

Ciò si verifica quando gli ambienti di sviluppo e produzione utilizzano versioni API servlet diverse.

Durante la creazione con tomcat7 (ad esempio) supporta il servlet 3 e quindi non si riceverà alcun errore.

Mentre si esegue lo stesso su una versione inferiore di tomcat, verrà generato un errore.

Soluzione:

effettuare l'aggiornamento uno degli ambienti a supporto servlet 3 o semplicemente downgrade il codice per utilizzare servlet 2,5

Answer 3

ho trovato la soluzione per il mio errore. La vera API servlet che veniva fornita era gwt-servlet.jar e la servlet-ap nel gwt-servlet.jar era della versione precedente. Così ho configurato il mio percorso di costruzione per fare in modo che il progetto punti all'ultimo servlet-API durante la costruzione.

Per quanto riguarda la risposta corretta, penso che il mio voto vada a Jens poiché ha dato la soluzione più vicina secondo lo scenario.

Grazie a tutti. :)

Answer 4

Il messaggio di errore indica che la versione dell'API servlet è errata nel classpath.

Se si utilizza il Gradle eseguire

gradle dependencies 

analizzare l'albero delle dipendenze ed escludere le dipendenze 'servlet-API' con la versione inferiore a 3,0. È possibile effettuare le seguenti operazioni di escludere

compile ('javax.servlet:jsp-api:2.0'){ 
    exclude module : 'servlet-api' 
} 

Non ci può essere più dipendenze che includono ulteriori servlet-api-2.x. Escludere tutti coloro

Answer 5

risolvo questo problema aggiungendo al java accumulo percorso Tomcat come una libreria di runtime server di

Answer 6

Ho avuto un simile problema alcuni dei miei test JUnit non funzionavano (in IntelliJ IDEA) e stavo anche ricevendo java.lang.NoSuchMethodError: javax.servlet.http.HttpServletRequest.... per quei test unitari. Quando provo a compilare il progetto completo utilizzando gradle dalla directory attraverso il prompt dei comandi utilizzando il comando gradle clean build, il codice è stato compilato correttamente. Mentre il problema era con i test di Junit nell'intelligenza di Intellij, stavano mostrando l'errore sopra citato. Ho semplicemente cambiato la versione gradle dalla 3.4.1 alla 2.1.3. Non so perché ora i miei test di Junit si stanno compilando così come il mio codice viene compilato tramite intellij e tramite prompt dei comandi. Lo stesso problema si è verificato con un altro mio collega e anche lui ha cambiato la versione gradle dal 4 in qualche versione 2. Il problema è stato risolto.