"Ungültige Signaturdatei" beim Versuch, eine JAR-Datei auszuführen


450

Mein Java-Programm ist in einer JAR-Datei verpackt und verwendet eine externe JAR-Bibliothek, eine Hüpfburg . Mein Code wird gut kompiliert, aber das Ausführen des JAR führt zu folgendem Fehler:

Ausnahme im Thread "main" java.lang.SecurityException: Ungültiger Digest der Signaturdatei für Manifest-Hauptattribute

Ich habe über eine Stunde lang gegoogelt und nach einer Erklärung gesucht und sehr wenig Wert gefunden. Wenn jemand diesen Fehler schon einmal gesehen hat und Hilfe anbieten könnte, wäre ich verpflichtet.


1
Versuchen Sie, Ihr eigenes Glas zu unterschreiben? Wenn ja, wie versuchen Sie es zu unterschreiben?
Cogsy

Nein, zumindest glaube ich nicht. Xcode versucht möglicherweise, es selbst zu signieren, aber es scheint keine Einstellung zu geben, um dies zu deaktivieren.

Vergessen Sie nicht zu prüfen, ob auch Jars mit implementierten Schnittstellen signiert sind!
Gaurav

Antworten:


47

Die hier aufgeführte Lösung bietet möglicherweise einen Zeiger.

Ungültiger Digest der Signaturdatei für Manifest-Hauptattribute

Endeffekt :

Es ist wahrscheinlich am besten, das offizielle JAR unverändert zu lassen und es einfach als Abhängigkeit in die Manifestdatei für Ihre Anwendungs-JAR-Datei einzufügen.


3
Wie würde ich dies in der Manifestdatei widerspiegeln? Ich habe noch nie einen bearbeitet. Ich verwende Xcode und die übliche Konvention besteht darin, externe JAR-Bibliotheken zur Aufnahme in das Verzeichnis myproject / lib zu stellen, was ich auch tue.

@ user123003 .. wie es bei Intelli-J der Fall ist
MikeM

13
Leider verwenden einige von uns Dinge wie "Maven Shade Plugin", so dass es in diesen Fällen nicht so einfach ist, wörtliche Kopien des Originalglases
einzuschließen

schamloser Stecker zur Beantwortung auf dieser Seite: stackoverflow.com/a/30922181/448779
foo

Was ist mit Maven-Assembly-Plugin? Es
löst

1083

Für diejenigen, die diesen Fehler beim Erstellen eines Uber-JAR mit erhalten haben maven-shade-plugin, besteht die Lösung darin, Manifest-Signaturdateien auszuschließen, indem der Plugin-Konfiguration die folgenden Zeilen hinzugefügt werden:

