Ошибка Javassist в спящем режиме: неверный тип константы: 60 - PullRequest
Новая
       53

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

6 голосов
/ 12 июня 2010

Я создаю инструмент cli для управления существующим приложением.И приложение, и тесты работают нормально и работают нормально, но, несмотря на это, я получаю ошибку javassist при запуске моего инструмента cli, который существует внутри jar: 

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.Затем поставщик байт-кода отображается как cglib, но я все еще получаю ту же самую трассировку стека с присутствующим в ней javassist.

cglib определенно находится в пути к классам: 

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

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

ОБНОВЛЕНИЕ : я могу успешно запустить приложение в Eclipse (Правый клик-> Выполнить как-> Java-приложение), но используя сгенерированный maven jar-с-зависимости не удается.Я предполагаю, что разница в том, что с Eclipse javassist не проверяет содержащийся jar, скорее, он проверяет все файлы классов (и, возможно, несколько зависимых сторонних jar-файлов).

1 Ответ

19 голосов
/ 29 июня 2010

Проблема в конечном итоге вызвана недопустимым классом в 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 через его транзитивные зависимости, поэтому я не распознал эту страницу как ссылку на ошибку, а файл, содержащийся в банке, был виновником и причиной проблемы. Вот как он оказался в моем пакете jar-with-dependencies: 

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