Tomcat 7 - Servlet 3.0: недопустимый байт-тег в постоянном пуле - PullRequest
30 голосов
/ 19 июля 2011
  • кот 7.0.16
  • Java 1.6.0_22
  • CentOS 5,6

Я только что переключил web.xml на сервлет 3.0 (из приложения, работавшего ранее на 2.4), и теперь я вижу следующую ошибку (включил точную регистрацию для org.apache.tomcat.util):

mtyson  FINE: Scanning JAR [file:/usr/java/jdk1.6.0_22/jre/lib/ext/jcharset.jar] from classpath
mtyson  Jul 19, 2011 10:04:40 AM org.apache.catalina.startup.HostConfig deployDirectory
mtyson  SEVERE: Error deploying web application directory ROOT
mtyson  org.apache.tomcat.util.bcel.classfile.ClassFormatException: Invalid byte tag in constant pool: 60

ОБНОВЛЕНИЕ: Just Tried tomcat 7.0.19 - те же результаты

Ответы [ 10 ]

30 голосов
/ 04 октября 2012

Добавление

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

23 голосов
/ 20 июля 2011

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

19 голосов
/ 26 апреля 2012

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

icu4j 2.6.1 была версия, которая не работала, обновление до следующей версии 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>
3 голосов
/ 12 июня 2013

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

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>com.ibm.icu</groupId>
            <artifactId>icu4j</artifactId>
            <scope>provided</scope>
        </dependency>
        ....
3 голосов
/ 22 января 2012

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

2 голосов
/ 04 августа 2011

Я думаю, что это ошибка при разборе файла 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>

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

1 голос
/ 14 января 2014

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

0 голосов
/ 22 апреля 2018

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

0 голосов
/ 17 сентября 2015

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

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

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

0 голосов
/ 09 февраля 2015

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

Это можно проверить, выполнив следующий тест в вашем проекте (при условии, что icu-xxxjar находится в вашем пути к классам):

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

...