Подтвердить что ты не робот

Получение 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. Так есть ли другая причина этой ошибки? Пожалуйста, помогите

4b9b3361

Ответ 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 основных причины:

  1. Версия вашего сервлета старше 3.1.

  2. В некоторых других jar есть сервлет с версией старше 3.1.

  3. Ваша версия кота старше 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')