Im Allgemeinen sollte eine Anwendung so schnell unter dem Wrapper läufen, wie es eigenständig läuft. Here sind ein paar Dinge, die überprüft werden sollten.

Ein paar User haben bezüglich der Nachricht nachgefragt, die in ihrer wrapper.log-Datei auftaucht:

WrapperManager: ERROR - Unable to load the Wrapper's native library because none of the
WrapperManager:         following files:
WrapperManager:           wrapper-windows-x86-64.dll
WrapperManager:           wrapper.dll
WrapperManager:         could be located on the following java.library.path:
WrapperManager:           E:\myworkspace\tortoise\wrapper\wrapper_3.5.x\professional\bin\..\lib
WrapperManager:         Please see the documentation for the wrapper.java.library.path
WrapperManager:         configuration property.

Ausgabe, die das Problem beschreiben, sollten in der Konsole wie auch in der konfigurierten Logdatei angezeigt werden. Um eine mehr detaillierte Ausgabe zu bekommen, editieren Sie bitte die wrapper.conf-Datei und aktivieren Sie das Debugging durch das Auskommentieren der wrapper.debug-Eigenschaft. Dies wird eine sehr detaillierte Ausgabe für jeden Schritt im Prozess des Startens und Überwachens Ihrer Anwendung anzeigen.

Wenn Ihre Anwendung unter Nutzung des Wrappers abstürzt, aber ohne ihn funktioniert, dann ist es sehr wahrscheinlich, dass es ein Problem gibt bezüglichdessen, wie Sie Ihre wrapper.conf-Datei eingerichtet haben. Bitte werfen Sie einen genaueren Blick auf den Befehl in der Debug-Ausgabe, der genutzt wird, um Java zu starten. Es ist möglich, dass es einen Fehler im Classpath oder etwas Ähnliches gibt.

Es ist möglich, dass der Wrapper nicht in der Lage ist, den Speicherort der spezifizierten Wrapper-Konfigurationsdatei zu ermitteln, oder er ist nicht imstande, die konfigurierte Log-Datei aus bestimmten Gründen zu öffnen. In beiden Fällen wird der Wrapper die Ausgabe in eine Datei namens wrapper.log in dem gegenwärtigen Arbeitsverzeichnis loggen. Das gegenwärtige Arbeitsverzeichnis wird sehr wahrscheinlich das Verzeichnis sein, welches die Programmdatei enthält. Jedoch in einigen Fällen, wenn als Windows-Dienst ausgeführt, kann die wrapper.log-Datei auch in Ihrem Systemverzeichnis (WinNT\System32) untergebracht sein.

Wenn Sie System.exit() in Ihrer Anwendung aufrufen, dann wird der Wrapper dies abfangen und dann versuchen, die Anwendung ordnungsgemäß zu beenden. Wenn während des Beenden-Prozesses, Ihre Anwendung noch einmal System.exit() aufruft, dann wird der Aufruf auf unbestimmte Zeit blockiert, was bewirkt, dass Ihre Anwendung hängt. Es gibt auch Probleme beim Aufruf der destroy()-Methode auf einem AWT-Frame oder Fenster von innerhalb eines Shutdown-Hook-Threads. Bitte werfen Sie einen Blick in die wrapper.disable_shutdown_hook-Eigenschaft in der Konfigurationsübersicht bezüglich Details dazu, wie dieses Problem vermieden werden kann.

Das Problem ist, dass Sie womöglich die wrapper.java.command-Eigenschaft viel mehr in eine Batch-Datei einstellen möchten statt direkt in die java.exe-Datei. Wenn Sie einen Thread-Dump anfordern, wird das "BREAK" -Signal eher zum Prozess command.exe/shell gesendet als zum Java-Prozess. Es leitet dann das Signal an die JVM weiter, aber setzt auch eine interne Flag-Markierung, dass STRG-C gedrückt wurde. Wenn der Kindprozess, Java sich beendet, wird der User sofort gefragt, ob danach gewünscht wird, die Batch-Skript-Datei zu beenden oder fortzusetzen.

INFO   | jvm 1    | 2009/10/23 14:30:35 | WrapperManager Debug: Sent a packet STOPPED : 0
INFO   | jvm 1    | 2009/10/23 14:30:36 | Terminate batch job (Y/N)?
ERROR  | Wrapper  | 2009/10/23 14:30:56 | Shutdown failed: Timed out waiting for the JVM to terminate.
ERROR  | Wrapper  | 2009/10/23 14:30:56 | JVM did not exit on request, terminated
STATUS | Wrapper  | 2009/10/23 14:30:57 | <-- Wrapper Stopped