<configuration>
    <filters>
        <filter>
            <artifact>*:*</artifact>
            <excludes>
                <exclude>META-INF/*.SF</exclude>
                <exclude>META-INF/*.DSA</exclude>
                <exclude>META-INF/*.RSA</exclude>
            </excludes>
        </filter>
    </filters>
    <!-- Additional configuration. -->
</configuration>

9
Ich habe diese Methode für mein Überglas verwendet und sie hat großartig funktioniert. Unter maven.apache.org/plugins/maven-shade-plugin/examples/… finden Sie ein vollständiges POM-Beispiel , das diese Methode zum Filtern der enthaltenen Dateien zeigt.
M. Dudley

4
Ich war versucht, einen ganz neuen Thread zu starten - aber da dies die Nummer 1 in den Googles-Ergebnissen ist, schien es angebracht, ihn hier zu behalten. Die hier aufgeführten Zeilen befinden sich in der von mir verwendeten POM-Datei - und beim Ausführen der Anwendung wird immer noch der Sicherheitsfehler angezeigt. Es baut sich gut - und läuft natürlich gut, wenn man KEIN Uber-Glas macht - wie erwartet. Und obwohl dies sicherlich eine Option ist - halten Sie sie getrennt -, löst es das Problem nicht, wenn Sie ein Uber Jar wollen.
Gavin Baumanis

7
Das funktioniert bei mir, aber ... warum mussten wir die Signaturdateien ignorieren? Ich bin mir sicher, dass das Signaturmanifest aus einem bestimmten Grund vorhanden ist ...
Jeryl Cook

4
Stellen Sie sicher, dass Sie "mvn clean" ausführen, nachdem Sie oben ausgeführt haben!
Codeinjuice

4
@ JerylCook Die Signaturdateien zeigen an, dass der Inhalt dieses JARs diese Dateien enthält. Wenn Sie ein Überglas erstellen, fügen Sie dem Glas eine Reihe weiterer Dateien hinzu, sodass die Signatur nicht korrekt ist. Wenn Sie es wirklich wollten, könnten Sie das neue Glas erneut signieren, aber natürlich mit Ihrer Unterschrift, nicht mit der alten. Alternativ könnten Sie das Uber-Jar nicht verteilen, sondern das signierte Jar als separate Datei einschließen, aber das macht den Zweck eines Uber-Jars in erster Linie zunichte.
LadyCailin

139

Für diejenigen, die gradle verwenden und versuchen, ein Fettglas zu erstellen und zu verwenden, kann die folgende Syntax hilfreich sein.

jar {
    doFirst {
        from { configurations.compile.collect { it.isDirectory() ? it : zipTree(it) } } 
    }
    exclude 'META-INF/*.RSA', 'META-INF/*.SF','META-INF/*.DSA' 
}

1
Dies schließt grundsätzlich alle Dateien mit den Erweiterungen .RSA, .SF oder .DSA im META-INF-Verzeichnis aus.
Keith P

9
Durch das Signieren einer JAR-Datei werden diese Dateien unter META-INF hinzugefügt. Wenn sie jedoch enthalten sind, stimmen die Signaturen nicht mehr mit dem JAR-Inhalt überein. Durch das Entfernen dieser Signaturen wird die Nichtübereinstimmung der Signaturen vermieden.
Peter N. Steinmetz

1
Es gibt eine ähnliche Frage streng über die Verwendung von Fettglas in gradle - stackoverflow.com/questions/4871656/…
Tomasz Sętkowski

3
Das hat bei mir nicht funktioniert. Ich musste das excludemeiner fatJarAufgabe stellen, die diesen configurations.compile.collectBefehl hatte. Siehe stackoverflow.com/a/31426413/103412
Torsten

1
Dies löst auch den FehlerError: Could not find or load main class App Caused by: java.lang.ClassNotFoundException: App
vonox7

57

Einige Ihrer Abhängigkeiten sind wahrscheinlich signierte Jarfiles. Wenn Sie sie alle zu einer großen Jarfile kombinieren, sind die entsprechenden Signaturdateien immer noch vorhanden und stimmen nicht mehr mit der "großen kombinierten" Jarfile überein, sodass die Laufzeit anhält und denkt, dass die JAR-Datei manipuliert wurde (was sie ... muss) sprechen).

Sie können das Problem lösen, indem Sie die Signaturdateien aus Ihren Jarfile-Abhängigkeiten entfernen. Leider ist es nicht möglich, dies in einem Schritt in ant zu tun .

Ich konnte dies jedoch in zwei Schritten mit Ant zum Laufen bringen, ohne jede Jarfile-Abhängigkeit speziell zu benennen, indem ich Folgendes verwendete:

<target name="jar" depends="compile" description="Create one big jarfile.">
    <jar jarfile="${output.dir}/deps.jar">
        <zipgroupfileset dir="jars">
            <include name="**/*.jar" />
        </zipgroupfileset>
    </jar>
    <sleep seconds="1" />
    <jar jarfile="${output.dir}/myjar.jar" basedir="${classes.dir}">
        <zipfileset src="${output.dir}/deps.jar" excludes="META-INF/*.SF" />
        <manifest>
            <attribute name="Main-Class" value="com.mycompany.MyMain" />
        </manifest>
    </jar>
</target>

Das Schlafelement soll in Zukunft Fehler bei Dateien mit Änderungsdaten verhindern .

Andere Variationen, die ich in den verknüpften Threads gefunden habe, haben bei mir nicht funktioniert.


Es ist möglich, in einem Schritt Ihre Gläser auf andere Weise anzugeben: <jar destfile = "build / myjar.jar"> <einschränkung> <not> <name name = "META-INF / *. SF" /> </ not> <archives> <zips> <fileset dir = "jarfolder" include = " * / .jar" /> </ zips> </ archives> </ restrikt> </ jar>
DieterDP

