Tomcat 7 - Servlet 3.0: Invalid byte tag in constant pool

• tomcat 7.0.16
• Java 1.6.0_22
• CentOS 5.6

I just switched the web.xml to servlet 3.0 (from a app running 2.4 previously) and now I'm seeing the following error (turned on fine logging for 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

UPDATE: Just Tried tomcat 7.0.19 - same results

Adding

metadata-complete="true" 

to your web.xml should sort the issue

<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">

This tells tomcat not to scan classes for annotations: https://web.archive.org/web/20180510163848/http://www.tomcatexpert.com/blog/2011/10/12/how-use-fragments-and-annotations-configure-your-web-application

It may not be your issue, but mine was the same as this one -- an old version of com.ibm.icu:icu4j. I solved the problem by changing my build configuration to exclude the older transitive dependencies and explicitly depending upon the latest version (4.8).

Thanks James A Wilson for your answer - updating icu4j as you suggested worked for me and allows me to keep version="3.0" in my web.xml (which I prefer for the long run).

icu4j 2.6.1 was the version which did not work, upgrading to the NEXT version 3.4.4 will solve this problem. I did NOT go to the latest version of icu4j (49.1) because it is 4MB larger than version 3.4.4.

Here is a Maven configuration snippet to lock in your transitive dependency version (without adding an explicit dependency):

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

This turned out to be an incompatible jasper jar being included in the build, conflicting with the jasper.jar in tomcat 7.

I bumped into the same issue today. In my case, the dependency was coming via com.google.code.findbugs:annotations:jar:1.3.8. That means this library is only used at build time, to use annotations to turn off some findbug warnings. In this case, instead of changing the version, it is safe to just change the dependency scope and not take the library at runtime:

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

I think this is a bug parsing the web.xml file myself

Using this works for me...

<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>

Notice the use of the version="2.5" with the web-app_3_0.xsd schema and the presence of the session-config tracking-mode which is only part of the 3.0 spec not the 2.5 (AFAIK)

We had started getting the very same error with a minor change to our application without any upgrade to Java, Tomcat or project dependencies. We have icu4j 2.6.1

After spending quite considerable time and trying to upgrade icu4j to various newer versions (we noticed and found amouzing that icu versions went from 4.8.x to 49.x.x, 50.x.x etc, someone must have fat-fingered it while building 4.9.0), we found the problem.

Our minor change submitted a new class (Class A) that is mapped to hibernate. Hibernate initializes when we start the WAR, and checks persistent objects against their mappings. There happened to be another class which is an enum (Class B) with the same name and same package in our codebase. Once we fixed that duplicate class, the problem went away.

I was facing the same issue from a week and resolved by simply replacing the icu4j.2.1.jar file with latest version of jar.

In version 2.6.1. the com.ibm.icu.impl.data.LocaleElements_zh__PINYIN.class is invalid. The only solution is to update, other solutions are just workarounds.

It can be checked by running the following test in your project ( provided icu-x.x.x.jar is on your classpath ):

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

Solved by deleting the folder and re-downloading the jars

It may not be your issue, but mine was the same as this one -- an old version of gson-2.8.5. I solved the problem by changing by build configuration to exclude the older transitive dependencies and explicitly depending upon the older version (2.8.5).