Wenn eine zusätzliche Weiterbearbeitung bevor oder nachdem die JVM gestartet wurde, notwendig wird, hat die Java Service Wrapper Professional Edition die Fähigkeit, genau dies zu tun:Wrapper-Ereigniskonfiguration

Dieses Problem ist ähnlich und verursacht durch den gleichen Grund wie der vorherig Erwähnte oben.

INFO   | jvm 1    | 2009/10/23 14:35:48 |  WrapperJNI Error: Unable to send BREAK event to JVM process: The parameter is incorrect. (0x57)

Wenn eine zusätzliche Weiterbearbeitung bevor oder nachdem die JVM gestartet wurde, notwendig wird, hat die Java Service Wrapper Professional Edition die Fähigkeit, genau dies zu tun:Wrapper-Ereigniskonfiguration

INFO   | jvm 1    | 2011/01/06 17:23:05 | ERROR: Error installing to Configured: name=ServiceBindingManager state=Configured
INFO   | jvm 1    | 2011/01/06 17:23:05 | java.lang.Exception: Error calling callback JMXRegistrationAdvice for target context ServiceBindingManager
...

JBoss mit Version 6 benutzt intern eine MBeanServer Factory, die auf org.jboss.system.server.jmx.MBeanServerBuilderImpl basiert ist, jedoch ist diese inkompatibel zu der voreingestellten JVM MBeanServerBuilder (javax.management.MBeanServerBuilder).

Es gibt 2 verfügbare Optionen, um dies zu lösen. Erste Option ist, die Wrapper MBeans zu deaktivieren davon, registriert zu werden. Für diese Option sehen Sie bitte in die Integrationsmethode 1. Die zweite Option ist die, der JVM zu sagen, die MBeanServer Factory zu nutzen, welche JBoss auch nutzt. Mehr Information bezüglich dies, kann auf der folgenden Seite gefunden werden JMX-Seite.

wrapper  | A signature was found in "C:\wrapper-windows-x86-32-3.5.7-pro\bin\wra
pper.exe", but checksum failed: (Errorcode: 0x800b010a) 
A certificate chain could not be built to a trusted root authority. (0x800b010a)
wrapper  |   Signer Certificate:
wrapper  |     Serial Number: 
wrapper  |       00 97 06 fe b5 6e 56 cc cb 66 3a bb 55 a7 a0 e4 76 
wrapper  |     Issuer Name: UTN-USERFirst-Object
wrapper  |     Subject Name: Tanuki Software Ltd.
wrapper  |   TimeStamp Certificate:
wrapper  |     Serial Number: 
wrapper  |       47 8a 8e fb 59 e1 d8 3f 0c e1 42 d2 a2 87 07 be 
wrapper  |     Issuer Name: UTN-USERFirst-Object
wrapper  |     Subject Name: COMODO Time Stamping Signer
wrapper  |     Date of TimeStamp : 2010/12/19 22:32
wrapper  | The Wrapper will shutdown!

Beginnend mit der Wrapper Version 3.5.7, nutzen die Wrapper-Programmdateien (z.B. wrapper.exe, wrapperW.exe und wrapper.dll) von allen Wrapper-Editionen (Community, Standard, Professional) nutzen Codesigning, um die Dateiherkunft, dass sie von Tanuki Software stammt, zu überprüfen. Wenn irgendein Problem erkannt wurde, wird der Wrapper sich beenden.

Beginnend mit der Wrapper-Version 3.5.28, wird der Wrapper mit einem SHA-2-Zertifikat signiert, welche höhere Sicherheit als der vorherig genutzte SHA-1-Algorithmus ermöglicht.Die Entscheidung, das Zertifikat zu ändern, wurde in Compliance mit Microsofts SHA-1 deprecation plan gemacht, der erklärt, dass Windows 7 und aktueller SHA-1 nach dem 1.Januar 2016 nicht mehr unterstützen.

Der oben genannte Fehler tritt auf, wenn die Zertifikate, die von unserem Gegenzeichner 'Comodo' zur Verfügung gestellt werden, nicht korrekt installiert wurden.

Die Zertifikate sollten in einem store installiert werden, welcher von dem Konto unter den der Wrapper läuft, erreichbar ist. Wenn der Wrapper als eine Konsolenanwendung ausgeführt wird, mag dies der aktuelle User sein. Wenn als Dienst ausgeführt, sollte er von dem genutzten Dienstkonto erreichbar sein. Eine Alternative zu diesem ist es, das Zertifikat auf der lokalen Maschine zu installieren, so dass es in beiden Modi verfügbar ist.

