Standardmäßig werden die Windows-Dienste als SYSTEM-User ausgeführt. Das Problem ist, dass der SYSTEM-User keinen Zugang zu den Netzwerkressourcen hat. Wenn Ihre Anwendung als Windows-Dienst gut läuft, dann ist das Erste, was wir versuchen können, Ihren Dienst mit dem User auszuführen, mit dem Sie angemeldet waren, als Sie diese als eine Konsolenanwendung ausgeführt haben.

Um dies zu tun,

• deinstallieren Sie bitte zuerst Ihre Anwendung, wenn diese gegenwärtig als ein Windows-Dienst installiert ist.
• Dann editieren Sie die wrapper.conf-Datei, legen die wrapper.ntservice.account und wrapper.ntservice.password Eigenschaften fest.
• Als nächstes installieren Sie Ihren Dienst neu und starten diesen.

Der Dienst wird jetzt in der gleichen Umgebung laufen, in der eine Konsolenanwendung läuft, so dass jetzt alles korrekt funktionieren sollte.

Abhängig von Ihren Sicherheitsanforderungen kann es sein, dass Sie einen neuen User für diesen Dienst erstellen und konfigurieren möchten.

Es wurde festgestellt, dass auf ein paar Systemen Laufwerke, denen ein Festplattenbuchstabe zugeordnet wurde (Buchstabe zeigt eine Festplatte an),nach einem System-Neustart nicht immer zugreifbar sind - bis sich ein wirklicher Nutzer schliesslich einloggt und mit dem Laufwerk verbindet. Der Workaround ist, die UNC-Syntax (Gesamtpfadname inklusive eines Rechnernamens) zu verwenden, um statt den zugeordneten Laufwerksnamen zu nutzen, sich direkt auf das Laufwerk zu beziehen.

//host/share/path

Wenn ich einen Thread-Dump durch Drücken der Taste Strg-Pause,Strg-\, oder über die API anfordere, erhalte ich die folgende Log-Nachricht und die JVM wird neu gestartet:

wrapper  | JVM beendete sich unerwarteterweise.

Stellen Sie bitte sicher, dass der -Xrs Flag beim Starten der JVM nicht gesetzt ist. Dieses Flag ist in einigen Umgebungen, wenn Sie Java ohne den Wrapper einsetzen, sinnvoll, aber es beeinträchtigt die Fähigkeit des Wrappers, auf verschiedene Systemsignale zu reagieren.

Um den Wrapper und damit auch seine JVM darüber zu informieren, Systemsignale zu ignorieren, nutzen Sie stattdessen die Eigenschaft wrapper.ignore_signals. Stellen Sie bitte sicher, dass Sie zuerst die Dokumentation gelesen haben.

Einige Nutzer berichteten von Problemen beim Versuch, Ihre COM-Anwendungen mit dem Wrapper zum Laufen zu bringen. Die Anwendung läuft problemlos unabhängig als eine Standalone-Anwendung, aber wenn diese unter dem Wrapper läuft, treten folgende Fehler auf:

Caught java.lang.NullPointerException: name can't be null while loading driver com.sun.comm.Win32Driver

Die COM API erfordert, dsss zwei Dateien verfügbar sind. Die win32com.dll Datei im library-Verzeichnis, und eine javax.comm.properties Datei, die sich in dem lib-Unterverzeichnis von dem Verzeichnis befindet, welches als Ergebnis von der Eigenschaft System.getProperty("java.home") zurückgegeben wird.

Probleme können auftreten, wenn Ihre wrapper.conf so konfiguriert wurde, dass Sie eine andere JVM benutzen als diese, welche durch Ihre JAVA_HOME-Umgebungsvariable festgelegt wurde. Sie können sicherstellen, dass Sie die korrekte JVM benutzen, indem Sie die folgende Eigenschaft wrapper.java.command in Ihrer wrapper.conf Datei festlegen.

wrapper.java.command=%JAVA_HOME%/bin/java

Der einzige Unterschied zwischen der Art, wie Ihre Anwendung unter dem Wrapper läuft und der Art, wie sie läuft, bevor sie in diesen integriert wurde, ist der, dass zuvor die Main-Methode Ihrer Anwendung direkt durch die JVM beim Hochstarten aufgerufen wurde. Wenn wir jetzt annehmen, dass Sie die Helper-Klassen WrapperSimpleApp oder WrapperStartStopApp benutzen, wird die JVM zuerst die Main-Methode der Klasse aufrufen und danach, nachdem der Wrapper initialisiert wurde, wird es die Main-Methode Ihrer Anwendung aufrufen.

