Lors de l'exécution d'un projet construit par maven avec les dépendances suivantes:
<dependency>
<groupId>org.Eclipse.persistence</groupId>
<artifactId>javax.persistence</artifactId>
<version>2.2.0</version>
</dependency>
<dependency>
<groupId>org.Eclipse.persistence</groupId>
<artifactId>eclipselink</artifactId>
<version>2.7.0</version>
</dependency>
J'obtiens l'erreur suivante au moment de l'exécution:
Java.lang.SecurityException: class "javax.persistence.Cacheable"'s signer information does not match signer information of other classes in the same package
L'artefact javax.persistence-2.2.0 est signé et contient l'annotation javax.persistence.Cacheable.class, tandis que l'artefact eclipselink-2.7.0 est/ pas signé et contient la même annotation de classe Java.
Comment cela peut-il être corrigé?
Modifier
Le remplacement de la version 2.2.0 de l'artefact javax.persistence par la version 2.1.1 corrige le problème (celui-ci n'est pas signé), mais je ne suis pas sûr que ce soit une situation normale.
Merci Stéphane - le montage à la fin de votre question m'a aidé à "résoudre" le même problème. Pour toute autre personne qui en parle également, voici une réponse plus complète. Voici ce dont vous avez besoin pour "réparer" les choses dans votre pom (jusqu'à ce que Eclipse corrige les choses correctement):
<!-- See https://stackoverflow.com/q/45870753 -->
<dependency>
<groupId>org.Eclipse.persistence</groupId>
<artifactId>eclipselink</artifactId>
<version>2.7.0</version>
<exclusions>
<exclusion>
<groupId>org.Eclipse.persistence</groupId>
<artifactId>javax.persistence</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.Eclipse.persistence</groupId>
<artifactId>javax.persistence</artifactId>
<version>2.1.1</version>
</dependency>
Ceci récupère eclipselink
mais exclut la dépendance javax.persistence
qu'il tente d'extraire et la remplace par une version antérieure de javax.persistence
qui n'a pas le problème de la signature.
De plus: javax.persistence
version 2.2.0
est explicitement insérée, dans le fragment de nom de page affiché dans la question d'origine, bien qu'il s'agisse déjà d'une dépendance transitive de eclipselink
.
Résumé - l'artefact eclipselink
dépend de javax.persistence
et les deux contiennent des classes contenues dans le package javax.persistence
. Cependant, le fichier jar javax.persistence
est signé tandis que celui eclipselink
ne l’est pas. Ainsi, lors du chargement d'une classe à partir du package javax.persistence
dans le fichier jar eclipselink
, Java se plaindra du fait que son absence de signature ne correspond pas aux classes déjà chargées du même package dans le fichier jar javax.persistence
.
Détails - Si je mets un point d'arrêt dans Java.util.concurrent.ConcurrentHashMap.putIfAbsent(K, V)
avec la condition "javax.persistence".equals(arg0)
, je vois que javax.persistence
est associé à la valeur CodeSource
suivante:
(file:/Users/georgehawkins/.m2/repository/org/Eclipse/persistence/javax.persistence/2.2.0/javax.persistence-2.2.0.jar [
[
Version: V3
Subject: CN="Eclipse Foundation, Inc.", OU=IT, O="Eclipse Foundation, Inc.", L=Ottawa, ST=Ontario, C=CA
Signature Algorithm: SHA256withRSA, OID = 1.2.840.113549.1.1.11
...
C'est à dire. javax.persistence-2.2.0.jar
est signé par la fondation Eclipse et contient des classes dans le package javax.persistence
. Ce fichier jar est extrait lorsqu'une partie de mon application (quelque chose de plus profond dans la logique Spring) essaie de charger javax.persistence.EntityManagerFactory
.
Si je place ensuite un point d'arrêt dans Java.lang.ClassLoader.checkCerts(String, CodeSource)
sur la ligne throw new SecurityException
, je vois qu'il atteint cette ligne lorsque la valeur passée dans CodeSource
est:
(file:/Users/georgehawkins/.m2/repository/org/Eclipse/persistence/eclipselink/2.7.0/eclipselink-2.7.0.jar <no signer certificates>)
C'est à dire. eclipselink-2.7.0.jar
contient également des classes qui sont dans le package javax.persistence
, mais il est non signé, ce qui provoque un conflit qui entraîne la génération de SecurityException
. Cela se produit lorsque quelque chose (également dans la logique Spring) tente de charger javax.persistence.PersistenceUtil
.
Si je regarde le résultat de mvn dependency:tree
, je constate que cette incompatibilité semble être réduite à eclipselink
elle-même - elle extrait org.Eclipse.persistence:javax.persistence:jar:2.2.0
elle-même. C'est à dire. ce n'est pas un conflit avec une autre dépendance:
[INFO] | \- org.Eclipse.persistence:eclipselink:jar:2.7.0:compile
[INFO] | +- org.Eclipse.persistence:javax.persistence:jar:2.2.0:compile
[INFO] | +- org.Eclipse.persistence:commonj.sdo:jar:2.1.1:compile
[INFO] | +- javax.validation:validation-api:jar:1.1.0.Final:compile
[INFO] | \- org.glassfish:javax.json:jar:1.0.4:compile
Je me suis connecté à bugs.Eclipse.org - voir bug 525457 .
Pour résoudre ce problème, insérez la dépendance appropriée conforme à JPA 2.2 pour EclipseLink 2.7.x, dans votre fichier PAV maven, en tant que:
<dependency>
<groupId>org.Eclipse.persistence</groupId>
<artifactId>org.Eclipse.persistence.jpa</artifactId>
<version>2.7.1</version>
</dependency>
eclipselink.jar en tant que tel est conçu comme un package tout-en-un, non compatible avec osgi, contenant toutes les parties du projet eclipselink (c.-à-d. sdo, trucs spécifiques à la base de données Oracle, dbws, nosql ..) avec la possibilité de s'exécuter avec jpa api 2.0 sur le chemin de classe - au moins dans les versions 2.x. Dans de nombreux cas, cela n'est pas nécessaire et des composants appropriés peuvent être utilisés, tels que org.Eclipse.persistence.jpa, org.Eclipse.persistence.Oracle, etc. Pour la liste complète, voir ie: http: //search.maven .org/# search% 7Cga% 7C1% 7Corg.Eclipse.persistence
J'ai corrigé cela en changeant l'ordre d'affichage des jars dans le classpath. Dans mon cas, j'utilise Tomcat et j'ai dû modifier catalina.properties pour mettre javax avant eclipselink.
La réponse d'Obinna est correcte. Je suppose qu'il y avait un problème avec eclipselink 2.7.x - comme George l'a indiqué. J'ai eu un problème similaire lors de la mise à niveau d'eclipselink, mais il s'agissait simplement de mauvais artefacts. Le problème initialement décrit semble résulter d’un référencement externe de javax.persistence - il n’est absolument pas nécessaire.
La configuration correcte de maven est disponible dans le wiki eclipselink: https://wiki.Eclipse.org/EclipseLink/Maven
Je rencontre également ce problème, mon cas étant un peu différent, en ce sens que je n’utilise pas Maven. Cependant, je mets une réponse ici, car cela pourrait donner aux gens une idée de la façon de gérer cela dans leur propre situation. Après tout, le titre parle de cette discordance, en général, un sous-cas concerne l'utilisation de Maven.
J'utilise eclipselink dans un projet NetBeans. Initialement, je plaçais le fichier jar eclipselink (eclipselink-2.7.0.jar
) et les fichiers jar org.Eclipse.persistence nécessaires en tant que bibliothèques externes de mon projet. Les commentaires de Sergey et entreprenr ci-dessus sont en fait ce qui me conduit à résoudre mon problème. Ce que je devais faire était de créer une nouvelle bibliothèque (Outils-> Bibliothèques-> Nouvelle bibliothèque ...) qui not ne contienne pas le fichier jar eclipselink (c.-à-d. Que eclipselink-2.7.0.jar
n'est pas ajouté dans la bibliothèque), seule l'organisation Fichiers JAR .Eclipse.persistence nécessaires au projet, par exemple: org.Eclipse.persistence.antlr-2.7.0.jar
, org.Eclipse.persistence.asm-2.7.0.jar
, org.Eclipse.persistence.core-2.7.0.jar
, org.Eclipse.persistence.jpa.modelgen.processor-2.7.0.jar
, org.Eclipse.persistence.jpa-2.7.0.jar
, etc. J'ai ensuite ajouté cette bibliothèque à mon projet et l'exception a disparu.
Bien sûr, je devais également remplacer tous les fichiers jar org.Eclipse.persistence sur mon serveur par leur version 2.7.0 et remplacer le javax.persistence.jar
par sa version 2.2.0 (j'utilise payara, ils sont donc situés sous <payara_home>\glassfish\modules
).