EclipseLink 2.7.0 and JPA API 2.2.0 - signature mismatch

前端 未结 10 1555
滥情空心
滥情空心 2020-12-03 04:31

When running a project built by maven with the following dependencies:

        
            org.eclipse.persistence

        
相关标签:
10条回答
  • 2020-12-03 04:43

    My project was working on JDK-8, but stopped to work when I upgraded it to openJDK-11. I solved it excluding the jpa-persistence module, and adding again on the version 2.2:

       dependencies.create('org.eclipse.persistence:eclipselink:2.7.4') {
          exclude module: "javax.persistence"
       },
       'javax.persistence:javax.persistence-api:2.2', //add it again, manually
       'org.eclipse.persistence:org.eclipse.persistence.asm:2.7.4',
       'org.eclipse.persistence:org.eclipse.persistence.antlr:2.7.4',
       'org.eclipse.persistence:org.eclipse.persistence.moxy:2.7.4',
       'org.eclipse.persistence:org.eclipse.persistence.core:2.7.4'
    
    0 讨论(0)
  • 2020-12-03 04:47

    Because I could not find an answer for this problem when only using a Tomcat and this thread is often linked with this problem, I am going to post my solution here:

    Since the signature is in the MANIFEST.MF you can change the signatures in the .jar files using 7zip or WinRAR to open them or simply delete them from the META-INF files of both .jar's and then import the changed files to your IDE.

    A useful thread for the Signature-Mismatch-Problem is this thread: Java SecurityException: signer information does not match

    0 讨论(0)
  • 2020-12-03 04:57

    eclipselink.jar as such is designed as all-in-one bundle, not osgi enabled jar containing all partsof eclipselink project (ie sdo, oracle db specific stuff, dbws, nosql..) with ability to run with jpa api 2.0 on the classpath - at least in 2.x versions. In many cases this is not needed and proper components can be used instead, such as org.eclipse.persistence.jpa, org.eclipse.persistence.oracle etc. For the full list see ie: http://search.maven.org/#search%7Cga%7C1%7Corg.eclipse.persistence

    0 讨论(0)
  • 2020-12-03 04:59

    I also run into this problem, with my case being a bit different, in that I am not using Maven. However, I place an answer here, as it might give people an idea about how to deal with this in their own situation. After all, the title is about this mismatch, in general, one sub-case being when using Maven.

    I am using eclipselink in a NetBeans project. Initially, I was placing both the the eclipselink jar file (eclipselink-2.7.0.jar) and the needed org.eclipse.persistence jar files as external libraries to my project. Comments by Sergey and entreprenr above are what actually lead me to solve my problem. What I had to do was create a new library (Tools->Libraries->New Library...) which does not contain the eclipselink jar file (i.e. eclipselink-2.7.0.jar is not added in the library), only the specific org.eclipse.persistence jar files that are necessary for the project, e.g. 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. I then added this library to my project and the exception vanished.

    Of course, I also had to replace all org.eclipse.persistence jar files on my server with their 2.7.0 version and also replace the javax.persistence.jar with its 2.2.0 version (I use payara, so these are located under <payara_home>\glassfish\modules).

    0 讨论(0)
  • 2020-12-03 05:01

    Thanks Stéphane - the edit at the end of your question helped me "fix" the same problem. For anyone else who hits this as well - here is an expanded answer. This is what you need to "fix" things in your pom (until Eclipse fix things properly):

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

    This pulls in eclipselink but excludes the javax.persistence dependency that it tries to pull in and replaces it with an earlier version of javax.persistence that doesn't have the signing issue.

    Aside: javax.persistence version 2.2.0 is explicitly pulled in, in the pom fragment shown in the original question, despite already being a transitive dependency of eclipselink.

    Explanation

    Summary - the eclipselink artifact depends on javax.persistence and both contain classes that are in the package javax.persistence. However the javax.persistence jar is signed while the eclipselink one is not. So the Java runtime will complain, when loading a class from the package javax.persistence in the eclipselink jar, that it's lack of signing doesn't match with classes already loaded from the same package in the javax.persistence jar.

    Details - if I put a breakpoint in java.util.concurrent.ConcurrentHashMap.putIfAbsent(K, V) with condition "javax.persistence".equals(arg0) then I see that javax.persistence is mapped to the following CodeSource value:

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

    I.e. javax.persistence-2.2.0.jar is signed by the Eclipse Foundation and contains classes in the package javax.persistence. This jar is pulled in when some part of my application (actually something deep in Spring logic) tries to load javax.persistence.EntityManagerFactory.

    If I then put a breakpoint in java.lang.ClassLoader.checkCerts(String, CodeSource) on the throw new SecurityException line I then see that it hits this line when the passed in CodeSource is:

    (file:/Users/georgehawkins/.m2/repository/org/eclipse/persistence/eclipselink/2.7.0/eclipselink-2.7.0.jar <no signer certificates>)
    

    I.e. eclipselink-2.7.0.jar also contain classes that are in the javax.persistence package but it is unsigned so a clash occurs that results in a SecurityException being thrown. This happens when something (also deep in Spring logic) tries to load javax.persistence.PersistenceUtil.

    If I look at the output of mvn dependency:tree I see that this mismatch seems to be down to eclipselink itself - it is pulling in org.eclipse.persistence:javax.persistence:jar:2.2.0 itself. I.e. it isn't some clash with some other dependency:

    [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
    

    I've logged this now at bugs.eclipse.org - see bug 525457.

    0 讨论(0)
  • 2020-12-03 05:01

    I fixed this by switching the order in which the jars appear in the classpath. In my case, I'm using Tomcat and had to modify catalina.properties to put javax before eclipselink.

    0 讨论(0)
提交回复
热议问题