Dies kann ein paar Probleme verursachen, wenn ein Security Manager in Benutzung ist. Der Grund ist der, dass der Java Security Manager einen Call Stack durchsucht, um sicherzustellen, dass jede Klasse und Methode authorisiert wurde, den geschützten Programmcode aufzurufen, bevor Zugang gewährt wird. Wenn die Klassen des Wrappers in Ihrem Call-Stack existieren und ihnen keine besonderen Rechte gegeben wurden, dann erhalten Sie einen Sicherheitsfehler.

Versuchen Sie bitte wrapper.jar Berechtigungen zu geben, indem Sie das Folgende Ihrer Sicherheits-Datei hinzufügen. Dies löst gewöhnlich so ein Problem.

// Give Wrapper classes full permissions
grant codeBase "file:../lib/wrapper.jar" {
    permission java.security.AllPermission;
};

Einige Javadienst-Anwendungen haben ein Problem mit dem Javaprozess, der sich beendet, wann immer sich ein Benutzer von Windows abmeldet. Wrapper hat seit seinem ersten Release damit gut umgehen können.

Die Java-Seite des Wrappers erfordert eine native Bibliothek: Windows: wrapper.dll, Linux/UNIX: libwrapper.soum diese Arbeit zu erledigen. Die native Bibliothek ist für das Abfangen und die korrekte Bearbeitung aller an den JVM-Prozess gesendeten Systemsignale, verantwortlich. Ein Java-Anwendung kann mit diesen Signalen umgehen, indem die Methode controlEvent in die WrapperListener-Schnittstelle implementiert wird.

Wenn Sie Probleme mit Ihrer JVM haben, nachdem diese bei der Abmeldung eines Users durch den Wrapper neu gestartet wurde, überprüfen Sie bitte, ob die Bibliothek geladen wurde. Wenn dies nicht der Fall ist, erhalten Sie in der JVM-Ausgabe während der WrapperManager-Initialisierung eine Warnmeldung.

Sie können im Abschnitt Beispiele der Dokumentation Beispiele erhalten bezüglich dem, was passiert, wenn der User sich - während der Wrapper als Konsolenanwendung und als Dienst läuft - abmeldet.

Auf Windows-Systemen kann die Priorität durch das Festlegen der wrapper.ntservice.process_priority-Eigenschaft in der wrapper.conf-Datei eingestellt werden. Besuchen Sie bitte die Konfigurationsübersicht bezüglich mehr Details.

Auf UNIX-Systemen ist die empfohlene Methode für das Festlegen der Prioritätsstufe der "nice"-Befehl in Ihren Shell-Skripten, wenn Sie den Wrapper starten. Die Beispielskripte, die mit dem Wrapper ausgeliefert werdern, zeigen, wie dies geht. Sehen Sie unter "man nice" oder "info nice", um Details darüber zu erhalten, wie "nice" genutzt werden kann.

Standardmäßig legt der Wrapper das JVM-Benutzerverzeichnis entweder auf das Standardverzeichnis der wrapper.exe-Datei unter Windows oder des Wrapper-Shellskripts auf UNIX-Systemen fest. Dies wird getan, damit zuverlässig auf relative Verzeichnisangaben innerhalb Ihrer Anwendung zugegriffen werden kann. Normalerweise wäre dies nicht möglich, da das Benutzerverzeichnis meist davon abhängt, von wo aus die JVM gestartet wird.

Relative Pfadangaben machen es sehr einfach, eine Anwendung zu installieren, als ob sie gewöhnlich in irgendein Verzeichnis entzippt und zuverlässig ausgeführt würden.

Es gibt einige Fälle, in denen es notwendig ist, das Benutzerverzeichnis auf einen anderen Ort als gewöhnlich einzustellen. Dies wird durch das Setzen der wrapper.working.dir-Eigenschaft erledigt.

Beim Ausführen von mehreren Kopien des Wrappers unter Windows ist es nicht einfach festzustellen, welche Anwendung welche im Task-Manager ist, weil alle darin als wrapper.exe und java.exe erscheinen. Für den Wrapper ist es leider nicht möglich, ein Feature zu implementieren, um diese Namen zu ändern, weil Windows dies aufgrund von sicherheitsrelevanten Gründen nicht erlaubt.

Der Workaround kostet gewisse Anstrengungen, funktioniert aber gut.

• Benennen Sie die wrapper.exe-Datei in wrapper-myapp.exe um.
• Dann ändern Sie die Batch-Dateien so ab, dass diese die neue Datei wrapper-myapp.exe verwenden.
• Für den Javaprozess müssen Sie das Gleiche tun. Gehen Sie bitte in das %JAVA_HOME%/bin-Verzeichnis und kopieren Sie einfach java.exe und benennen Sie die Kopie als java-myapp.exe.
• Dann ändern Sie die wrapper.conf-Datei, so dass die neue Datei java-myapp.exe genutzt wird.

