Schau dir die folgende Java-Zeile an:
%Vor%Wenn ich dies in ein einfaches Testprogramm lege, läuft es ohne Probleme auf meinem Server. Wenn ich diese Zeile jedoch in einem Container verwende, bekomme ich
%Vor%In beiden Fällen wird die gleiche JDK-Installation verwendet.
Nachdem ich etwas gegoogelt habe, habe ich es geschafft, indem ich zwei Sachen gemacht habe:
sunjce_provider.jar von $JAVA_HOME/jre/lib/ext in das lib-Verzeichnis des Containers. Hinzufügen der folgenden Zeile zu meinem Code:
java.security.Security.addProvider(new com.sun.crypto.provider.SunJCE());
Genauer gesagt passiert mir das in einem Apache James Mailet, aber ich bin mir ziemlich sicher, dass dies zu tun hat mit JVM-Optionen. Hier ist das Startskript , das es verwendet .
Obwohl ich es am Ende zum Laufen gebracht habe, fühlt sich die Lösung zu gehackt an, um die richtige zu sein. Ich würde mich über eine Erklärung dessen, was vor sich geht, sowie über eine "richtige" Lösung freuen.
Verwandte Frage : Die Verwendung von Java crypto führt zu NoSuchAlgorithmException . In diesem Fall bin ich jedoch ziemlich sicher, dass der HmacSHA1-Algorithmus sofort unterstützt werden sollte. Als Beweis funktioniert das ohne Probleme in einem Testprogramm.
Das Startskript setzt java.ext.dirs auf seine eigenen Verzeichnisse (anwendungsspezifisch), unterlässt jedoch das Erweiterungsverzeichnis "normal" ( $JAVA_HOME/jre/lib/ext/ ), in dem sich sunjce_provider.jar befindet. Dies erklärt Ihren ersten Punkt (das Kopieren der Jar-Datei in das Lib-Verzeichnis macht es wieder sichtbar). Dies wird leicht reproduziert.
Was den zweiten Punkt angeht, denke ich, dass dies an der Richtliniendatei liegt, die das Startskript mit der Option -Djava.security.policy setzt. Ob einige Anbieter verfügbar sind oder nicht, hängt von den Richtliniendateien ab. Die Standardrichtliniendatei macht den SunJCE-Provider verfügbar, aber da die Startskripts eine nicht standardmäßige benutzerdefinierte Richtliniendatei erfordern, ist alles möglich. Ich schlage vor, dass Sie sich die Policy-Datei ansehen.
Zum Beispiel ist auf meinem System (Ubuntu Linux, mit Sun JVM 1.6.0_20 wie von Ubuntu verpackt) die Standard-Richtliniendatei in /etc/java-6-sun/security/java.security und enthält (unter anderem) die folgenden Zeilen:
definiert, welche Anbieter standardmäßig verfügbar sein sollen. Aufgrund Ihrer Symptome glaube ich, dass die benutzerdefinierte Richtliniendatei SunJCE nur dann verfügbar gemacht hat, wenn sie explizit registriert wurde (was verständlich ist, da das Startskript auch den Zugriff auf die Jar-Datei mit SunJCE entfernt hat).
Versuchen Sie, die Java-Version zu ändern
Ich habe die Ausnahme NoSuchAlgorithmException: "Unable to obtain JCA MAC algorithm 'HmacSHA512'" in der folgenden Java-Version erhalten:
Java-Version "1.8.0_131"
Java (TM) SE Laufzeitumgebung (Build 1.8.0_131-b11)
Java HotSpot (TM) 64-Bit-Server-VM (Build 25.131-b11, gemischter Modus)
Nach dem Ändern der JDK-Version wurde das folgende Problem behoben:
Java-Version "1.8.0_45"
Java (TM) SE Laufzeitumgebung (Build 1.8.0_45-b15)
Java HotSpot (TM) 64-Bit Server-VM (Build 25.45-b02, gemischter Modus)
Das erforderliche JAR für dieses Problem ist sunjce_provider.jar , möglicherweise ist es beschädigt.
Tags und Links java cryptography jce james