Javassist error in sleep mode: invalid persistent type: 60

Question

I am creating a cli tool to manage an existing application. Both the application and the tests build perfectly and work fine, but despite this, I get a javassist failure when I run my cli tool, which exists in the bank:

INFO: Bytecode provider name : javassist ... INFO: Hibernate EntityManager 3.5.1-Final Exception in thread "main" javax.persistence.PersistenceException: Unable to configure EntityManagerFactory at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:371) at org.hibernate.ejb.HibernatePersistence.createEntityManagerFactory(HibernatePersistence.java:55) at javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:48) at javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:32) ... at com.sophware.flexipol.admin.AdminTool.<init>(AdminTool.java:40) at com.sophware.flexipol.admin.AdminTool.main(AdminTool.java:69) Caused by: java.lang.RuntimeException: Error while reading file:flexipol-jar-with-dependencies.jar at org.hibernate.ejb.packaging.NativeScanner.getClassesInJar(NativeScanner.java:131) at org.hibernate.ejb.Ejb3Configuration.addScannedEntries(Ejb3Configuration.java:467) at org.hibernate.ejb.Ejb3Configuration.addMetadataFromScan(Ejb3Configuration.java:457) at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:347) ... 11 more Caused by: java.io.IOException: invalid constant type: 60 at javassist.bytecode.ConstPool.readOne(ConstPool.java:1027) at javassist.bytecode.ConstPool.read(ConstPool.java:970) at javassist.bytecode.ConstPool.<init>(ConstPool.java:127) at javassist.bytecode.ClassFile.read(ClassFile.java:693) at javassist.bytecode.ClassFile.<init>(ClassFile.java:85) at org.hibernate.ejb.packaging.AbstractJarVisitor.checkAnnotationMatching(AbstractJarVisitor.java:243) at org.hibernate.ejb.packaging.AbstractJarVisitor.executeJavaElementFilter(AbstractJarVisitor.java:209) at org.hibernate.ejb.packaging.AbstractJarVisitor.addElement(AbstractJarVisitor.java:170) at org.hibernate.ejb.packaging.FileZippedJarVisitor.doProcessElements(FileZippedJarVisitor.java:119) at org.hibernate.ejb.packaging.AbstractJarVisitor.getMatchingEntries(AbstractJarVisitor.java:146) at org.hibernate.ejb.packaging.NativeScanner.getClassesInJar(NativeScanner.java:128) ... 14 more 

Since I know that the jar is beautiful, because unit tests and integration run against it, I thought it might be a problem with javassist, so I tried cglib. Then the byte code provider appears as cglib, but I still get the same stack tracking with the javassist present in it.

cglib is definitely in the classpath:

 $ unzip -l flexipol-jar-with-dependencies.jar | grep cglib | wc -l 383 

I tried with both sleeping 3.4 and 3.5 and got the same error. Is this a problem with javassist?

UPDATE . I can successfully run the application in Eclipse (right click-> Run as> Java application), but maven-generated jar-with-dependations fail. I assume that the difference is that using javassist Eclipse does not check the contents of the container, but checks all class files (and possibly several dependent third-party jars).

Answer 1

The problem is ultimately caused by an invalid class in icu4j-2.6.1 , as seen in this post . In particular, this file is not valid:

 com/ibm/icu/impl/data/LocaleElements_zh__PINYIN.class 

Here is an easy way to identify a damaged file:

 for x in PATH_TO_EXTRACTED_JAR/**/*.class; do java -cp PATH_TO/javassist.jar javassist.tools.Dump $x >/dev/null 2>&1 || echo "$x is invalid" done 

This file is included indirectly through maven through its transitive dependencies, so I did not recognize this page as a link to an error and the file contained in the bank as the culprit and cause of the problem. Here's how it turned out to be included in the jar-with-dependencies package:

 jaxen-1.1.1 -> xom-1.0 -> icu4j-2.6.1 

After adding the following exception to the jaxen dependency jaxen everything works correctly for me (but be careful if you need its localization fragments):

 <exclusions> <exclusion> <groupId>com.ibm.icu</groupId> <artifactId>icu4j</artifactId> </exclusion> </exclusions> 

Another option is to delete the crash files (s) from the jar file:

 #!/bin/sh shopt -s extglob shopt -s globstar for x in **/*.jar ; do zip -d $x 'com/ibm/icu/impl/data/*_zh*' >/dev/null 2>&1 && echo "Removed corrupted files from $x" done