Wenn Sie nun in den Windows Task Manager sehen, wird es einfach sein, zu unterscheiden, welche Datei welche ist.

Beachten Sie, dass Sie auch die wrapper.pidfile und die wrapper.java.pidfile-Eigenschaften in der wrapper.conf-Datei einstellen können. Diese erstellen Dateien, die Pids enthalten. Diese Pids können dann mit diesen verglichen werden, die im Task-Manager angezeigt werden. Beachten Sie, dass Sie den Task Manager konfigurieren müssen, um die Prozess-IDs anzuzeigen.

Unter Windows wird dies durch das Festlegen der wrapper.ntservice.account Eigenschaft getan. Stellen Sie sicher, die Dokumentation komplett zu lesen und dann den Dienst neu zu installieren.

Unter UNIX wird dies durch das Bestimmen der RUN_AS_USER -Variable des Wrappers-Shellskripts festgelegt src/bin/App.sh.in. Wenn Sie den Konsolen-Befehl ausführen, wird der Wrapper mit dem gegenwärtigen User-Konto ausgeführt. Wenn Sie jedoch den start-Befehl ausführen, ändert sich das User-Konto jedoch zum gegenwärtig genutzten User-Konto und startet dann den Wrapper. Dies bedeutet, dass der aktuelle User die Berechtigung braucht, Users zu ändern.

Wenn eine Java-Anwendung als ein Windows-Dienst ausgeführt wird, läuft es tatsächlich nicht im gleichen Sitzungskontext, wie die des Users, der VisualVM gestartet hat. Daher kann VisualVM die Java-Anwendung standardmässig nicht finden.

Bis Windows XP machten die laxen Sicherheitsrichtlinien für Windows Dienste es möglich, dies ziemlich einfach mit folgenden Schritten zu lösen:

Zum Zeitpunkt, wenn die JVM gestartet wird, schreibt die JVM ihre Prozess- und Hook-Information an die Stelle, die von der Umgebungsvariable %TMP% bestimmt wurde. Bitte beachten Sie, dass einige Umgebungsvariablen (inklusive dieser) für jeden User unterschiedlich festgelegt wurden. So die Kontexte, in denen Ihr Dienst und VisualVM laufen müssen den gleichen Wert für diese Umgebungsvariable nutzen.

set.TMP=C:\tmp

Nachdem dies getan ist, starten Sie bitte den Dienst neu. Starten Sie nun eine Konsole und setzen Sie die TMP-Umgebungsvariable auf den gleichen Wert, den Sie in der Konfigurationsdatei angegeben haben:

set TMP=C:\tmp
C:\Program Files\...\jvisualvm.exe

VisualVM sollte nun in der Lage sein, den Javaprozess aufzulisten.

Während das oben Genannte für Windows-Versionen bis Windows XP zutrifft, werden Windows Vista/7 (und neuere Versionen) dies wahrscheinlich aufgrund von strengeren Sicherheitsmassnahmen nicht mehr zulassen. So ist der einzige Weg, dies zu lösen, die JMX Remote Monitoring Einstellungen (dies setzt mindestens Java 1.5 voraus) zu benutzen.

wrapper.java.additional.N=-Dcom.sun.management.jmxremote.port=XXXX
wrapper.java.additional.N=-Dcom.sun.management.jmxremote.ssl=false
wrapper.java.additional.N=-Dcom.sun.management.jmxremote.authenticate=false

Bitte benutzen Sie ungenutzte Zahlen für 'N' mit der wrapper.java.additional.<n> Eigenschaft und ersetzen Sie 'XXXX' durch eine ungenutzte Port-NummerZahl Ihrer Maschine. Innerhalb VisualVM wählen Sie bitte "File"-> "Add JMX Connection". Im Feld "Connection" geben Sie bitte "localhost:XXXX" ein (XXXX ist der Port, den Sie in der conf-Datei zugewiesen haben).

In bestimmten Umgebungen, in denen virtuelle Maschinen mit Automatisierungstools ständig gelöscht und erstellt werden, hört der Wrapper auf zu funktionieren, sobald die HostId (die auf die MAC-Adresse basiert) unterschiedlich zu der im Serverlizenzschlüssel gesetzten ist. In diesem Fall sollte der Lizenzeigentümer den Lizenzschlüssel manuell zurücksetzen, was den eigenständigen Vorgang der Erstellung von virtuellen Maschinen unterbricht. Abhängig vom Virtualiserungstool, welches Sie einsetzen, ist es möglich, eine feste MAC-Adresse für virtuelle Maschinen festzulegen. Indem Sie stets die gleiche MAC-Adresse benutzen, können Sie sicher sein, dass der Wrapper ohne Lizenzschlüsselfehler startet.

Bitte beziehen Sie sich auf folgende Dokumentation:

• VMware
• VirtualBox
• AWS