Ошибка Javassist в Hibernate: неверный тип постоянного типа: 60

Question

Я создаю инструмент CLI для управления существующим приложением. Как приложение, так и тесты построят штрафные и запускаются нормально, но, несмотря на то, что я получаю сбой Javassist при запуске моего инструмента CLI, который существует в банке:

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

Поскольку я знаю, что JAR в порядке, так как у него и тесты единицы и интеграции, я думал, что это может быть проблемой с Javassist, поэтому я попробовал CGLIB. Поставщик Bytecode затем показывает как CGLIB, но я все еще получаю то же прослеживание стопки с присутствующим в нем Javassist.

CGLIB определенно в классе:

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

Я пробовал с помощью Hibernate 3.4 и 3.5 и получить точную то же ошибку. Это проблема с Javassist?

ОБНОВИТЬ: Я могу успешно запустить приложение в Eclipse (правой кнопкой мыши-> RUN AS-> AS-> Java Application), но используя сгенерированные Maven JAR-зависимости. Предлагаю, что разница состоит в том, что с Eclipse Javassist не проверяет содержащий банку, а не проверяет все файлы классов (и, возможно, несколько зависимых 3-х сторонних банок).

Answer 1

Проблема в конечном итоге вызвана недействительным классом в icu4j-2.6.1 Как видно в эта почта. Отказ В частности, этот файл недействителен:

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

Вот простой способ определить поврежденный файл:

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

Этот файл включен косвенно Maven через свои переходные зависимости, поэтому я не признал эту страницу в качестве ссылки на ошибку и файл, содержащийся в банке, как виновник и причиной проблемы. Вот как оно закончилось в моем барно-зависимостях.

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

После добавления следующего исключения к jaxen Зависимость, все работало правильно для меня (но будьте осторожны, если вам нужна его кусочки локализации):

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

Другой вариант будет удалить файл (ы) оскорблений в файле 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