Error de Javassist en hibernación: tipo de constante no válida: 60

Question

Estoy creando una herramienta cli para administrar una aplicación existente. La solicitud y las pruebas se acumulan bien y funcionan bien, pero a pesar de eso reciben un fracaso javassist al ejecutar mi herramienta CLI que existe dentro de la jarra:

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 

Como sé que el frasco está bien como el test de integración unidad y correr contra eso, pensé que podría ser un problema con javassist, así que probé cglib. El proveedor de código de bytes luego se muestra como cglib, pero todavía obtengo el mismo rastro de pila con presencia de javassist.

cglib está definitivamente en la ruta de clase:

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

He intentado tanto con hibernación 3.4 y 3.5 y obtener el mismo error exacto. ¿Es esto un problema con javassist?

ACTUALIZACIÓN: Puedo ejecutar la aplicación con éxito dentro de Eclipse (clic derecho-> Ejecutar como-> Aplicación Java), pero falla el uso de jar-with-dependencies generado por maven. Supongo que la diferencia es que con Eclipse, javassist no está inspeccionando el contenedor contenedor, sino que está inspeccionando todos los archivos de clase (y tal vez algunos archivos dependientes de terceros).

Answer 1

El problema es en última instancia causado por una clase no válida en icu4j-2.6.1 como se puede ver en this post. En concreto, este archivo no es válido:

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

Aquí está una manera simple de identificar un archivo dañado:

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 

Este archivo está siendo incluido por indirectamente por experto a través de sus dependencias transitivas por lo que yo no' Reconozco que la página hace referencia al error y que un archivo incluido en el contenedor es el culpable y la causa del problema. Así es como terminó incluido en mi tarro-con-dependencias paquete:

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

Después de añadir la siguiente exclusión a la dependencia jaxen, todo funcionó correctamente para mí (pero tenga cuidado si necesita sus piezas de localización):

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

Otra opción sería eliminar el archivo (s) ofensivo del archivo jar:

#!/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