NoSuchMethodError en javax.persistence.Table.indexes () [Ljavax / persistence / Index

Tengo una aplicación Play Framework y estaba usando Hibernate 4.2.5.Final (que se recupera a través del administrador de dependencias de Maven). Decidí actualizar a Hibernate 4.3.0.Final, recompilar mi aplicación con éxito y ejecutarla.

Recibí la excepción a continuación y no he podido averiguar por qué. Bajé de nuevo a 4.2.5 y este problema no ocurrió. Luego, intenté actualizar Hibernate con cada versión final después de 4.2.5. Es decir, pasé de 4.2.5.Final a 4.2.6.Final, a 4.2.7.Final, a 4.2.8.Final y luego a 4.3.Final. El problema no ocurre hasta que actualizo a 4.3.0.Final.

Información de la versión de Java

java version "1.7.0_45"
Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)

Y excepción :

play.api.UnexpectedException: Unexpected exception[NoSuchMethodError: javax.persistence.Table.indexes()[Ljavax/persistence/Index;]
    at play.core.ReloadableApplication$$anonfun$get$1$$anonfun$apply$1$$anonfun$1.apply(ApplicationProvider.scala:152) ~[play_2.10.jar:2.2.1]
    at play.core.ReloadableApplication$$anonfun$get$1$$anonfun$apply$1$$anonfun$1.apply(ApplicationProvider.scala:112) ~[play_2.10.jar:2.2.1]
    at scala.Option.map(Option.scala:145) ~[scala-library.jar:na]
    at play.core.ReloadableApplication$$anonfun$get$1$$anonfun$apply$1.apply(ApplicationProvider.scala:112) ~[play_2.10.jar:2.2.1]
    at play.core.ReloadableApplication$$anonfun$get$1$$anonfun$apply$1.apply(ApplicationProvider.scala:110) ~[play_2.10.jar:2.2.1]
    at scala.util.Success.flatMap(Try.scala:200) ~[scala-library.jar:na]
Caused by: java.lang.NoSuchMethodError: javax.persistence.Table.indexes()[Ljavax/persistence/Index;
    at org.hibernate.cfg.annotations.EntityBinder.processComplementaryTableDefinitions(EntityBinder.java:936) ~[hibernate-core-4.3.0.Final.jar:4.3.0.Final]
    at org.hibernate.cfg.AnnotationBinder.bindClass(AnnotationBinder.java:781) ~[hibernate-core-4.3.0.Final.jar:4.3.0.Final]
    at org.hibernate.cfg.Configuration$MetadataSourceQueue.processAnnotatedClassesQueue(Configuration.java:3762) ~[hibernate-core-4.3.0.Final.jar:4.3.0.Final]
    at org.hibernate.cfg.Configuration$MetadataSourceQueue.processMetadata(Configuration.java:3716) ~[hibernate-core-4.3.0.Final.jar:4.3.0.Final]
    at org.hibernate.cfg.Configuration.secondPassCompile(Configuration.java:1410) ~[hibernate-core-4.3.0.Final.jar:4.3.0.Final]
    at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1844) ~[hibernate-core-4.3.0.Final.jar:4.3.0.Final]

Me encontré con el mismo problema. La pregunta aquí es que el artefacto play-java-jpa (clave javaJpa en el archivo build.sbt) depende de una versión diferente de la especificación (version 2.0 -> "org.hibernate.javax.persistence" % "hibernate-jpa-2.0-api" % "1.0.1.Final").

Cuando agregó hibernate-entitymanager 4.3, esto trajo la especificación más reciente (2.1) y un proveedor de fábrica diferente para el entitymanager. Básicamente, terminó teniendo ambos archivos jar en el classpath como dependencias transitivas.

Edite su archivo build.sbt de esta manera y solucionará temporalmente su problema hasta que el juego lance una nueva versión del complemento jpa para la dependencia api más nueva.

libraryDependencies ++= Seq(
javaJdbc,
javaJpa.exclude("org.hibernate.javax.persistence", "hibernate-jpa-2.0-api"),
"org.hibernate" % "hibernate-entitymanager" % "4.3.0.Final"
)

Esto es para play 2.2.x. En versiones anteriores había algunas diferencias en los archivos de compilación.

Hibernate 4.3 es la primera versión que implementa la especificación JPA 2.1 (parte de Java EE 7). Y, por lo tanto, espera la biblioteca JPA 2.1 en la ruta de clases, no la biblioteca JPA 2.0. Es por eso que obtiene esta excepción: Table.indexes () es un nuevo atributo de Table, introducido en JPA 2.1

Probablemente tenga 2 versiones diferentes de hibernate-jpa-api en el classpath. Para comprobar esa ejecución:

mvn dependency:tree >dep.txt

Luego busque si hay hibernate-jpa-2.0-api e hibernate-jpa-2.1-api. Y excluye el exceso.

Actualizo mi Hibernate JPA a 2.1 y funciona.

<dependency>
    <groupId>org.hibernate.javax.persistence</groupId>
    <artifactId>hibernate-jpa-2.1-api</artifactId>
    <version>1.0.0.Final</version>
</dependency>

Podría resolver el problema simplemente reemplazando el archivo JPA api jar que se encuentra jboss7 / modules / javax / persistence / api / main con 'hibernate-jpa-2.1-api'. también con la actualización de module.xml en el directorio.

Error: java.lang.NoSuchMethodError: javax.persistence.JoinTable.indexes () [Ljavax / persistence / Index;

Lo único que resolvió mi problema fue eliminar la siguiente dependencia en pom.xml: <dependency> <groupId>org.hibernate.javax.persistence</groupId> <artifactId>hibernate-jpa-2.1-api</artifactId> <version>1.0.0.Final</version> </dependency>

Y reemplácelo por:

<dependency>
  <groupId>javax.persistence</groupId>
  <artifactId>persistence-api</artifactId>
  <version>1.0.2</version>
</dependency>

Espero que ayude a alguien.

He experimentado el mismo problema en mi aplicación de arranque de primavera. después de eliminar manualmente el archivo javax.persistance.jar de la carpeta lib. se solucionó el problema. en el archivo pom.xml he permanecido siguiendo solo la dependencia

  <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-data-jpa</artifactId>
  </dependency>

Tuve el mismo problema, lo solucioné usando una org.hibernate.annotations.Tableanotación en lugar de javax.persistence.Tableen la clase Entity.

import javax.persistence.Entity;
import org.hibernate.annotations.Table;

@Entity
@Table(appliesTo = "my_table")
public class MyTable{
//and rest of the code

Hay varios proveedores de JPA en su classpath. O al menos en la carpeta lib del servidor de aplicaciones.

Si está usando Maven, verifique las dependencias usando el comando mencionado aquí https://stackoverflow.com/a/47474708/3333878

Luego, corrija eliminando / excluyendo la dependencia no deseada.

Si solo tiene una dependencia en su classpath, entonces el cargador de clases del servidor de aplicaciones podría ser el problema.

Dado que los servidores de aplicaciones JavaEE como Websphere, Wildfly, Tomee, etc., tienen sus propias implementaciones de JPA y otros estándares EE, el cargador de clases puede cargar su propia implementación en lugar de elegir su ruta de clases en el archivo WAR / EAR.

Para evitar esto, puede intentar los pasos a continuación.

1. Eliminando el jar ofensivo en la ruta de la biblioteca de Application Servers Proceda con precaución, ya que podría dañar otras aplicaciones alojadas.

En Tomee 1.7.5 Plume / Web se habrá incluido eclipselink-2.4.2en la libcarpeta usando JPA 2.0, pero tuve que usar JPA 2.1 de org.hibernate:hibernate-core:5.1.17, así que eliminé el jar eclipselink y agregué todas las dependencias relacionadas / transitivas del núcleo de hibernación.

2. Agrega una biblioteca compartida. y agregue jarras manualmente a la ruta del servidor de aplicaciones. Websphere tiene esta opción.

3. En Websphere, la ejecución del cargador de clases se puede cambiar. por lo que hacer que la ruta de clase del servidor de aplicaciones se cargue en último lugar, es decir, el padre en último lugar y la ruta de acceso se cargue primero. Puede resolver esto.

Verifique si su servidor de aplicaciones tiene las características anteriores, antes de continuar con el primer punto.

Referencias de IBM websphere:

https://www.ibm.com/support/knowledgecenter/SSEQTP_9.0.5/com.ibm.websphere.base.doc/ae/trun_classload_server.html

https://www.ibm.com/support/pages/how-create-shared-library-and-associate-it-application-server-or-enterprise-application-websphere-application-server