57

Bitte benutzen Sie den folgenden Befehl

zip -d yourjar.jar 'META-INF/*.SF' 'META-INF/*.RSA' 'META-INF/*SF'

4
Vielen Dank, ich hatte dieses Problem mit Intellij 14 und Ihre Lösung funktioniert für mich!
Mohamad Kouhi Moghadam

5
Danke, habe für mich in Windows gearbeitet. Öffnen Sie einfach das Glas mit 7zip und löschen Sie die .SF-Dateien. Ich hatte keine .RSA-Dateien zum Löschen
Candino

3
Wow, kann ich nur sagen, dass diese Lösung erstaunlich war (und ich habe dabei etwas sehr Mächtiges gelernt!)? Dies erfordert mehr Upvoting.
Dylan_Larkin

Ich stimme dem Kommentar von @Dylan_Larkin zu, dies hat es für mich gelöst.
Felipe Valdes

26

Ich hatte dieses Problem bei der Verwendung von IntelliJ IDEA 14.01.

Ich konnte es beheben durch:

Datei-> Projektstruktur-> Neue hinzufügen (Artefakte) -> jar-> Von Modulen mit Abhängigkeiten vom Fenster Jar aus Modul erstellen:

Wählen Sie Ihre Hauptklasse

JAR-Datei aus Bibliotheken Wählen Sie Kopie in das Ausgabeverzeichnis und verknüpfen Sie sie über das Manifest


2
Ist es möglich, die abhängigen Gläser in das Zielglas zu stellen?
coder.chenzhi

Ihre Lösungen funktionieren gut! Danke vielmals!
Hzitoun

19

Sicherheit ist bereits ein schwieriges Thema, aber ich bin enttäuscht zu sehen, dass die beliebteste Lösung darin besteht, die Sicherheitssignaturen zu löschen. JCE benötigt diese Signaturen . Maven-Schatten explodiert in der BouncyCastle-JAR-Datei, in der die Signaturen in META-INF abgelegt werden. Die BouncyCastle-Signaturen gelten jedoch nicht für ein neues Uber-JAR (nur für das BC-JAR). Dies führt zu dem ungültigen Signaturfehler in diesem Thread .

Ja, das Ausschließen oder Löschen der von @ruhsuzbaykus vorgeschlagenen Signaturen lässt zwar den ursprünglichen Fehler verschwinden, kann aber auch zu neuen, kryptischen Fehlern führen:

java.security.NoSuchAlgorithmException: PBEWithSHA256And256BitAES-CBC-BC SecretKeyFactory not available

Indem Sie explizit angeben, wo sich der Algorithmus wie folgt befindet:

SecretKeyFactory.getInstance("PBEWithSHA256And256BitAES-CBC-BC","BC");

Ich konnte einen anderen Fehler bekommen:

java.security.NoSuchProviderException: JCE cannot authenticate the provider BC

JCE kann den Anbieter nicht authentifizieren, da wir die kryptografischen Signaturen gelöscht haben, indem wir dem Vorschlag an anderer Stelle in demselben Thread gefolgt sind .

Die Lösung, die ich gefunden habe, war das ausführbare Packer- Plugin, das einen JAR-in-JAR-Ansatz verwendet, um die BouncyCastle-Signatur in einem einzelnen ausführbaren JAR beizubehalten.

AKTUALISIEREN :

