Получение NoSuchMethodError: javax.servlet.ServletContext.getVirtualServerName()
У меня возникла проблема во время развертывания службы в Tomcat 8. Получение следующей ошибки:
Вызвано: java.lang.NoSuchMethodError: javax.servlet.ServletContext.getVirtualServerName() Ljava/языки/String; at org.apache.tomcat.websocket.server.WsServerContainer. (WsServerContainer.java:149) на org.apache.tomcat.websocket.server.WsSci.init(WsSci.java:131) at org.apache.tomcat.websocket.server.WsSci.onStartup(WsSci.java:47) at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5244) на org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) ... еще 10
Метод getVirtualServerName
был введен в Servlet 3.1, и после извлечения MANIFEST.MF
из моей servlet-api
jar я получил следующие данные:
Specification-Title: Java API for Servlets
Specification-Version: 3.1
Specification-Vendor: Sun Microsystems, Inc.
Implementation-Title: javax.servlet
Это говорит о том, что у него есть 3.1. Так есть ли другая причина этой ошибки? Пожалуйста, помогите
Ответы
Ответ 1
Проверьте все ваши зависимости Maven (или эквивалентные) и убедитесь, что вы - или, скорее всего, другая зависимость - не втягиваете в версию 3.1 javax.servlet / servlet-api
, которая может иметь приоритет над тем, что в вашем Tomcat 8. Если вы вручную развернули, убедитесь, что вы не вручную скопировали JAR файлы сервлета-api в сам Tomcat.
Смотрите: fooobar.com/questions/176448/...
Ответ 2
Метод getVirtualServerName
был добавлен в ServletContext в Servlet 3.1. См. метод java doc getVirtualServerName.
Эта проблема имеет 3 основных причины:
Версия вашего сервлета старше 3.1.
В некоторых других jar есть сервлет с версией старше 3.1.
Ваша версия кота старше 8 лет
Чтобы решить эту проблему, попробуйте следующий способ.
I. Проверьте ваш pom.xml на наличие кода ниже.
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>javax.servlet-api</artifactId>
<version>3.1.0</version>
</dependency>
если ваш pom.xml имеет вышеуказанный код, он все равно будет иметь эту проблему. Вы можете сделать второй путь.
II. чтобы проверить другую банку, обратитесь к банке javax.servlet-api
. например, org.apache.santuario
ссылается на банку javax.servlet-api
. pom.xml:
<dependency>
<groupId>org.apache.santuario</groupId>
<artifactId>xmlsec</artifactId>
<version>1.4.3</version>
</dependency>
но когда вы смотрите на зависимости maven, это относится к банке javax.servlet-api
, версия которой 2.3 старше 3.1.
![enter image description here]()
поэтому вы должны исключить версию 2.3. pom.xml:
<!-- exclude servlet-api 2.3 jar-->
<dependency>
<groupId>org.apache.santuario</groupId>
<artifactId>xmlsec</artifactId>
<version>1.4.3</version>
<exclusions>
<exclusion>
<groupId>javax.servlet</groupId>
<artifactId>servlet-api</artifactId>
</exclusion>
</exclusions>
</dependency>
<!-- servlet-api 3.1 version has getVirtualServerName() -->
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>javax.servlet-api</artifactId>
<version>3.1.0</version>
</dependency>
III. При весенней загрузке запустите tomcat 7. по умолчанию, поэтому укажите tomcat версии 8 вместо tomcat 7. Добавьте код pom.xml:
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
<java.version>1.8</java.version>
<tomcat.version>8.5.5</tomcat.version>
</properties>
Ответ 3
У меня была эта ошибка на IntelliJ с maven после обновления IntelliJ.
Я мог запускать тесты с помощью maven, но не из моей IDE.
Я решил проблему, удалив файлы ./idea
и project.iml
и перезагрузив проект.
Ответ 4
Spring boot будет запускаться tomcat 7 по умолчанию, вам нужно переопределить maven build tomcat.version в вашем pom.xml. См. Ниже, чтобы запустить tomcat 8.0.30
<properties>
<tomcat.version>8.0.30</tomcat.version>
</properties>
Должно исправить вашу проблему.
Ответ 5
решаемые
На моем mac с java 8 столкнулась проблема с загруженным tomcat с сайта и разархивированием.
Моя проблема была решена, потому что был добавлен дополнительный файл servlet-api.jar, который подбирался. Это происходило из
/Library/Java/Extensions/servlet -api.jar
Чтобы найти его в своей системе, вы можете использовать
sudo find/-name servlet-api.jar
Удалено, создав резервную копию в другом месте.
Я следил за этим за инталлацию
https://gist.github.com/ddanailov-nmdp/c97aba2ca926b9627f6b4f7174083a32
Ответ 6
После огромной боли Отсеивая все эти ответы на вопросы stackoverflow, единственное, что в итоге сработало для меня, это понижение с tomcat8 до tomcat7. Я знаю, что это не идеальное решение, и, возможно, это была просто новая версия tomcat, которая решила мою проблему. Если ничего не помогает, сделайте это.
Ответ 7
Если вы использовали эту зависимость:
<dependency>
<groupId>com.google.oauth-client</groupId>
<artifactId>google-oauth-client-jetty</artifactId>
<version>1.23.0</version>
</dependency>
Затем исключите, как показано ниже:
<dependency>
<groupId>com.google.oauth-client</groupId>
<artifactId>google-oauth-client-jetty</artifactId>
<version>1.23.0</version>
<exclusions>
<exclusion>
<artifactId>servlet-api</artifactId>
<groupId>org.mortbay.jetty</groupId>
</exclusion>
</exclusions>
</dependency>
Ответ 8
Это, безусловно, имеет какое-то отношение к версии javax.servlet и версии Tomcat.
В моем случае он исчез, когда я объявил зависимость javax.servlet в gradle без версии. Как это -
compile('javax.servlet:servlet-api')