Tomcat 7 - Servlet 3.0: неверный тег байта в постоянном пуле

Ответ 1

Возможно, это не ваша проблема, но мой был такой же, как этот - старая версия com.ibm.icu:icu4j, Я решил проблему, изменив конфигурацию сборки, чтобы исключить более старые транзитивные зависимости и явно в зависимости от последней версии (4.8).

Ответ 2

Добавление

metadata-complete="true" 

к вашему web.xml следует сортировать проблему

<web-app version="3.0"
         xmlns="http://java.sun.com/xml/ns/javaee"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
         metadata-complete="true">

Это говорит tomcat не сканировать классы для аннотаций: http://www.tomcatexpert.com/blog/2011/10/12/how-use-fragments-and-annotations-configure-your-web-application

Ответ 3

Спасибо Джеймс Уилсон за ваш ответ - обновление icu4j, как вы предложили, работало для меня и позволило мне сохранить версию = "3.0" в моем web.xml(который Я предпочитаю в долгосрочной перспективе).

icu4j 2.6.1 была версия, которая не работала, обновление до версии NEXT 3.4.4 решит эту проблему. Я НЕ пошел в последнюю версию icu4j (49.1), потому что он на 4 Мбайт больше, чем версия 3.4.4.

Вот фрагмент конфигурации Maven для блокировки вашей транзитивной версии зависимостей (без добавления явной зависимости):

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>com.ibm.icu</groupId>
            <artifactId>icu4j</artifactId>
            <version>3.4.4</version>
        </dependency>
    </dependencies>
</dependencyManagement>

Ответ 4

Я столкнулся с тем же вопросом сегодня. В моем случае зависимость проходила через com.google.code.findbugs: аннотации: jar: 1.3.8. Это означает, что эта библиотека используется только во время сборки, чтобы использовать аннотации, чтобы отключить некоторые предупреждения об ошибках. В этом случае вместо изменения версии можно просто изменить область зависимостей и не брать библиотеку во время выполнения:

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>com.ibm.icu</groupId>
            <artifactId>icu4j</artifactId>
            <scope>provided</scope>
        </dependency>
        ....

Ответ 5

Я думаю, что это ошибка, анализирующая файл web.xml сам.

Использование этого работает для меня...

<web-app version="2.5" xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd">

<session-config> <tracking-mode>COOKIE</tracking-mode> </session-config>

Обратите внимание на использование версии = "2.5" с помощью схемы web-app_3_0.xsd и наличие режима отслеживания session-config, который является лишь частью спецификации 3.0, а не 2.5 (AFAIK)

Ответ 6

Это оказалось несовместимым jasper jar, включенным в сборку, противоречащим jasper.jar в tomcat 7.

Ответ 7

Я столкнулся с той же проблемой с недели и решил просто заменить файл icu4j.2.1.jar последней версией jar.

Ответ 8

добавив http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd "metadata-complete =" true" >

решил мою проблему

Ответ 9

В версии 2.6.1. com.ibm.icu.impl.data.LocaleElements_zh__PINYIN.class недействителен. Единственное решение - обновить, другие решения - обходные пути.

Его можно проверить, выполнив следующий тест в вашем проекте (если icu-x.x.x.jar находится в вашем пути к классам):

@Test public void testValidityOfLocaleElements_zh__PINYINJar() throws ClassNotFoundException { getClass().forName("com.ibm.icu.impl.data.LocaleElements_zh__PINYIN"); }

Ответ 10

Мы начали получать ту же ошибку с незначительными изменениями в нашем приложении без какого-либо обновления до зависимостей Java, Tomcat или проекта. Мы имеем icu4j 2.6.1

Проведя довольно значительное время и пытаясь обновить icu4j до различных новых версий (мы заметили и обнаружили, что модификации icu от 4.8.x до 49.xx, 50.xx и т.д., кто-то должен был обмануть его при построении 4.9.0), мы обнаружили проблему.

Наши незначительные изменения представили новый класс (класс A), который отображается в спящий режим. Hibernate инициализируется, когда мы запускаем WAR, и проверяет постоянные объекты на их сопоставления. Там был еще один класс, который представляет собой перечисление (класс B) с тем же именем и одним и тем же пакетом в нашей кодовой базе. Как только мы исправили этот повторяющийся класс, проблема исчезла.

Ответ 11

Решено путем удаления папки и повторной загрузки фляг