Eine andere Möglichkeit, dies zu tun (die richtige?), Ist die Verwendung des Maven Jar-Unterzeichners . Auf diese Weise können Sie Maven Shadow weiterhin verwenden, ohne Sicherheitsfehler zu erhalten. Sie müssen jedoch über ein Codesignaturzertifikat verfügen (Oracle schlägt vor, nach "Java Code Signing Certificate" zu suchen). Die POM-Konfiguration sieht folgendermaßen aus:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-shade-plugin</artifactId>
    <version>3.1.0</version>
    <executions>
        <execution>
            <phase>package</phase>
            <goals>
                <goal>shade</goal>
            </goals>
            <configuration>
                <filters>
                    <filter>
                        <artifact>org.bouncycastle:*</artifact>
                        <excludes>
                            <exclude>META-INF/*.SF</exclude>
                            <exclude>META-INF/*.DSA</exclude>
                            <exclude>META-INF/*.RSA</exclude>
                        </excludes>
                    </filter>
                </filters>
                <transformers>
                    <transformer implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">
                        <mainClass>your.class.here</mainClass>
                    </transformer>
                </transformers>
                <shadedArtifactAttached>true</shadedArtifactAttached>
            </configuration>
        </execution>
    </executions>
</plugin>
<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-jarsigner-plugin</artifactId>
    <version>1.4</version>
    <executions>
        <execution>
            <id>sign</id>
            <goals>
                <goal>sign</goal>
            </goals>
        </execution>
        <execution>
            <id>verify</id>
            <goals>
                <goal>verify</goal>
            </goals>
        </execution>
    </executions>
    <configuration>
        <keystore>/path/to/myKeystore</keystore>
        <alias>myfirstkey</alias>
        <storepass>111111</storepass>
        <keypass>111111</keypass>
    </configuration>
</plugin>

Nein, es gibt keine Möglichkeit, JCE dazu zu bringen, ein selbstsigniertes Zertifikat zu erkennen. Wenn Sie also die BouncyCastle-Zertifikate aufbewahren müssen, müssen Sie entweder das jar-in-jar-Plugin verwenden oder ein JCE-Zertifikat erwerben.


Dies ist definitiv der richtige Weg, auch wenn es arbeitsintensiv ist. Vielen Dank, dass Sie ausführlich auf die Vorbehalte bei der Verwendung der genehmigten Antwort hingewiesen haben. Wissen Sie, ob das JCE-Zertifikat von Sun unterschrieben werden muss? Oder kann
WiteCastle

1
Es gibt Dritte, die Codesignaturzertifikate ausstellen können. Suchen Sie nach "Java Code Signing Certificate", um Optionen anzuzeigen.
MattW

Sie, mein Herr, haben meinen Tag gemacht!
Socona

Hat mir geholfen. Es gibt einige Dateien in dieser Bibliothek, die ich nicht benutze, außer sie helfen mir bei der Fat-Jar-Datei
Saidolim

14

Ich hatte das gleiche Problem, nachdem ich irgendwo darauf hingewiesen hatte, dass es wie folgt funktioniert hat:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-shade-plugin</artifactId>
    <version>3.2.1</version>
    <configuration>
        <createDependencyReducedPom>false</createDependencyReducedPom>
    </configuration>
    <executions>
        <execution>
            <phase>package</phase>
            <goals>
                <goal>shade</goal>
            </goals>
            <configuration>
                <filters>
                    <filter>
                        <artifact>*:*</artifact>
                        <excludes>
                            <exclude>META-INF/*.SF</exclude>
                            <exclude>META-INF/*.DSA</exclude>
                            <exclude>META-INF/*.RSA</exclude>
                        </excludes>
                    </filter>
                </filters>
            </configuration>
        </execution>
    </executions>
</plugin>

1
Dies löste mein Problem schnell! Der Vollständigkeit halber sollte dies im maven-shade-pluginTag stehen.
Kuzeko

1
@ Kuzeko Aktualisierte die Antwort mit Ihrem Vorschlag. Danke
m.nguyencntt

8

Angenommen, Sie erstellen Ihre JAR-Datei mit ant, können Sie ant einfach anweisen, das META-INF-Verzeichnis wegzulassen. Dies ist eine vereinfachte Version meines Ameisenziels:

<jar destfile="app.jar" basedir="${classes.dir}">
    <zipfileset excludes="META-INF/**/*" src="${lib.dir}/bcprov-jdk16-145.jar"></zipfileset>
    <manifest>
        <attribute name="Main-Class" value="app.Main"/>
    </manifest>
</jar>

Wo soll ich diese Zeilen hinzufügen?
Addi.Star

4