Die installierten Zertifikate können von dem Windows Zertifikatmanager certmgr.msc (für den aktuellen User) oder von mmc (für jeden beliebigen User)überprüft werden.

Um die Zertifikate von einem spezifischen Konto zu verwalten, starten Sie launch 'mmc' vom Windows Ausführen-Suchfeld. Im Dateimenü klicken Sie auf 'Add/Remove Snap-in' und doppelklicken Sie dann auf 'Certificates'. Sie können dann wählen zwischen entweder Zertifikate des aktuellen Users, eines Dienstkontos oder des Computerkontos verwalten. Im Fall eines Dienstkontos wird eine Liste erscheinen mit allen auf dem Computer installierten Diensten. Sie sollten den Namen auswählen, der genutzt wird, wenn der Wrapper als ein Dienst installiert wird.

Um die Zertifikate für den aktuellen User oder den lokalen Computer zu installieren, können Sie einfach die .crt-Datei ausführen und den folgenden Installationsschritte folgen. Um sie zu einem Dienstuser zu importieren, benutzen Sie bitte 'mmc', fügen das Snap-In, wie oben beschrieben, hinzu. Wählen Sie dann einen beliebigen Speicherplatz (markiert mit einem Ordnersymbol) unterhalb dieses Snap-In auf der linken Seite, und im Menü klicken Sie auf "Aktion> Alle Aufgaben> Importieren" (Wählen Sie die Option "Den Zertifikatspeicher automatisch anhand des Zertifikatstyps auswählen").

Wenn der Fehler immer noch auftritt, kann dies bedeuten, dass die lokalen Sicherheitsrichtlinien des Servers zu streng sind, um die Überprüfung der Zertifikate zu erlauben. Diese Einstellungen können in der lokalen Sicherheitsrichtlinie des Servers gefunden werden. Starten Sie bitte 'secpol.msc' vom Windows Ausführen-Suchfeld, klicken Sie auf "Public Key Policies", dann auf "Certificate Path Validation Settings". Stellen Sie bitte sicher, dass auf der Registerkarte 'Stores' "Third-Party Root CAs and Enterprise Root CAs" markiert ist, wenn die Richtlinieneinstellungen definiert wurden. Wenn dies so nicht aktiv gesetzt ist/kann, wäre eine andere Option, das "UTN-USERFirst-Object Certificate" von dem "Third Party Root CA"-Verzeichnis in das "Trusted Root Certificate Authorities"-Verzeichnis zu verschieben.

In der Wrapper-Version 3.5.8, wird sich der Wrapper nur beenden, wenn der Grund, dass die Signatur nicht überprüft wurde, direkt vom Wrapper verursacht wurde, und nicht durch den Gegenzeichner.

In der Wrapper-Version 3.5.7 gab es einen Bug, der möglicherweise eine Zugriffsverletzung verursachte, wenn die Signaturüberprüfung fehlschlug und der Wrapper versuchte, einen Fehler anzuzeigen.

Seit Wrapper-Version 3.5.34 sind die Wrapper-Binärdateien doppelt mit SHA-1- und SHA-2-Hash-Algorithmen signiert, um eine stärkere Überprüfung auf Betriebssystemebene zu ermöglichen. Um Algorithmen und Zeitstempel zu überprüfen, klicken Sie mit der rechten Maustaste auf die Binärdateien und öffnen Sie das Fenster "Eigenschaften" des Kontextmenüs, dann wählen Sie die Registerkarte "Digitale Signaturen":

Beachten Sie, dass der SHA-256-Hash-Algorithmus nicht in alten Windows-Versionen angezeigt wird, in denen dieser Algorithmus nicht unterstützt wird. Microsoft veröffentlichte ein Update für Windows 7 und Windows Server 2008 R2, um die Unterstützung für SHA-2 hinzuzufügen. Wenn dieses Update vorhanden ist, können Sie den SHA-2-Hash überprüfen, andernfalls können Sie nur den SHA-1-Hash verifizieren. Neuere Windows-Versionen benötigen dieses Update nicht, da sie bereits SHA-256 unterstützen, wohingegen ältere Versionen (Windows XP, Vista, Windows Server 2008) nur SHA-1-Hashes überprüfen können.

Sie können bestätigen, dass eine digitale Signatur gültig ist, indem Sie in der Signaturliste darauf klicken:

