fracaso Javassist en hibernación: inválido tipo constante: 60

Question

Estoy creando una herramienta CLI para administrar una aplicación existente. Tanto la solicitud como la multa y correr bien las pruebas de acumulación pero a pesar de que recibo 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 la unidad e integración de las pruebas realizadas en contra de ella, pensé que podría ser un problema con javassist, así que traté cglib. El proveedor de código de bytes a continuación muestra como cglib pero aún así obtener exactamente la misma traza de la pila con el presente javassist en ella.

cglib está definitivamente en la ruta de clase:

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

He intentado tanto con Hibernate 3.4 y 3.5 y obtener el mismo error exacto. Es este un problema con javassist?

Actualizar : Puedo ejecutar la aplicación con éxito dentro de Eclipse (click-derecho> Ejecutar As-> Aplicación Java), pero utilizando el experto generada-jar-con-dependencias falla. Supongo que la diferencia es que con Eclipse javassist no está inspeccionando el frasco que contiene, más bien, que es la inspección de todos los archivos de clase (y tal vez un par de tarros dependientes tercera parte).

Answer 1

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

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

Esta es una forma sencilla 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 maven indirectamente a través de sus dependencias transitivas razón por la cual no reconocía esa página como referencia el error y un archivo contenido en el frasco como 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 usted tiene 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 infractor (s) desde el 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