Ho ricompilato le mie classi come al solito e improvvisamente ho ricevuto il seguente messaggio di errore. Perché? Come posso ripararlo?
java.lang.SecurityException: class "Chinese_English_Dictionary"'s signer information does not match signer information of other classs in the same package at java.lang.ClassLoader.checkCerts(ClassLoader.java:776) Questo accade quando le classi appartenenti allo stesso pacchetto vengono caricate da diversi file JAR, e quei file JAR hanno firme firmate con certificati diversi – o, forse più spesso, almeno una è firmata e una o più altre non lo sono (che include le classi caricate dalle directory dato che quelli AFAIK non possono essere firmati).
Quindi assicuratevi che tutti i JAR (o almeno quelli che contengono classi dagli stessi pacchetti) siano firmati usando lo stesso certificato, o rimuovete le firme dal manifest dei file JAR con pacchetti sovrapposti.
Un modo semplice per aggirarlo è semplicemente provare a cambiare l’ordine dei file jar importati che possono essere fatti da (Eclipse). Fai clic con il pulsante destro del mouse sul pacchetto -> Percorso di creazione -> Configura percorso di creazione -> Riferimenti e librerie -> Ordina ed esporta. Prova a cambiare l’ordine dei jar che contengono i file delle firme.
A. Se usi Maven, un modo utile per eseguire il debug di un conflitto su jar è:
mvn dependency:tree
Ad esempio, per un’eccezione:
java.lang.SecurityException: class "javax.servlet.HttpConstraintElement"'s signer information does not match signer information of other classs in the same package
noi facciamo:
mvn dependency:tree|grep servlet
La sua produzione:
[INFO] +- javax.servlet:servlet-api:jar:2.5:compile [INFO] +- javax.servlet:jstl:jar:1.2:compile [INFO] | +- org.eclipse.jetty.orbit:javax.servlet.jsp:jar:2.2.0.v201112011158:compile [INFO] | +- org.eclipse.jetty.orbit:javax.servlet.jsp.jstl:jar:1.2.0.v201105211821:compile [INFO] | +- org.eclipse.jetty.orbit:javax.servlet:jar:3.0.0.v201112011016:compile [INFO] +- org.eclipse.jetty:jetty-servlet:jar:9.0.0.RC2:compile
mostra clashing servlet-api 2.5 e javax.servlet 3.0.0.x.
B. Altri suggerimenti utili (come eseguire il debug dell’eccezione di sicurezza e come escludere i servizi di assistenza) sono alla domanda al momento in cui le informazioni del firmatario non corrispondono .
Nel mio caso, avevo duplicato la versione JAR di BouncyCastle nel mio percorso della libreria: S
Ciò può verificarsi con i proxy cglib-instrumented poiché CGLIB utilizza le proprie informazioni sul firmatario anziché le informazioni sul firmatario della class di destinazione dell’applicazione.
Ho avuto un’eccezione simile:
java.lang.SecurityException: class "org.hamcrest.Matchers"'s signer information does not match signer information of other classs in the same package
Il problema principale era che includevo la libreria di Hamcrest due volte. Una volta usando il file pom Maven. E ho anche aggiunto la libreria JUnit 4 (che contiene anche una libreria di Hamcrest) al percorso di costruzione del progetto. Ho semplicemente dovuto rimuovere JUnit dal percorso di costruzione e tutto andava bene.
Nome: net / sf / jasperreports / engine / util / xml / JaxenXPathExecuterFactory.c lass SHA-256-Digest: q3B5wW + hLX / + lP2 + L0 / 6wRVXRHq1mISBo1dkixT6Vxc =
Se lo stai eseguendo in Eclipse, controlla i vasi di tutti i progetti aggiunti al percorso di generazione; oppure fai control-shift-T e cerca più jar che corrispondono allo stesso spazio dei nomi. Quindi rimuovere i jar ridondanti o obsoleti dal percorso di generazione del progetto.
Nel mio caso si trattava di un conflitto di nomi di pacchetti. Il progetto corrente e la libreria referenziata firmata avevano un pacchetto in common package.foo.utils . Ho appena cambiato l’attuale nome del pacchetto sobject a errori del progetto in qualcos’altro.
Ciò si verifica anche se includi due volte un file con nomi diversi o da posizioni diverse, specialmente se si tratta di due versioni diverse dello stesso file.
Potrei aggiustarlo
Causa principale: questo è un problema comune quando si utilizza l’implementazione Sun JAXB con i jar firmati. In sostanza, l’implementazione di JAXB sta tentando di evitare la riflessione generando una class per accedere direttamente alle proprietà senza utilizzare la reflection. Sfortunatamente, genera questa nuova class nello stesso pacchetto della class a cui si accede da cui proviene questo errore.
Soluzione: aggiungere la seguente proprietà di sistema per disabilitare le ottimizzazioni JAXB che non sono compatibili con i contenitori firmati: -Dcom.sun.xml.bind.v2.bytecode.ClassTailor.noOptimize = true
In base alla risposta di @Mohit Phougat, se stai eseguendo una Groovy con annotazioni @Grab, puoi provare a riordinare tali annotazioni.
Un thread un po ‘troppo vecchio ma dato che sono rimasto bloccato per un po’ di tempo su questo, ecco la correzione (spero che aiuti qualcuno)
Il mio scenario:
Il nome del pacchetto è: com.abc.def. Ci sono 2 file jar che contengono classi da questo pacchetto, diciamo jar1 e jar2, cioè alcune classi sono presenti in jar1 e altre in jar2. Questi file jar sono firmati utilizzando lo stesso keystore ma in momentjs diversi della build (ovvero separatamente). Ciò sembra comportare una firma diversa per i file in jar1 e jar2.
Ho messo tutti i file in jar1 e li ho creati (e firmati) tutti insieme. Il problema va via.
PS: i nomi dei pacchetti e i nomi dei file jar sono solo degli esempi
Se hai aggiunto tutti i vasi da bouncycastle.org (nel mio caso da crypto-159.zip), rimuovi solo quelli per i JDK che non si applicano a te. Ci sono ridondanze. Probabilmente hai solo bisogno dei vasi “jdk15on”.