Ich habe kürzlich begonnen, IntelliJ für meine Projekte zu verwenden. Einige meiner Kollegen verwenden Eclipse jedoch immer noch für dieselben Projekte. Heute habe ich den gleichen Fehler, nachdem ich die von meinem IntelliJ erstellte JAR-Datei ausgeführt habe. Während alle Lösungen hier über fast dasselbe sprachen, funktionierte keine von ihnen problemlos für mich (möglicherweise, weil ich ANT nicht verwende, gab mir maven build andere Fehler, die mich auf http://cwiki.apache.org/ verwiesen). Konfluenz / Anzeige / MAVEN / MojoExecutionException , und ich konnte auch nicht selbst herausfinden, was die signierten Gläser sind!)

Schließlich hat mir das geholfen

zip -d demoSampler.jar 'META-INF/*.SF' 'META-INF/*.RSA' 'META-INF/*SF'

Ratet mal, was aus meiner JAR-Datei entfernt wurde?!

deleting: META-INF/ECLIPSE_.SF 
deleting: META-INF/ECLIPSE_.RSA

Es scheint, dass das Problem für einige Eclipse-relevante Dateien relevant war.


4

Ich hatte das gleiche Problem gradlebeim Erstellen eines fetten Jar. Durch Aktualisieren der build.gradleDatei mit einer Ausschlusszeile wurde das Problem behoben.

jar {
    from {
        configurations.compile.collect {
            it.isDirectory() ? it : zipTree(it)
        }
    }
    exclude 'META-INF/*.RSA', 'META-INF/*.SF','META-INF/*.DSA'
    manifest {
        attributes 'Main-Class': 'com.test.Main'
    }
}

1
Ich habe tagelang debuggt, dies hat mein Problem mit dem fetten Glas gelöst.
Sysuser

Die Art und Weise, wie ich debuggt habe, besteht darin, das fette Glas in das Verzeichnis jmeter lib zu stellen. Wenn Sie das problematische JAR in lib / ext haben, ist dieses Problem nicht offensichtlich, sondern Sie erhalten einen Fehler wie den in stackoverflow.com/questions/37624187/…
sysuser

1
Ausschluss 'META-INF / *. RSA', 'META-INF / *. SF', 'META-INF / *. DSA' Dies fehlte, ein abhängiges Glas verursachte das Problem
Nirbhay Mishra

3

Für den Fall, dass Sie gradle verwenden, finden Sie hier eine vollständige farJar-Aufgabe:

version = '1.0'
//create a single Jar with all dependencies
task fatJar(type: Jar) {
    manifest {
        attributes 'Implementation-Title': 'Gradle Jar File Example',  
            'Implementation-Version': version,
            'Main-Class': 'com.example.main'
    }
    baseName = project.name + '-all'
    from { configurations.compile.collect { it.isDirectory() ? it : zipTree(it) } }
    exclude 'META-INF/*.RSA', 'META-INF/*.SF','META-INF/*.DSA' 
    with jar
}

2

Vergleichen Sie den Ordner META-INF im neuen Glas mit dem alten Glas (bevor Sie neue Bibliotheken hinzugefügt haben). Es ist möglich, dass es neue Dateien gibt. Wenn ja, können Sie sie entfernen. Es sollte helfen. Grüße, 999michal


2

Eine Strategie würde darin bestehen, ANT zu verwenden, um das Entfernen der Signatur aus jeder Jar-Datei zu vereinfachen. Es würde mit den folgenden Schritten fortfahren:

  1. Kopieren der Datei MANIFEST.MF in eine temporäre Datei
  2. Entfernen der Einträge Name und SHA aus der temporären Datei
  3. Erstellen einer temporären Jar-Datei mit dem temporären Manifest
  4. Entfernen des temporären Manifests
  5. Tauschen Sie die ursprüngliche Jar-Datei gegen die temporäre aus

Hier ist ein ANT-Makrodef , der die Arbeit erledigt :

<macrodef name="unsignjar" description="To unsign a specific Jar file">
    <attribute name="jarfile" 
        description="The jar file to unsign" />
    <sequential>
<!-- Copying to the temporary manifest file -->
        <copy toFile="@{jarFile}_MANIFEST.tmp">
            <resources>
                <zipentry zipfile="@{jarFile}" name="META-INF/MANIFEST.MF"/>
            </resources>
        </copy>
<!-- Removing the Name and SHA entries from the temporary file -->
        <replaceregexp file="@{jarFile}_MANIFEST.tmp" match="\nName:(.+?)\nSH" replace="SH" flags="gis" byline="false"/>
        <replaceregexp file="@{jarFile}_MANIFEST.tmp" match="SHA(.*)" replace="" flags="gis" byline="false"/>
<!-- Creating a temporary Jar file with the temporary manifest -->
        <jar jarfile="@{jarFile}.tmp"
            manifest="@{jarFile}_MANIFEST.tmp">
            <zipfileset src="@{jarFile}">
                <include name="**"/>
                <exclude name="META-INF/*.SF"/>
                <exclude name="META-INF/*.DSA"/>
                <exclude name="META-INF/*.RSA"/>
            </zipfileset>
        </jar>
<!-- Removing the temporary manifest -->
        <delete file="@{jarFile}_MANIFEST.tmp" />
<!-- Swapping the original Jar file with the temporary one -->
        <move file="@{jarFile}.tmp"
              tofile="@{jarFile}"
              overwrite="true" />
</sequential>

`

Die Definition kann dann in einer ANT-Aufgabe folgendermaßen aufgerufen werden:

<target name="unsignJar">
    <unsignjar jarFile="org.test.myjartounsign.jar" />
</target>

2

Fehler: Es ist ein JNI-Fehler aufgetreten. Überprüfen Sie Ihre Installation und versuchen Sie es erneut. Ausnahme im Thread "main" java.lang.SecurityException: Ungültiger Digest der Signaturdatei für Manifest-Hauptattribute unter sun.security.util.SignatureFileVerifier.processImpl (SignatureFileVerifier.java: 314) at sun.security.util.SignatureFileVerifier.process (SignatureFileVerifier.java:268) at java.util.jar.JarVerifier.processEntry (JarVerifier.java:316) at java.util.jar.JarVerifier.update (JarVerifier.java) : 228) unter java.util.jar.JarFile.initializeVerifier (JarFile.java:383) unter java.util.jar.JarFile.getInputStream (JarFile.java:450) unter sun.misc.URLClassPath $ JarLoader $ 2.getInputStream (URLClassPath .java: 977) bei sun.misc.Resource.cachedInputStream (Resource.java:77) bei sun.misc.Resource.getByteBuffer (Resource.java:160) unter java.net.URLClassLoader.defineClass (URLClassLoader.java:454) unter java.net.URLClassLoader.access $ 100 (URLClassLoader.java:73) unter java.net.URLClassLoader $ 1.run (URLClassLoader.java:368) um java.net.URLClassLoader $ 1.run (URLClassLoader.java:362) bei java.security.AccessController.doPrivileged (native Methode) bei java.net.URLClassLoader.findClass (URLClassLoader.java:361) bei java.lang.ClassLoader.loadC (ClassLoader.java:424) unter sun.misc.Launcher $ AppClassLoader.loadClass (Launcher.java:331) unter java.lang.ClassLoader.loadClass (ClassLoader.java:357) unter sun.launcher.LauncherHelper.checkAndLoadMain (LauncherHper. Java: 495)Führen Sie (URLClassLoader.java:368) unter java.net.URLClassLoader $ 1.run (URLClassLoader.java:362) unter java.security.AccessController.doPrivileged (native Methode) unter java.net.URLClassLoader.findClass (URLClassLoader.java:36 aus ) bei java.lang.ClassLoader.loadClass (ClassLoader.java:424) bei sun.misc.Launcher $ AppClassLoader.loadClass (Launcher.java:331) bei java.lang.ClassLoader.loadClass (ClassLoader.java:357) bei sun .launcher.LauncherHelper.checkAndLoadMain (LauncherHelper.java:495)Führen Sie (URLClassLoader.java:368) unter java.net.URLClassLoader $ 1.run (URLClassLoader.java:362) unter java.security.AccessController.doPrivileged (native Methode) unter java.net.URLClassLoader.findClass (URLClassLoader.java:36 aus ) bei java.lang.ClassLoader.loadClass (ClassLoader.java:424) bei sun.misc.Launcher $ AppClassLoader.loadClass (Launcher.java:331) bei java.lang.ClassLoader.loadClass (ClassLoader.java:357) bei sun .launcher.LauncherHelper.checkAndLoadMain (LauncherHelper.java:495)331) unter java.lang.ClassLoader.loadClass (ClassLoader.java:357) unter sun.launcher.LauncherHelper.checkAndLoadMain (LauncherHelper.java:495)331) unter java.lang.ClassLoader.loadClass (ClassLoader.java:357) unter sun.launcher.LauncherHelper.checkAndLoadMain (LauncherHelper.java:495)

Was mir geholfen hat (IntelliJ IDEA 2016.3): Datei -> Projektstruktur -> Artefakte -> JAR hinzufügen -> Hauptklasse auswählen -> Wählen Sie "In das Ausgabeverzeichnis kopieren und über Manifest verknüpfen" -> OK -> Übernehmen -> Erstellen - > Artefakte erstellen ... -> Erstellen


1

Es ist möglich, dass zwei verschiedene Unterzeichner den Java-Verstand durcheinander bringen.

Versuchen Sie, den META-INF-Ordner aus dem JAR zu entfernen, das Manifest hinzuzufügen und JAR erneut zu signieren. Dies hat mir geholfen: http://jehy.ru/articles/2013/12/13/invalid-signature-file-digest-for-manifest-main- Attribute /


1
+1 für den Link. Das Entfernen von META-INF * .RSA und META-INF * .SF aus den Gläsern, mit denen ich gearbeitet habe, löste die Probleme für mich. YMMV
KathyA.

1

Wenn Sie nach einer Fat JAR-Lösung suchen, ohne die Originalbibliotheken zu entpacken oder zu manipulieren, aber mit einem speziellen JAR-Klassenladeprogramm, schauen Sie sich mein Projekt hier an .

Haftungsausschluss: Ich habe den Code nicht geschrieben, sondern nur verpackt und auf Maven Central veröffentlicht und in meinem Read-Me beschrieben, wie er verwendet wird.

Ich persönlich verwende es zum Erstellen von ausführbaren JARs, die BouncyCastle-Abhängigkeiten enthalten. Vielleicht ist es auch für Sie nützlich.


0

Für diejenigen, die Probleme mit der akzeptierten Lösung haben, gibt es eine andere Möglichkeit, Ressourcen mit DontIncludeResourceTransformer aus dem schattierten Glas auszuschließen:

https://maven.apache.org/plugins/maven-shade-plugin/examples/resource-transformers.html#DontIncludeResourceTransformer

          <transformers>
            <transformer implementation="org.apache.maven.plugins.shade.resource.DontIncludeResourceTransformer">
                <resource>BC1024KE.DSA</resource>
            </transformer>
          </transformers>

Ab Shade 3.0 akzeptiert dieser Transformator eine Liste von Ressourcen. Vorher müssen Sie nur mehrere Transformatoren mit jeweils einer Ressource verwenden.


0

Dies ist mir in Intellij passiert, als ich unter dem Strich auf "Als Maven-Projekt hinzufügen" geklickt habe, als Intellij "Nicht verwaltete POM-Dateien gefunden" sagte. Inzwischen wurde bereits ein Ordner generiert. Es wurden also keine Änderungen vorgenommen.

Das Löschen des Ordners und das Ausführen des Programms lösten das Problem für mich. Der Ordner out wurde dann neu erstellt.

Siehe auch die Antwort von Little Fox. Der Fehler, den ich erhielt, war seinem sehr ähnlich.


-1

Ich hatte ein ähnliches Problem. Der Grund war, dass ich mit einem JDK mit einer anderen JRE als der Standard-JRE in meiner Windows-Box kompilierte.

Die Verwendung der richtigen java.exe hat mein Problem gelöst.


-2

Wenn Sie dies erhalten, wenn Sie versuchen, JAR-Dateien für ein Xamarin.Android-Bindungsprojekt wie folgt zu binden:

JARTOXML: Warnung J2XA006: Fehlender Klassenfehler wurde ausgelöst, während com.your.class reflektiert wurde: Ungültiger Digest der Signaturdatei für Manifest-Hauptattribute

Öffnen Sie einfach die JAR-Dateien mit Winzip und löschen Sie die Meta-Inf-Verzeichnisse. Wiederaufbau - Arbeit erledigt


1
Dies ist eine schreckliche Technik. Absolut schrecklich. Nehmen Sie die Korrekturen vor Ort vor und nehmen Sie keine Änderungen an eingehenden Gläsern vor
Sinisterrook
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.