Schließlich sollte berücksichtigt werden, dass Windows XP SP2 und älter, sowie auch Windows Server 2003, SHA-2 und das neue Zertifikat auf diesen Plattformen nicht verwendet werden. Die Programmdateien, die für Windows Itanium zur Verfügung gestellt werden, werden nicht mehr signiert.

Der Wrapper selbst versucht nicht, auf den Comodo- oder andere Server zuzugreifen, aber beginnend mit der Wrapper-Version 3.5.7 werden die Programmdateien mit einem Comodo-Zertifikat signiert. Dies ist wichtig, um das Betriebssystem darin zu unterstützen, zu überprüfen, dass die Wrapper-Programmdateien wirklich von Tanuki Software stammen.

Wenn Windows versucht, eine signierte Programmdatei zu starten, wird es zuerst die Programmdatei überprüfen, um sicherzustellen, dass diese mit der Signatur übereinstimmt, um sich zu vergewissern, dass die Programmdatei nicht manipuliert wurde. Normalerweise müsste das Comodo-Zertifikat überprüfen, dass die Programmdatei auf einer Windows-Maschine existiert, aber in einigen Fällen, muss das Betriebssystem, sich mit dem Internet verbinden und diese von einem bekannten Ort herunterladen. Die Verbindung erfolgt, wenn der Wrapper aufgerufen wird, aber bevor er wirklich gestartet wird. Es kann jedoch den Anschein haben, als ob der Wrapper die Verbindung herstellt. Wir bekamen Mitteilungen von folgenden Servern, dass auf diese Art auf sie zugegriffen wurde : ocsp.comodoca.com, a125-56.204-123.deploy.akamaitechnologies.com (Der IP-Anteil der akamai-Server variiert je nach Anfrage)

Wenn dies irgendein Problem mit Kunden verursachen würde, dann wäre die eine Option für Standard und Professional Editionen, Ihre Wrapper-Programmdatei anzupassen, da dieser Prozess die Signatur entfernt. Dies wird jedoch natürlich auch die Fähigkeit des Betriebssystems, die Echtheit der Programmdatei zu überprüfen, entfernen.

Der Wrapper selbst legt keinerlei Beschränkungen auf bezüglich der Zahl der Wrapper-Instanzen, die unter Windows zur gleichen Zeit ausgeführt werden können, aber beide, der Wrapper und insbesondere Java verbraucht diverse Ressourcen, die Beschränkungen dbzgl. auferlegen können, wie viele Instanzen auf einem vorhandenen System ausgeführt werden können. Die Ressource, die am häufigsten Probleme verursachen kann, ist der Desktop Heap. Sehen Sie bitte auf der Seite Solving Desktop Heap Problems für mehr Information.

Java 9 führt mehrere Optionen ein (z.B. --module-path oder --add-modules), die mit einem Argument angegeben werden müssen. Normalerweise wird das Argument durch ein Leerzeichen vom Optionsnamen getrennt, aber jeder Leerraum innerhalb der Werte der wrapper.java.additional.<n> Eigenschaften wird als Teil des Argumentwerts und nicht als Trennzeichen interpretiert. Eine Lösung besteht darin, den Optionsnamen und das Argument durch ein Gleichheitszeichen (=) anstelle eines Leerzeichens zu trennen.

wrapper.java.additional.1=--add-modules=MODULE1,MODULE2

Beachten Sie, dass dies nur mit langen Optionen funktioniert (solche, die mit '--' beginnen) und nicht mit ihren kurzen Aliasen. Zum Beispiel ist '-p=<PATH>' nicht erlaubt ('-p' ist ein Alias ??von '--module-path').

Eine andere Lösung, bei der Sie sowohl Leerzeichen als auch kurze Aliase verwenden können, ist die Verwendung der Umgebungsvariable JDK_JAVA_OPTIONS. Der Inhalt dieser Variablen wird von der JVM den Optionen der Befehlszeile hinzugefügt. Sie können es mithilfe der folgenden Syntax aus der Wrapper-Konfigurationsdatei heraus festlegen:

set.JDK_JAVA_OPTIONS=--add-modules MODULE1,MODULE2

Beachten Sie jedoch, dass Sie den Inhalt von JDK_JAVA_OPTIONS nicht visualisieren können, wenn Sie die Java-Befehlszeile wrapper.java.command.loglevel Eigenschaft) anzeigen, da diese von der JVM nur beim Start geparst wird.

Weitere Informationen zu den Long-Optionen und der Variablen JDK_JAVA_OPTIONS finden Sie auf der Website von Oracle.