Par défaut, les services Windows s'exécutent sous l'utilisateur SYSTEM. Le problème est que l'utilisateur SYSTEM n'a pas accès aux ressources réseau. Si votre application fonctionne correctement lorsqu'elle s'exécute en tant que service Windows, la première chose à essayer est d'exécuter votre service sous l'utilisateur avec lequel vous étiez connecté lorsque vous l'exécutiez en tant qu'application console.

Pour ce faire,

• Désinstallez d'abord votre application si elle est actuellement installée en tant que service Windows.
• Modifiez ensuite le fichier wrapper.conf, en définissant les propriétés wrapper.ntservice.account et wrapper.ntservice.password.
• Réinstallez ensuite et démarrez votre service.

Le service s'exécutera désormais dans le même environnement que lorsqu'il était exécuté en tant qu'application console, tout devrait donc maintenant fonctionner correctement.

Selon vos exigences de sécurité, vous souhaiterez peut-être créer et configurer un nouvel utilisateur spécialement pour le service.

Sur certains systèmes, les lecteurs mappés à une lettre de lecteur (lettre de l'alphabet indiquant un lecteur) ne sont pas toujours accessibles au redémarrage du système tant qu'un utilisateur réel ne s'est pas réellement connecté et n'a pas établi la connexion au lecteur. La solution de contournement consiste à utiliser la syntaxe UNC (chemin complet incluant un nom de machine) pour référencer le lecteur directement plutôt que d'utiliser la lettre de lecteur mappée.

//host/share/path

Lorsque je demande un vidage de threads en appuyant sur CTRL-BREAK, CTRL-\, ou via l'API, j'obtiens le message suivant dans le journal et la JVM est redémarrée :

wrapper  | JVM exited unexpectedly.

Veuillez vous assurer que vous n'avez pas spécifié l'indicateur -Xrs lors du lancement de la JVM. Cet indicateur est utile dans certains environnements lors de l'utilisation de Java sans le Wrapper, mais il compromet la capacité du Wrapper à répondre aux différents signaux système.

Pour indiquer au Wrapper et donc à sa JVM d'ignorer les signaux système, utilisez plutôt la propriété wrapper.ignore_signals. Assurez-vous d'avoir d'abord lu la documentation.

Certains utilisateurs ont signalé des problèmes lorsqu'ils tentaient de faire fonctionner leurs applications COM avec le Wrapper. L'application fonctionne correctement de manière autonome, mais lorsqu'elle est exécutée sous le Wrapper, des erreurs comme les suivantes sont générées :

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

L'API COM nécessite que deux fichiers soient disponibles. Le fichier win32com.dll dans le chemin de bibliothèque, et un fichier javax.comm.properties situé dans un sous-répertoire lib du répertoire renvoyé par System.getProperty("java.home").

Des problèmes surviennent si votre wrapper.conf a configuré l'utilisation d'une JVM différente de celle spécifiée par votre variable d'environnement JAVA_HOME. Vous pouvez vous assurer d'utiliser la JVM correcte en spécifiant la propriété suivante wrapper.java.command dans votre fichier wrapper.conf.

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

La seule différence entre la façon dont votre application s'exécute sous le Wrapper et la façon dont elle s'exécutait avant d'être intégrée est qu'auparavant, la méthode main de votre application était appelée directement par la JVM au démarrage. Désormais, en supposant que vous utilisez les classes d'aide WrapperSimpleApp ou WrapperStartStopApp, la JVM appelle d'abord la méthode main de cette classe, puis, une fois le Wrapper initialisé, elle appelle la méthode main de votre application.

Cela peut provoquer des problèmes lorsqu'un gestionnaire de sécurité est utilisé. La raison est que le gestionnaire de sécurité Java parcourt la pile d'appels pour s'assurer que chaque classe et méthode est autorisée à appeler le code protégé avant d'accorder l'accès. Si les classes du Wrapper existent dans votre pile d'appels et qu'elles n'ont pas de privilèges, vous obtiendrez une exception de sécurité.

Essayez d'accorder des autorisations à wrapper.jar en ajoutant ce qui suit à votre fichier de stratégie. Cela résout généralement ce type de problème.

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

Certaines applications de service Java ont un problème avec le processus Java qui se termine chaque fois qu'un utilisateur se déconnecte sous Windows. Le Wrapper gère cela correctement depuis sa première version.

La partie Java du Wrapper nécessite une bibliothèque native : Windows : wrapper.dll, Linux/UNIX : libwrapper.so pour que cela fonctionne. La bibliothèque native est responsable de l'interception de tous les signaux système envoyés au processus JVM et de leur traitement correct. Une application Java peut gérer ces signaux en implémentant la méthode controlEvent dans l'interface WrapperListener.

Si vous rencontrez des problèmes avec votre JVM redémarrée par le Wrapper lorsqu'un utilisateur se déconnecte, veuillez vérifier que la bibliothèque est bien chargée. Si ce n'est pas le cas, un message d'avertissement s'affichera dans la sortie de la JVM lors de l'initialisation de WrapperManager.

Vous pouvez trouver des exemples de ce qui se passe lorsque l'utilisateur se déconnecte alors que le Wrapper s'exécute en tant qu'application console et en tant que service dans la section Exemples de la documentation.

Sur les systèmes Windows, la priorité peut être définie en configurant la propriété wrapper.ntservice.process_priority dans le fichier wrapper.conf. Veuillez consulter la Vue d'ensemble de la configuration pour plus de détails.

Sur les systèmes UNIX, la méthode suggérée pour définir la priorité consiste à utiliser la commande « nice » dans vos scripts shell lors du lancement du Wrapper. Les scripts d'exemple fournis avec le Wrapper montrent comment procéder. Consultez « man nice » ou « info nice » pour plus de détails sur l'utilisation de « nice ».

Par défaut, le Wrapper définit le répertoire utilisateur de la JVM à l'emplacement soit du fichier wrapper.exe sous Windows, soit du script shell du Wrapper sous les systèmes UNIX. Cela est fait pour permettre d'utiliser de manière fiable des chemins relatifs au sein de votre application. Normalement, cela ne serait pas possible car le répertoire utilisateur dépendrait de l'endroit d'où la JVM a été lancée.

Les chemins relatifs rendent l'installation d'une application extrêmement facile, car elle peut généralement être décompressée dans n'importe quel répertoire et s'exécuter de manière fiable.

Il existe certains cas où il est nécessaire de définir le répertoire utilisateur à un emplacement autre que celui par défaut. Cela se fait en définissant la propriété wrapper.working.dir.

Lorsque plusieurs copies du Wrapper s'exécutent sous Windows, il n'est pas facile de distinguer les applications dans le Gestionnaire des tâches car elles apparaissent toutes comme wrapper.exe et java.exe. Il n'est pas possible pour le Wrapper d'implémenter une fonctionnalité pour changer ce nom car Windows ne le permet pas pour des raisons de sécurité.

La solution de contournement est un peu bricolée, mais elle fonctionne très bien.

• Renommez le fichier wrapper.exe en wrapper-myapp.exe.
• Modifiez ensuite les fichiers batch pour qu'ils utilisent ce nouveau wrapper-myapp.exe.
• Pour le processus Java, vous devez faire la même chose. Allez dans le répertoire %JAVA_HOME%/bin et copiez simplement java.exe vers java-myapp.exe.
• Modifiez ensuite le fichier wrapper.conf afin que le nouveau java-myapp.exe soit utilisé.

Désormais, lorsque vous consultez le Gestionnaire des tâches Windows, il sera facile de distinguer les exécutables.

Notez que vous pouvez également définir les propriétés wrapper.pidfile et wrapper.java.pidfile dans le fichier wrapper.conf. Celles-ci créeront des fichiers contenant les PID. Ces PID peuvent ensuite être comparés à ceux affichés dans le Gestionnaire des tâches. Notez que vous devez configurer le Gestionnaire des tâches pour afficher les PID des processus.

Sous Windows :

Cela se fait en définissant la propriété wrapper.ntservice.account. Veillez à lire entièrement la documentation, puis réinstallez le service.

Sous Unix :

Par défaut, les démons Unix s'exécutent avec l'utilisateur root. C'est généralement assez sécurisé et le moyen le plus simple de faire fonctionner votre application en tant que service.

Cependant, pour optimiser davantage la sécurité de votre système, il est souvent recommandé de créer un utilisateur dédié pour exécuter votre service. Idéalement, cet utilisateur ne devrait avoir accès qu'aux fichiers du Wrapper et de l'application Java, et aucun autre utilisateur ne devrait pouvoir accéder à ces fichiers.

La variable RUN_AS_USER dans le script shell du Wrapper src/bin/App.sh.in (dans les versions plus anciennes du Wrapper, ce fichier s'appelait « sh.script.in ») vous permet de spécifier l'utilisateur sous lequel le Wrapper doit s'exécuter. Elle est utilisée à la fois lors de l'exécution en tant que service ou en tant qu'application console. Cependant, si vous souhaitez changer l'utilisateur pour un service existant, vous devrez réinstaller le service après toute modification de la variable RUN_AS_USER.

Lorsque RUN_AS_USER est définie, l'utilisateur sera changé une fois le processus Wrapper démarré. Cela signifie que l'utilisateur actuel exécutant le script shell doit avoir l'autorisation de changer d'utilisateur.

IMPORTANT : N'oubliez pas d'ajuster correctement les autorisations des fichiers du Wrapper et de toutes les bibliothèques ou fichiers utilisés par votre application Java (à l'aide des commandes chown et chmod). Dans la plupart des cas, l'utilisateur nouvellement configuré devrait être le propriétaire des fichiers. Pour les scénarios où plusieurs services utilisent une seule installation du Wrapper, il est également possible de définir des autorisations pour le groupe.

Si une application Java s'exécute en tant que service Windows, elle ne s'exécute en réalité pas dans le même contexte/session que l'utilisateur lançant VisualVM. Par conséquent, VisualVM n'est pas en mesure de trouver l'application Java par défaut.

Jusqu'à Windows XP, la politique de sécurité peu stricte des services Windows permettait en fait de résoudre cela assez facilement avec les étapes suivantes :

Au moment où une JVM démarre, la JVM écrit les informations de son processus et de ses hooks à l'emplacement spécifié par la variable d'environnement %TMP%. Veuillez garder à l'esprit que certaines variables d'environnement (y compris celle-ci) sont définies différemment pour chaque utilisateur. Les contextes dans lesquels votre service et VisualVM s'exécutent doivent donc utiliser la même valeur pour cette variable d'environnement.

set.TMP=C:\tmp

Après cela, veuillez (re)démarrer le service. Démarrez maintenant une console et définissez la variable d'environnement TMP à la même valeur que celle spécifiée dans le fichier de configuration :

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

VisualVM devrait maintenant être en mesure de lister le processus Java.

Bien que ce qui précède fonctionne pour les versions de Windows jusqu'à Windows XP, Windows Vista/7 (et versions ultérieures) ne le permettront très probablement plus en raison de mesures de sécurité plus strictes. La seule façon de résoudre cela est donc d'utiliser les paramètres de surveillance à distance JMX (cela nécessite au moins Java 1.5).

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

Veuillez utiliser des numéros non utilisés pour « N » avec la propriété wrapper.java.additional.<n> et remplacer « XXXX » par un numéro de port non utilisé sur votre machine. Depuis VisualVM, veuillez sélectionner « Fichier » → « Ajouter une connexion JMX ». Dans le champ « Connexion », veuillez saisir « localhost:XXXX » (XXXX est le port que vous avez attribué dans le fichier de configuration).

Dans certains environnements où les machines virtuelles sont constamment supprimées et créées avec des outils d'automatisation, le Wrapper cessera de fonctionner dès que le HostId (qui est basé sur l'adresse MAC) est différent de celui défini dans la clé de licence serveur. Dans ce cas, le propriétaire de la licence doit réinitialiser manuellement la clé de licence, ce qui interrompt le processus autonome de création de machines virtuelles. Selon l'outil de virtualisation que vous utilisez, il est possible de définir une adresse MAC fixe pour les machines virtuelles. En utilisant toujours la même adresse MAC, vous êtes assuré que le Wrapper démarrera sans erreurs de clé de licence.

Veuillez consulter la documentation suivante :

• VMware
• VirtualBox
• AWS