2011-12-26 12 views
12

Hola, estoy ejecutando una prueba maven usando maven 3.0.3 con hibernate 4.0.0 versión final y primavera 3.1 en la actualización jdk7 2.¿Cómo puedo obtener la prueba de unidad para ejecutar en java 7: java.lang.VerifyError: Esperando un marco de mapa de distribución en el destino de rama

Recibo el siguiente error.

Caused by: java.lang.VerifyError: Expecting a stackmap frame at branch target 63 in method ${myDomainClass}.equals(Ljava/lang/Object;)Z at offset 24 
    at java.lang.Class.getDeclaredMethods0(Native Method) 
    at java.lang.Class.privateGetDeclaredMethods(Class.java:2442) 
    at java.lang.Class.getDeclaredMethods(Class.java:1808) 
    at org.hibernate.property.BasicPropertyAccessor.getterMethod(BasicPropertyAccessor.java:352) 
    at org.hibernate.property.BasicPropertyAccessor.getGetterOrNull(BasicPropertyAccessor.java:331) 
    at org.hibernate.property.BasicPropertyAccessor.createGetter(BasicPropertyAccessor.java:314) 
    at org.hibernate.property.BasicPropertyAccessor.getGetter(BasicPropertyAccessor.java:310) 
    at org.hibernate.internal.util.ReflectHelper.getter(ReflectHelper.java:250) 
    at org.hibernate.internal.util.ReflectHelper.reflectedPropertyClass(ReflectHelper.java:229) 
    at org.hibernate.mapping.SimpleValue.setTypeUsingReflection(SimpleValue.java:314) 
    at org.hibernate.cfg.HbmBinder.bindSimpleId(HbmBinder.java:447) 
    at org.hibernate.cfg.HbmBinder.bindRootPersistentClassCommonValues(HbmBinder.java:380) 
    at org.hibernate.cfg.HbmBinder.bindRootClass(HbmBinder.java:320) 
    at org.hibernate.cfg.HbmBinder.bindRoot(HbmBinder.java:171) 
    at org.hibernate.cfg.Configuration$MetadataSourceQueue.processHbmXml(Configuration.java:3377) 
    at org.hibernate.cfg.Configuration$MetadataSourceQueue.processHbmXmlQueue(Configuration.java:3369) 
    at org.hibernate.cfg.Configuration$MetadataSourceQueue.processMetadata(Configuration.java:3357) 
    at org.hibernate.cfg.Configuration.secondPassCompile(Configuration.java:1334) 
    at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1724) 
    at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1775) 
    at org.springframework.orm.hibernate4.LocalSessionFactoryBuilder.buildSessionFactory(LocalSessionFactoryBuilder.java:184) 
    at org.springframework.orm.hibernate4.LocalSessionFactoryBean.afterPropertiesSet(LocalSessionFactoryBean.java:314) 
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1514) 
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1452) 

El método My Equals usa EqualsBuilder de commons-lang 2.6. puse el siguiente experto opta

SET MAVEN_OPTS=%MAVEN_OPTS% -XX:-UseSplitVerifier 

después de leer este Java 7 JVM verifyError

Nota: Mi prueba de obras bajo JDK 1.6 update 29.

¿cómo puedo solucionar esto? Parece que configurar -XX: -UseSplitVerifier sigue causando el error.

+0

Limpiaría y construiría todo el proyecto de nuevo y probaré otras commons-lang lib. Parece un poco como este problema: http://stackoverflow.com/a/8617057/1064325 – falsarella

+0

Hibernate usa cglib y depende de cómo haya configurado la fuente, también podría estar utilizando bibliotecas similares, tal vez podrían ser las culpables. Intente utilizar una versión más reciente de cglib en su classpath y vea si eso satisface. –

Respuesta

14

Según surefire plugin documentation MAVEN_OPTS no son heredados por una JVM dado lugar, por lo que es necesario especificar argLine parámetro de configuración con -XX: -UseSplitVerifier en el elemento de configuración experta-segura-plugin.

+0

Quizás puedas aceptar la respuesta entonces. Gracias. :) –

+4

Ex: ' org.apache.maven.plugins experto-segura-plugin -XX: -UseSplitVerifier ' Cómo –

+0

hacer esto usando Ant? Lo que probé ? No funciona. Estoy usando JDK 6 u43 –

-1

usted parece ser entrar en conflicto con el "mejorado" verificador de código de bytes (que está realmente abajo idiotizada tal que exige mucha más información verificador ser suministrado por el compilador). Es necesario que o bien obtener su código procesada por una cadena compilador que produce el formato de código de bytes "mejorado" o bien tener la versión del archivo de clase se establece en la versión "antigua" (que estoy pensando que sería algo menos de 50,0).

+0

El problema en realidad no está en el código de usuario, sino en las herramientas/bibliotecas, como Hibernate y CGLIB. Estas herramientas no son conscientes de los nuevos requisitos de código de bytes y, obviamente, no funcionan bien con las clases compiladas para apuntar Java 7. –

+0

@EugeneKuleshov - Entonces, ¿qué solución propone que no sea uno de los dos sugerí? –

+0

Aquí está la cosa. Realmente no ofreciste una solución al problema original del póster, sin embargo, hiciste algunos comentarios ofensivos sobre el verificador de bytecode. –

Cuestiones relacionadas