Setzen Sie externe jars in die Umgebungsvariable JAVA_HOME/lib/ext-Verzeichnis eine schlechte Sache?
Haben wir eine Anwendung, die läuft in einem JRE-Umgebung. Die Anwendung nutzt einige externe jar-und wir setzen Sie in die Umgebungsvariable JAVA_HOME/lib/ext Ordner. Dies hat für uns gearbeitet, für Jahre, aber vor kurzem einen neuen Programmierer, unser team und scheint betonten, dass dies ist, wie einige eine schlechte Sache zu tun. Ich kann nicht verstehen, warum und ich versuche zu tun, einige der Forschung, bevor ich weiter Graben mit diesem Entwickler. Gibt es etwas, was fehlt mir hier?
- Geben Sie ihm eine Gehaltserhöhung, oder zumindest einen bonus. Nicht in Ihren Händen, sprechen mit den Managern. Ernst.
Schreibe einen Kommentar
Du musst angemeldet sein, um einen Kommentar abzugeben.
Ja - es ist eine schlechte Sache. Denken Sie daran: die Anwendung hängt von der JRE und einige extra Gläser. Was ist, wenn Sie ein update der JRE? Dann Sie daran denken müssen, kopieren Sie die Dateien in die neue JRE. Was, wenn Sie brauchen, um die Einrichtung der Anwendung auf ein neues system? Kopieren Sie nun die Applikation aus, und dann denken Sie auch an eine Kopie der externen jars in den JRE auf dem betreffenden system.
Beide dieser Probleme würde nicht ein Problem sein, überhaupt, wenn Sie nur Verpacken Sie die Anwendung korrekt zusammen mit den externen jars, die es braucht. Wenn Sie nicht sehen, dann vielleicht es ist nicht ein Problem überhaupt. Aber man sollte doch dankbar sein für den neuen Mann für das teilen seine Meinung.
Zusätzlich zu der Antwort von weiji (Verpackung und upgrades auf neue JVM-Versionen), gibt es andere Risiken.
Wenn Sie security manager in Ihren Anwendungen, die die Bibliotheken in ext oft viel mehr Funktionen standardmäßig behandelt werden, ähnlich wie die system-Bibliotheken. Sie müssen sicher sein, dass Sie Vertrauen können, im Sinne der Durchsetzung der Sicherheitsregeln, die diese Klassen. Haben die Autoren denken, durch was Sie waren auszusetzen, richtig? Wenn diese Klassen nicht benutzen, access control, um den Sicherheitskontext ändern, dann brauchen Sie nicht zu kümmern, aber wissen Sie, wenn Sie tun oder nicht tun (z.B. eine Methode, die den Zugriff auf eine Datei und verwendet AccessController, gilt es sicherzustellen, dass der Anrufer hat die richtige Datei-Berechtigungen?)
Können Sie alle Ihre Anwendungen verwenden die exakt gleichen version der Bibliothek? Was passiert, wenn Sie müssen, aktualisieren Sie die Bibliothek (nicht nur die JVM)? Sie brechen alle Ihre Anwendungen? Sie müssen mal testen alles. Die Bibliotheken in ext geladen werden von der extension class loader die, aufgrund der Eltern-delegation, hat einen höheren Rang als die normalen (d.h. CLASSPATH) Lader, so sind diese garantiert für Ihre Anwendung eingesetzt werden und es gibt keine Möglichkeit für eine einzelne Anwendung zu überschreiben, die Bibliothek in ext mit einer anderen version.
Wenn Sie möchten, teilen die Bibliotheken für Ihre Anwendungen, warum nicht stattdessen bieten Sie eine separate Ordner von gemeinsamen Bibliotheken, die Anwendungen können individuell konfiguriert werden (CLASSPATH) zu verweisen. Dann, wenn Sie Probleme mit einer Anwendung und einer Bibliothek können Sie wechseln Sie zu einer anderen version der Bibliotheken oder einfach nur für das eine, steckte es früher in den CLASSPATH (falls das funktioniert, müssen Sie dies testen, auch wie es andere Abhängigkeitsprobleme). Dies ermöglicht es Ihnen, mehr der individuellen Kontrolle für jede Anwendung. Aber dann, die Bündelung aller benötigten Bibliotheken mit Ihrer Anwendung ist die sicherste, da können Sie testen und roll-out-Bibliothek-upgrades für einzelne Anwendungen.
Es sieht wie JEP-220 angeblich veralteten dieses Verhalten mit beliebigen Mittel, um "eventuell ersetzen Sie es" mit einem anderen Verhalten.
-XX:+CheckEndorsedAndExtDirsBefehlszeile-option ist eine weitere nützliche option ist zu prüfen, ob Anwendungen, die auf JDK 8 hängt sich auf dieses feature.