getDispatcherType () non è definito per il tipo HttpServletRequest

Ho importato un progetto web dinamico Java nell’IDE di Eclipse (che è stato implementato in Eclipse IDE e funziona correttamente).

Ricevo un getDispatcherType()getDispatcherType() non definito per il tipo HttpServletRequest ” durante l’esecuzione del progetto.

Ho copiato tutti i file in IDE secondo la struttura e il lavoro è fatto.

Ora voglio solo sapere perché sto ricevendo questo errore quando ho importato il progetto. Qualcuno ha affrontato lo stesso problema? Per favore fatemi sapere quale errore avrei potuto fare.

Ho avuto lo stesso problema quando avevo una versione di servlet-API in conflitto che stavo usando in IntelliJ che era in conflitto con ciò che era supportato in Tomcat 8.0.x … Stavo usando Maven, quindi ho appena cambiato la mia dipendenza con questo, poi ho fatto un deploy pulito della mia webapp e il problema è andato via.

  javax.servlet javax.servlet-api 3.1.0  

tomcat 8.0.18, esperto. Riguarda il conflitto lib. La mia soluzione è:

  javax.servlet servlet-api 2.5  

cambiato in:

  javax.servlet javax.servlet-api 3.1.0  

Dovresti escludere “servlet-api-2.5.jar” da qualsiasi altra dipendenza che potresti avere nel tuo pom.xml.

Cerca di non aggiungere un servlet-API diverso come compilato, dato che Tomcat lo fornisce già per te.


I miei passi:

Ho controllato che c’era un servlet-api-2.5.jar incluso nella mia cartella WEB-INF / lib di Maven, quindi ho controllato il grafico completo delle dipendenze su “Progetti Maven @IntelliJ Idea”, quindi ho escluso questa dipendenza da TUTTI i luoghi da cui proviene. [Il pulsante “Mostra dipendenze” è utile per questo]

Ho dovuto escludere “commons-logging” (dato che ha dipendenza servlet-api 2.5) da velocity-tools. Doveva anche escludere servlet-API da jaxws-spring che ha una dipendenza diretta dall’ambito predefinito.

Quindi, è sufficiente aggiungere l’ambito fornito come si dovrebbe sulla dipendenza javax.servlet-api.

Se aggiungi il tuo servlet-apio 3.0.1+ come “compilato”, potresti finire con entrambi e il primo a caricare vincerà, il che non è affatto positivo.

Nota: la mia ipotesi è che questo problema derivi dalla ridenominazione di groupId / artifactId di servlet-api e che non venga sovrascritto con la versione più vecchia inclusa nel progetto maven. : \

Ho risolto questo problema utilizzando il servlet-api.jar e jsp-api.jar da tomcat stesso, quindi la dipendenza verrà specificata con l’ambito del sistema come di seguito:

 /opt/apache-tomcat-8.0.15/lib/servlet-api.jar /opt/apache-tomcat-8.0.15/lib/jsp-api.jar  javax.servlet servlet-api 3.0 system ${servlet.api.jar.path}   javax.servlet jsp-api 2.2 system ${jsp.api.jar.path}  

Se il tuo tomcat è la versione 8 usa:

  javax.servlet javax.servlet-api 3.1.0  

lavorato!

Questo può accadere anche durante l’aggiornamento da una versione precedente a una nuova di Tomcat e mantenendo i vecchi file jar come j2ee.jar e javaee.jar.

j2ee.jar dovrebbe essere comprensibile nella tua webapp, l’interfae è implementato da tomcat