ver 3.7.3, ver 3.7.2, ver 3.7.1, ver 3.7.0,

ver 3.6.5, ver 3.6.4, ver 3.6.3, ver 3.6.2, ver 3.6.1, ver 3.6.0,

ver 3.5.60, ver 3.5.59, ver 3.5.58, ver 3.5.57, ver 3.5.56, ver 3.5.55, ver 3.5.54, ver 3.5.53, ver 3.5.52, ver 3.5.51, ver 3.5.50, ver 3.5.49, ver 3.5.48, ver 3.5.47, ver 3.5.46, ver 3.5.45, ver 3.5.44, ver 3.5.43, ver 3.5.42, ver 3.5.41, ver 3.5.40, ver 3.5.39, ver 3.5.38, ver 3.5.37, ver 3.5.36, ver 3.5.35, ver 3.5.34, ver 3.5.33, ver 3.5.32, ver 3.5.31, ver 3.5.30, ver 3.5.29, ver 3.5.28, ver 3.5.27, ver 3.5.26, ver 3.5.25, ver 3.5.24, ver 3.5.23, ver 3.5.22, ver 3.5.21, ver 3.5.20, ver 3.5.19, ver 3.5.18, ver 3.5.17, ver 3.5.16, ver 3.5.15, ver 3.5.14, ver 3.5.13, ver 3.5.12, ver 3.5.11, ver 3.5.10, ver 3.5.9, ver 3.5.8, ver 3.5.7, ver 3.5.6, ver 3.5.5, ver 3.5.4, ver 3.5.3, ver 3.5.2, ver 3.5.1, ver 3.5.0,

ver 3.4.1, ver 3.4.0,

ver 3.3.9, ver 3.3.8, ver 3.3.7, ver 3.3.6, ver 3.3.5, ver 3.3.4, ver 3.3.3, ver 3.3.2, ver 3.3.1, ver 3.3.0,

ver 3.2.3, ver 3.2.2, ver 3.2.1, ver 3.2.0,

ver 3.1.2, ver 3.1.1, ver 3.1.0,

ver 3.0.5, ver 3.0.4, ver 3.0.3, ver 3.0.2, ver 3.0.1, ver 3.0.0,

ver 2.2.9, ver 2.2.8, ver 2.2.7, ver 2.2.6, ver 2.2.5, ver 2.2.4, ver 2.2.3, ver 2.2.2, ver 2.2.1, ver 2.2.0,

Correction de régressions introduites dans la version 3.7.2 du script shell Unix. Sur plusieurs plateformes (macOS x64 ou systèmes avec architectures ppc64le, aarch64 ou s390x), le script n'arrivait pas à localiser le binaire delta-pack approprié et s'arrêtait. De plus, sur macOS, certaines commandes auxiliaires (telles que « status » et « stop ») utilisaient incorrectement des binaires x86 au lieu des binaires aarch64. Aucun changement fonctionnel pour les distributions Windows.

Ajout de la nouvelle propriété wrapper.java.version.info.loglevel pour contrôler le niveau de journalisation des détails d'exécution Java analysés (actuellement l'éditeur, la version, l'architecture et le modèle de données). Fonctionne indépendamment de ou conjointement avec wrapper.java.version.output.

Amélioration du message d'erreur lorsque des fichiers jar du Wrapper en double sont référencés dans le classpath ou le module path.

Ajout de --enable-native-access org.tanukisoftware.wrapper à la ligne de commande du bootstrap. Cela résout les avertissements System.loadLibrary sur Java 24+ et protège contre les échecs de démarrage qui se produiraient si de futures versions de Java commençaient à appliquer des restrictions strictes d'accès natif. Cet indicateur est utilisé dans la ligne de commande qui lance l'application depuis la v3.6.1, mais manquait lors du lancement de l'instance bootstrap, qui a été mise à jour en v3.6.3 pour charger la bibliothèque native du Wrapper. Notez que ces avertissements n'apparaissent par défaut que dans les journaux DEBUG.

Correction du message d'erreur qui était journalisé au niveau DEBUG au lieu de ERROR en cas d'échec de chargement de la bibliothèque native.

Correction de problèmes potentiels dans les scripts batch Windows lorsque _WRAPPER_CONF_OVERRIDE est activé (false par défaut). Ce paramètre permet de spécifier le fichier de configuration en tant que premier argument. Auparavant, lors de la sélection automatique d'un binaire de secours, le script pouvait rechercher le fichier à une position incorrecte dans la liste des arguments. De plus, l'appel du script sans paramètres ou avec une valeur vide faisait échouer le Wrapper avec un chemin vide au lieu d'utiliser le fichier de configuration par défaut.

Correction d'un problème dans les scripts batch Windows provoquant l'échec des delta packs lors de la tentative de détection de l'architecture de la JVM si le chemin vers l'exécutable du Wrapper ou le fichier de configuration contenait des parenthèses. Cela n'affectait que Windows ARM, depuis la version 3.7.1. Merci à Chad pour le correctif.

Correction d'un problème où l'architecture de la JVM dans les scripts batch Windows était comparée en utilisant « arm64 » au lieu de « aarch64 » sur Windows ARM, ce qui pouvait entraîner l'affichage de messages incorrects par le script. Depuis la version 3.7.1. Merci à Chad d'avoir indiqué ce problème.

Amélioration de la gestion des erreurs lorsque les binaires du delta-pack ne correspondent pas à l'architecture de la JVM. Lorsque les scripts batch Windows ou shell Unix peuvent détecter l'architecture de la JVM, ils indiqueront le nom exact de l'exécutable manquant si le binaire correspondant n'est pas trouvé. Dans les autres cas, ou lorsque le Wrapper est lancé sans script, le Wrapper vérifiera l'architecture de la bibliothèque chargée par rapport à sa propre architecture.

Mise à jour de la logique de recherche d'exécutable dans les scripts batch Windows pour rechercher les binaires delta-pack (wrapper-windows-<arch>-<bit>.exe) avant de se rabattre sur wrapper.exe, s'alignant ainsi sur le script shell Unix. Lorsqu'aucun binaire n'est trouvé, le message d'erreur liste désormais tous les chemins et architectures essayés, dans l'ordre de recherche, plutôt que d'afficher uniquement le dernier chemin vérifié.

Mise à jour de la logique de recherche d'exécutable dans le script shell Unix pour éviter de rechercher les binaires delta-pack 32 bits (wrapper-windows-<arch>-32) sur les plateformes qui ne prennent pas en charge les exécutables 32 bits.

Simplification des scripts batch Windows qui démarrent des instances du Wrapper pour des tâches autres que le lancement de l'application Java en omettant les requêtes de bits et d'architecture au Wrapper.

GetHostId.bat est désormais exécutable par double-clic pour les delta packs. La console de sortie reste désormais ouverte automatiquement.

Ajout de noms de signaux système supplémentaires pour éviter le message de journal « UNKNOWN signal » en cas de plantage de la JVM.

Correction d'un problème lors de la résolution de l'encodage de sortie de la JVM où le Wrapper s'arrêtait si l'encodage du processus ou de la session en cours ne pouvait pas être converti en un nom canonique Java. Un encodage non résolu est désormais transmis tel quel à Java, laissant l'instance bootstrap vérifier la prise en charge. De plus, les propriétés d'encodage de la sortie standard et d'erreur ne sont désormais transmises sur la ligne de commande que lorsque cela est nécessaire. Depuis la version 3.7.0.

Correction d'un problème où wrapper.java.additional.<n>.scope était ignoré pour le premier argument sur les systèmes Unix.

Correction d'un problème qui faisait que le delta pack chargeait la bibliothèque native Linux au lieu de la bibliothèque native Alpine sur les systèmes Alpine. Depuis la version 3.7.0.

Correction d'un problème où les delta packs ne chargeaient pas correctement les binaires Windows ARM. Depuis la version 3.7.0.

Ajout de la détection automatique de l'architecture de la JVM dans les scripts des delta packs pour lancer le bon exécutable lors de l'utilisation de JVM émulées sur macOS et Windows ARM.

Correction d'un faux positif qui pouvait se produire dans de rares conditions de concurrence pour les processus enfants de courte durée lancés avec WrapperManager.exec(), amenant le Wrapper à journaliser par erreur un message « Received an unknown child process ID. » et à se terminer. Depuis la version 3.7.0.

Ajout de la prise en charge d'Alpine Linux (x86 et arm64v8). Les daemons sur cette plateforme s'exécutent avec OpenRC.

Ajout de la prise en charge de Windows ARM. Windows 10, Windows 11 et Windows Server 2025 sont pris en charge.

Arrêt de la fourniture de versions pour HP-UX (Itanium et PA-RISC), Linux ARMEL 32 bits et macOS 32 bits (x64 et aarch64 toujours fournis).

En raison de limitations matérielles, les distributions AIX ne sont pas incluses dans cette version. La prise en charge future sera évaluée en fonction de la demande des clients. Si votre organisation a besoin de la prise en charge d'AIX, veuillez contacter notre équipe.

Augmentation des exigences système minimales pour plusieurs plateformes. Pour des informations détaillées, consultez la page « Plateformes prises en charge (Wrapper version 3.7.*) ».

Les binaires Windows ne sont plus signés en double. La signature SHA-1 a été supprimée, car toutes les versions de Windows prises en charge prennent désormais en charge les certificats SHA-2.

Augmentation de la version minimale de JVM prise en charge de Java 4 à Java 7. Dans le cadre de ce changement, le code Java a été retravaillé pour utiliser les génériques. Les modifications de l'API ont été réduites au minimum, mais la recompilation de certains codes utilisateur peut être nécessaire.

Activation du RELRO complet pour les binaires FreeBSD et Linux (wrapper et libwrapper.so) afin de se protéger contre les attaques de corruption mémoire par écrasement de GOT. Sur macOS, où le chargeur dynamique fournit par défaut une protection équivalente au RELRO, la liaison anticipée (eager binding) a été activée pour garantir que tous les pointeurs de symboles dynamiques sont verrouillés immédiatement au démarrage pour une sécurité maximale. Sur Linux, l'exécutable du Wrapper était déjà protégé par RELRO depuis la version 3.5.40, mais le RELRO a été ajouté à la bibliothèque native dans cette version.

Les binaires FreeBSD sont désormais compilés avec _FORTIFY_SOURCE=2. Cela introduit des vérifications à la compilation et à l'exécution qui aident à prévenir les vulnérabilités liées à la mémoire telles que les débordements de tampon et les opérations mémoire non sécurisées. Les distributions Linux et macOS sont protégées avec _FORTIFY_SOURCE=2 depuis la version 3.5.40.

Les binaires Unix pris en charge sont désormais compilés avec une protection de pile afin de renforcer les défenses contre les exploits de corruption mémoire. Cela inclut des canaris de pile pour détecter et neutraliser les débordements de tampon, ainsi que des vérifications à l'exécution qui empêchent les attaques de « stack clash » de contourner les pages de garde mémoire.

Activation de PIE (Position-Independent Executable) pour toutes les plateformes Unix sauf Solaris. Cette mesure de sécurité protège contre les attaques qui reposent sur la connaissance du décalage du code exécutable dans le binaire. La bibliothèque native était déjà compilée avec PIC (Position-Independent Code) dans les versions précédentes du Wrapper.

Ajout d'une vérification pour empêcher le script shell Unix de démarrer ou d'arrêter un service installé avec un nom identique à un emplacement différent. Cela résout un problème où le script n'arrivait pas à suivre l'état du service en raison d'une non-correspondance du chemin du fichier PID. Si un service conflictuel est détecté, l'action est désormais abandonnée et le chemin de ce service est affiché.

Amélioration de la fiabilité et de la cohérence des commandes start, stop et restart du script shell Unix sur les plateformes et gestionnaires de services pris en charge. Les messages ont été standardisés et rendus plus précis, l'état du service est vérifié à l'arrêt, et sous systemd, la commande restart vérifie si le service est en cours d'exécution et effectue un démarrage normal s'il ne l'est pas.

Amélioration des actions de contrôle de service macOS (start, restart, stop, uninstall) pour une meilleure fiabilité et une journalisation plus claire. Les commandes launchctl héritées (load, unload, start, stop) ont été mises à jour vers leurs équivalents modernes (bootstrap, bootout, kickstart, kill). Merci à Jonathan pour l'indication. Avec cette mise à jour et d'autres changements de cette version, l'exigence minimale de macOS est désormais 10.13 (High Sierra).

Les propriétés avec des index entiers commençant par un zéro initial (par ex. « 02 ») sont désormais ignorées. Cela évite la confusion où un index « 02 » ne remplace pas « 2 », ainsi qu'un comportement de tri incohérent.

Désactivation de la possibilité de charger des clés de licence DEV ou TIME si leurs propriétés contiennent un nom d'hôte de contexte ou un HostId. Cela évite complètement la nécessité de rechercher les HostIds et d'attendre qu'ils deviennent disponibles au démarrage, lorsqu'une clé de licence de développement ou temporaire est utilisée.

Amélioration des vérifications dans les versions 32 bits du Wrapper pour gérer les dates dans les clés de licence qui dépassent le basculement 32 bits du 18/01/2038 (ceci est intentionnellement 24 heures avant la date réelle de basculement). Toutes les dates seront effectivement ramenées à cette date, ce qui signifie que les baux se termineront effectivement à la date de basculement. Les clés de licence de développement qui masquent la période de mise à niveau échoueront si leur date de fin dépasse la date de basculement. Les versions 64 bits ne sont pas affectées.

Amélioration de la sortie du journal lorsque le Wrapper démarre et abandonne l'attente que les HostIds deviennent disponibles au démarrage. Voir les propriétés wrapper.wait_for_hostid et wrapper.wait_for_hostid.strict.

Amélioration de la conformité avec JEP 400 (introduit dans Java 18), qui standardise UTF-8 comme jeu de caractères par défaut dans la plupart des API Java, à l'exception des E/S console. En plus des valeurs d'encodage explicites, la propriété wrapper.jvm.encoding prend désormais en charge deux valeurs spéciales : COMPAT, qui garantit un comportement cohérent entre les versions de Java, et WRAPPER, qui garantit la cohérence entre les versions du Wrapper. Les encodages non pris en charge par la version actuelle de Java (par ex. les jeux de caractères non UTF-8 transmis à Java 18) sont bloqués par défaut, mais cette restriction peut être levée en définissant wrapper.jvm.encoding.allow_unsupported à TRUE.

Amélioration de la détection de la prise en charge par l'installation Java actuelle de la configuration d'encodages séparés pour la sortie standard et l'encodage par défaut de la JVM. À partir de Java 18, les propriétés système stdout.encoding et stderr.encoding sont désormais utilisées à la place des propriétés internes sun.stdout.encoding et sun.stderr.encoding.

Ajout d'une nouvelle action USER_<n> aux propriétés wrapper.signal.mode.hup, wrapper.signal.mode.usr1 et wrapper.signal.mode.usr2 pour permettre le déclenchement d'un événement user_<n> en réponse à un signal.

Ajout d'une nouvelle action USER_<n> à la propriété wrapper.event.<event_name>.command.on_exit.<n>. Cela permet de déclencher un événement user_<n> lorsque la commande associée à <event_name> renvoie un code de sortie spécifique. Cela peut être utilisé pour définir des actions personnalisées de gestion des échecs.

Ajout d'une nouvelle classe WrapperUserEvent représentant un événement Java qui est déclenché chaque fois qu'un événement user_<n> survient dans le processus Wrapper. Les événements user_<n> peuvent être déclenchés depuis le fichier de commandes, la sortie du journal, les signaux, etc. Les instances de WrapperUserEvent peuvent être gérées par des WrapperEventListeners avec EVENT_FLAG_USER défini dans leurs masques.

La prise en charge de wrapper.java.library.path.append_system_path a été abandonnée. Ce changement s'aligne sur le comportement de Java 7+, qui n'ajoute plus le chemin de recherche par défaut des bibliothèques natives du système à java.library.path. Les emplacements contenant des bibliothèques natives chargées directement par le code Java doivent désormais être définis explicitement à l'aide des propriétés wrapper.java.library.path.<n>. L'utilisation de wrapper.java.library.path.append_system_path entraînera désormais une erreur de configuration invalide et empêchera le Wrapper de continuer. Cela garantit que les bibliothèques ne sont chargées qu'à partir des emplacements prévus et stables.

Ajout de la nouvelle propriété wrapper.system.library.path.override pour remplacer le chemin de recherche des bibliothèques natives hérité de l'environnement parent par un chemin personnalisé défini exclusivement via les propriétés wrapper.system.library.path.<n>. Cela permet de restreindre le chemin de recherche aux seuls emplacements requis par l'application.

Correction du bouton « Update Event Listener » dans l'application testwrapper afin que les événements sélectionnés soient désormais journalisés correctement lors de l'exécution avec la boîte de dialogue ouverte.

Correction d'un problème où le Wrapper se bloquait à l'étape de bootstrap si une méthode était spécifiée après le nom de la classe principale dans la valeur de wrapper.app.parameter.1.

Ajout de vérifications pour s'assurer que les méthodes main existent avant de lancer l'application Java. Lors de l'utilisation de WrapperStartStopApp (méthode d'intégration n° 2), la classe d'arrêt est également vérifiée.

Correction d'un problème où la méthode d'intégration n° 2 échouait à s'initialiser si les classes de démarrage et d'arrêt se trouvaient dans des modules différents.

L'intégrité du fichier wrapper.jar et de sa bibliothèque native est désormais vérifiée au démarrage afin d'améliorer la sécurité et la fiabilité. Deux modes de vérification peuvent être configurés à l'aide de la propriété wrapper.check_integrity.mode. Le mode par défaut effectue une vérification de hachage après la phase de bootstrap mais avant le lancement de l'application Java, permettant au Wrapper de collecter des métadonnées de bibliothèque telles que la version et l'édition avant la validation. La plupart des échecs de vérification d'intégrité résultent de mises à niveau de bibliothèques incomplètes ou incorrectes, ce qui rend ce mode bien adapté à la journalisation et au diagnostic. Le mode strict empêche le chargement des bibliothèques si la vérification échoue. Ces vérifications fournissent une couche de sécurité supplémentaire mais ne remplacent pas les permissions appropriées du système de fichiers sur les bibliothèques et leurs répertoires, qui restent essentielles pour garantir que seuls des fichiers légitimes sont utilisés.

La propriété wrapper.jarfile, introduite dans la version 3.5.55, est désormais requise pour permettre au Wrapper d'effectuer des vérifications d'intégrité fiables.

Mise en œuvre de mesures d'authentification à plusieurs niveaux pour le processus Java se connectant au Wrapper. En tant que base de sécurité, la clé utilisée lors de la poignée de main n'est plus exposée sur la ligne de commande (via -Dwrapper.key) et est désormais générée avec une entropie renforcée. De plus, le Wrapper vérifie le PID client signalé par rapport au PID pair réel (pour les types de backend pris en charge), et le mode wrapper.java.monitor=LAUNCHED a été rendu plus strict pour rejeter la connexion si ce PID vérifié ne correspond pas au processus initialement lancé. Alors que LAUNCHED interdit désormais la redirection de processus, un mode LEGACY a été ajouté pour la rétrocompatibilité. Dans les modes LEGACY et Windows JAVA où la redirection est autorisée, de nouvelles vérifications de sécurité garantissent que le PID client est un descendant vérifié au sein de la hiérarchie de processus du Wrapper.

Modification du type de connexion backend par défaut en PIPE pour une sécurité améliorée. Sur Windows, qui utilise des canaux nommés, ce mode a été rendu plus sécurisé avec des mesures pour prévenir les interférences non autorisées, le « pipe squatting » et les attaques par déni de service. De plus, l'authentification du processus Java se connectant a été renforcée par la vérification du PID et du SID. Notez que la vérification du SID nécessite le SeImpersonatePrivilege dans le jeton du Wrapper, qui est présent lors de l'exécution en tant que service Windows si le compte est SYSTEM (par défaut) ou si la propriété wrapper.ntservice.impersonation est définie sur UNCHANGED.

Ajout des nouvelles propriétés wrapper.backend.windows.type et wrapper.backend.unix.type pour permettre la configuration du type de backend par plateforme. Un nouveau mode SOCKET_PAIR a été ajouté pour wrapper.backend.unix.type.

Introduction de plusieurs améliorations du cycle de vie de la connexion backend pour renforcer la résilience. Pour atténuer d'éventuelles tentatives de déni de service, les demandes de connexion non autorisées sont rejetées et ignorées, garantissant que la connexion reste disponible pour que le processus Java légitime puisse se connecter. De plus, le côté serveur de la connexion est désormais strictement réinitialisé chaque fois que la JVM est redémarrée afin que tout état obsolète ou donnée résiduelle d'un cycle précédent soit effacé.

Activation du nettoyage automatique des pipes et des flux standard du Wrapper lors du lancement de sous-processus (par ex. commandes d'événements) sous Unix. Cela empêche l'héritage de descripteurs de fichiers inutiles, aidant à maintenir les sous-processus légers et isolés.

Ajout des nouvelles syntaxes set.<platform>.<X> et set.<platform>.default.<X> pour définir des variables spécifiques à la plateforme.

Ajout de la variable d'environnement WRAPPER_OS_FAMILY (« windows » ou « unix », selon la plateforme).

Amélioration de la fiabilité du nettoyage des threads dans le processus Wrapper pour des arrêts gracieux.

Amélioration des messages de journal pour les variables d'environnement non définies en incluant le fichier de configuration et le numéro de ligne où elles sont référencées pour la première fois.

Ajout de la possibilité de définir le répertoire de travail pour un processus enfant lancé via les types de démarrage DYNAMIC et POSIX_SPAWN. Cette fonctionnalité s'appuie sur les optimisations natives du système d'exploitation sur les plateformes Unix modernes, notamment Linux (glibc 2.29+), macOS (10.15+), FreeBSD (13.1+) et Solaris (11.3+). WrapperProcessConfig.isWorkingDirectorySupported() peut être utilisé à l'exécution pour vérifier la compatibilité de la plateforme avant de tenter de définir un répertoire de travail.

Dépréciation de la propriété système expérimentale wrapper.child.allowCWDOnSpawn, car la modification du répertoire du processus parent peut introduire des conditions de concurrence dans les environnements multithread. Un avertissement sera journalisé si cette propriété est activée pour les types de démarrage DYNAMIC ou POSIX_SPAWN alors que WrapperProcessConfig.isWorkingDirectorySupported() renvoie true.

Modification de la logique de résolution du type de démarrage DYNAMIC pour les processus enfants. Pour s'aligner sur les implémentations Java modernes (en particulier depuis Java 13), le mécanisme par défaut est désormais POSIX_SPAWN sur toutes les plateformes Unix. Si un répertoire de travail est défini sur une plateforme où WrapperProcessConfig.isWorkingDirectorySupported() renvoie false, FORK_EXEC sera utilisé à la place pour permettre aux processus enfants de s'exécuter avec le répertoire de travail personnalisé.

Dépréciation du type de démarrage WrapperProcessConfig.VFORK_EXEC sur macOS et mappage de son comportement sur DYNAMIC (voir la note précédente). De plus, WrapperProcessConfig.isSupported( WrapperProcessConfig.StartType.VFORK_EXEC ) renvoie false sur cette plateforme. Apple a déprécié l'appel système hérité vfork() en raison des risques inhérents de corruption mémoire liés au partage de mémoire parent/enfant. Comme macOS optimise nativement posix_spawn et fork() standard (via copy-on-write) pour qu'ils soient très efficaces, vfork n'est plus nécessaire ni recommandé.

Pour des vérifications plus sûres à la compilation, les fonctions basées sur des entiers WrapperProcessConfig.isSupported( int startType ), WrapperProcessConfig.getStartType() et WrapperProcessConfig.setStartType( int startType ) sont désormais dépréciées au profit de fonctions surchargées utilisant l'énumération WrapperProcessConfig.StartType dans leurs signatures.

Ajout d'une nouvelle directive @properties.final pour définir des propriétés dans le fichier de configuration qui ne peuvent pas être remplacées.

Amélioration des messages d'avertissement lorsque des propriétés de configuration en double sont trouvées.

Correction de l'enregistrement incomplet de la variable WRAPPER_CONF_DIR, dont la valeur ne devrait pas être modifiable. Cela provoquait un avertissement erroné indiquant que la variable n'était pas définie lorsqu'elle était référencée dans la configuration, et permettait également de la remplacer par une définition explicite dans le fichier de configuration. La variable est désormais strictement interne, et toute tentative de la redéfinir est ignorée.

Prévention de l'inclusion circulaire et en double de fichiers de configuration. Le Wrapper journalisera désormais une erreur descriptive et s'arrêtera si cela se produit.

Correction d'un problème où la spécification de l'argument --target comme nom de fichier sans chemin était considérée comme invalide lors de la personnalisation du binaire Wrapper sous Windows.

Correction des propriétés Specification-Version et Implementation-Title dans le fichier MANIFEST.MF du jar pour qu'elles soient cohérentes avec la version de la spécification.

Amélioration du message d'erreur affiché lorsque le code Java du Wrapper échoue à charger sa bibliothèque native parce que le fichier wrapper.jar se trouvait dans le chemin du répertoire endorsed. Uniquement un problème antérieur à Java 9.

Report de l'enregistrement des MBeans WrapperManager jusqu'après la réception des propriétés système définies avec wrapper.app.property.<n> afin de permettre de les désactiver de cette manière.

Ajout des nouvelles propriétés système org.tanukisoftware.wrapper.WrapperManager.waitLogManagerInitialized, org.tanukisoftware.wrapper.WrapperManager.waitLogManagerInitialized.timeout et org.tanukisoftware.wrapper.WrapperManager.waitLogManagerInitialized.delay qui peuvent être utilisées pour attendre l'initialisation de java.util.logging.LogManager par l'application avant que le Wrapper n'enregistre les MBeans et ne démarre la détection des interblocages, car ces deux fonctionnalités référencent en interne cette classe. La propriété timeout (par défaut 30 secondes) spécifie le temps d'attente maximal pour que la propriété système java.util.logging.manager soit définie. Une fois définie, le Wrapper attend que le délai configuré (par défaut une seconde) s'écoule pour permettre à l'application de terminer l'initialisation. Ce report empêche le Wrapper d'interférer avec les applications qui doivent enregistrer le LogManager elles-mêmes, car l'initialisation n'est autorisée qu'une seule fois par cycle de vie de la JVM.

Correction d'un problème sous Windows où les variables d'environnement n'étaient pas développées lorsqu'elles étaient référencées avec une casse différente de leurs définitions. Par exemple, auparavant %PATH% devait être écrit %Path% pour fonctionner correctement. Cette version rétablit le comportement standard de Windows consistant à traiter les références aux variables d'environnement comme insensibles à la casse. Aucun changement sur les systèmes Unix, où les noms de variables d'environnement restent sensibles à la casse. Depuis la version 3.6.3.

Correction d'un plantage lors de la tentative de collecte d'un HostId avec une adresse NULL.

Correction d'un problème où le descripteur de module dans wrapper.jar n'était pas compatible avec Java 9 ou 10. Les applications non modulaires pouvaient toujours utiliser le jar sans problème, mais les applications qui s'appuient sur le système de modules Java échouaient à charger le descripteur de module avec ces versions de Java.

Correction d'un problème où les signatures jar indiquaient « jar verified, with signer errors » en raison d'une chaîne de certificats incomplète utilisée lors de la signature.

Suppression des entrées non standard des manifestes jar. Ajout de l'entrée Sealed pour protéger contre l'ajout de classes tierces aux packages du Wrapper dans les anciennes versions de Java. Dans Java 9+, les modules du Wrapper sont scellés depuis la version 3.5.55.

Correction d'un problème où des règles plus strictes de chargement des DLL pour le processus Wrapper (introduites dans la version 3.6.3) interféraient avec l'initialisation des composants réseau, en particulier le Windows Multiple Provider Router (MPR). Cela empêchait le Wrapper de résoudre le domaine du compte de service, ce qui empêchait à son tour l'octroi du privilège « Ouvrir une session en tant que service » lors de l'installation du service.

Correction d'un problème rare où un message de journal précoce au démarrage pouvait provoquer la création du fichier journal par défaut dans le répertoire de travail initial (soit l'emplacement de lancement du terminal, soit C:\Windows\System32 pour les services Windows) avant que le Wrapper ne bascule vers l'utilisation du répertoire où se trouve son binaire.

Amélioration de la séquence de démarrage précoce des services Windows pour signaler plus fiablement les erreurs au SCM et au journal des événements en cas d'échec (par ex. lors du chargement de la configuration). L'instance wrapperm qui lance le service fournit désormais des messages plus clairs, y compris le chemin vers le fichier journal contenant les informations détaillées sur l'échec.

Correction d'une éventuelle incompatibilité d'encodage dans les paquets backend envoyés de Java vers le Wrapper natif. Auparavant, ces paquets uniquement ASCII étaient encodés en utilisant file.encoding et décodés avec l'encodage de sortie de la JVM. Cela provoquait des erreurs de décodage lorsque les encodages n'étaient pas compatibles ASCII, empêchant le Wrapper d'authentifier la JVM. UTF-8 est désormais utilisé aux deux extrémités pour garantir une transmission correcte.

Résolution d'une condition de concurrence qui pouvait provoquer un plantage si un signal de terminaison (par ex. SIGTERM ou Ctrl+C) était reçu pendant la phase d'arrêt finale. Le plantage était bénin mais pouvait générer un fichier dump et un message syslog.

Amélioration de la création de la connexion backend, en particulier le mécanisme de repli, qui bascule désormais de manière fiable vers un type de connexion alternatif lorsque celui sélectionné échoue.

Le Wrapper tente désormais de recréer la connexion backend si l'adresse de bouclage est temporairement indisponible lors de la liaison initiale. Ce mécanisme de nouvelle tentative est actif pendant une durée maximale définie par wrapper.backend.socket.bind.timeout. Il gère les détachements brefs d'adresse IP du périphérique de bouclage, qui peuvent se produire lorsque systemd-networkd gère l'interface et recharge la configuration (par exemple via 'netplan apply'). Lorsque wrapper.backend.type est défini sur AUTO ou SOCKET, le Wrapper tente plusieurs types de connexion successivement, en sélectionnant le premier qui se connecte avec succès.

Ne plus transmettre -Djava.net.preferIPv6Addresses=true à la JVM lors de l'utilisation d'un type de backend SOCKET_IPv6. Auparavant, cette propriété était transmise inutilement, car la logique interne du code Java garantit déjà que la bonne adresse de bouclage (IPv4 ou IPv6) est choisie en fonction de la version IP du socket d'écoute. java.net.preferIPv6Addresses=true indiquera à la pile réseau Java de prioriser globalement les adresses IPv6 par rapport aux adresses IPv4 pour la résolution des noms d'hôte. Si une application nécessite cette préférence IPv6 pour ses propres connexions, cette propriété doit être configurée indépendamment.

Empêcher l'utilisation du type de backend SOCKET_IPv6 lorsque java.net.preferIPv4Stack=true est spécifié, car cela provoquerait une SocketException « Protocol family unavailable » dans le code Java. Lors de l'utilisation des types de backend AUTO ou SOCKET, le Wrapper ignorera simplement SOCKET_IPv6 et tentera toujours d'utiliser les autres types.

La prise en charge de wrapper.port.address a été abandonnée. Lorsque cette propriété est utilisée, wrapper.backend.type basculera désormais automatiquement de AUTO vers PIPE. Si un type SOCKET est spécifié, le Wrapper s'arrêtera.

Modification de la valeur par défaut de wrapper.disable_tests à TRUE pour renforcer la sécurité des applications en production en empêchant l'utilisation des méthodes de test. Lorsque les tests sont activés, le Wrapper affichera un avertissement avant de démarrer la JVM. Le niveau de journalisation de cet avertissement peut être contrôlé avec la propriété wrapper.java.tests.warning.loglevel. Voir la vulnérabilité n°14.

Dépréciation de la méthode de test WrapperManager.accessViolation(), car elle n'a aucun effet sur les versions récentes de Java. Pour les tests, utilisez plutôt WrapperManager.accessViolationNative().

Amélioration du comportement lorsqu'une propriété wrapper.on_exit.<n> est définie sur une action autre que SHUTDOWN. L'action ne sera exécutée que si la sortie est initiée depuis la JVM ou depuis une commande d'événement.

Résolution plus fiable de l'encodage pour les locales nues sans jeu de caractères spécifié (par exemple 'ja_JP'), sur les plateformes Unix.

Les messages d'erreur produits par l'instance JVM de bootstrap sont désormais localisés, sauf dans les cas où la bibliothèque native ne parvient pas à se charger.

Les incompatibilités de version entre la bibliothèque native et le Wrapper sont désormais détectées plus tôt, en même temps que la vérification du fichier wrapper.jar, avant le lancement de l'application.

Le processus Wrapper limite désormais strictement le chargement des DLL au répertoire System32 de Windows. Bien que le mode de recherche sécurisée des DLL (Safe DLL Search Mode, activé par défaut sur les versions modernes de Windows) impose déjà un chargement sécurisé, cette mise à jour ajoute une couche de sécurité supplémentaire en contournant tous les chemins de recherche inutiles.

Ajout des nouvelles propriétés wrapper.java.windows.dll.search.mode et wrapper.java.windows.dll.search.path.<n> pour contrôler le comportement de recherche des DLL pour le code natif exécuté au sein du processus Java. Le mode par défaut, LEGACY, maintient la compatibilité avec les versions antérieures du Wrapper et s'aligne sur le comportement par défaut de la JVM. Des chemins restreints peuvent être configurés pour renforcer les protections contre le détournement de DLL. Toutefois, soyez prudent car des paramètres trop restrictifs qui interdisent des répertoires attendus par la JVM ou l'application peuvent entraîner des échecs de chargement de DLL et des erreurs d'exécution.

Correction d'un bug où les valeurs des propriétés wrapper.system.library.path.<n> n'étaient pas correctement ajoutées en tête de la variable d'environnement du chemin des bibliothèques (LD_LIBRARY_PATH sous Unix, PATH sous Windows) lorsque la configuration était rechargée et que la variable était également définie explicitement dans le fichier de configuration. De plus, lorsque la variable est générée à partir des valeurs wrapper.system.library.path.<n>, la source affichée lors du dump des variables d'environnement inclut désormais la lettre 'W', indiquant que le Wrapper a contribué à définir sa valeur.

Correction d'un problème où les variables d'environnement dans le fichier de configuration n'étaient pas résolues correctement si elles faisaient référence à elles-mêmes ou étaient référencées avant d'être définies.

Suppression d'un avertissement de journal incorrect lorsqu'une variable était définie plusieurs fois dans la configuration.

Correction de caractères illisibles affichés lors de la liste des propriétés backend en mode débogage sous Windows. Depuis la version 3.6.0.

Correction d'un plantage potentiel lors de l'installation d'un service Windows avec les privilèges requis.

Ajout d'une vérification pour annuler l'élévation des instances wrapperm s'exécutant dans une session non interactive. Cela empêche le processus de rester bloqué indéfiniment à l'invite du Contrôle de compte d'utilisateur (UAC), inaccessible dans de tels contextes. Au lieu de bloquer, le processus se terminera désormais avec un code d'erreur.

Lors de l'exécution dans une session non interactive, les propriétés wrapper.wrapperm.logfile.enable et wrapper.wrapperm.syslog.enable sont désormais forcées à TRUE. Cela garantit que les messages sont capturés dans les journaux puisqu'ils ne peuvent pas être visualisés dans la console.

Les propriétés wrapper.name, wrapper.displayname et wrapper.description ne sont plus rechargeables. Toute modification de ces propriétés nécessite une réinstallation du service pour être correctement prise en compte.

Les modifications suivantes ont été apportées à la configuration envoyée à la JVM :

• Les définitions de variables internes sont exclues.

• Les propriétés non rechargeables sont systématiquement incluses dans toutes les instances JVM, reflétant leurs définitions initiales au démarrage.

Le dump des propriétés système et des propriétés de configuration depuis l'application TestWrapper est désormais effectué par ordre alphabétique pour améliorer la lisibilité.

Modification de la configuration de DemoApp pour définir explicitement la propriété wrapper.app.parameter.1 à « dialog ». Auparavant, cette propriété était laissée vide et le Wrapper l'ignorait. Cependant, avec les modifications de la version 3.6.0, les valeurs vides sont désormais transmises à Java telles quelles. DemoApp est conçu pour ne recevoir aucun paramètre ou un mode valide (« dialog » ou « start »), mais pas de valeurs vides.

Suppression d'un avertissement qui était journalisé dans la console si destroy() était appelé sur une instance WrapperProcess après que le processus ait déjà été nettoyé en interne en réponse à la réception d'un signal SIGCHLD. Hormis l'avertissement, l'appel à destroy() fonctionnait correctement.

Ajout d'un message de débogage lors de l'établissement de la connexion socket depuis le code Java pour afficher le PID du processus serveur (Linux et Windows).

Ajout de la détection des signaux d'accusé de réception négatif (NAK) sur le socket backend. Les signaux NAK sont utilisés pour indiquer qu'un paquet n'a pas été reçu correctement ou qu'une erreur s'est produite. Ajout également de 'NAK' comme commande de test pour la propriété wrapper.commandfile afin de tester la gestion de ce signal.

Conformément aux nouvelles recommandations du JDK 24 (JEP 472), autoriser explicitement le module Wrapper 'org.tanukisoftware.wrapper' à exécuter du code natif, ce qui est nécessaire au fonctionnement de plusieurs fonctionnalités. Cela empêche l'apparition du message « WARNING: A restricted method in java.lang.System was called... ». Le niveau de restriction pour les autres modules, y compris le module UNNAMED, reste aux paramètres standard de la version de Java utilisée. Les versions de Java antérieures à 24 ne sont pas concernées par cette modification.

La définition de wrapper.jarfile est obligatoire lors de l'utilisation de Java 24+.

Ajout du nouvel ensemble de propriétés wrapper.java.module.<n>.enable_native_access pour activer l'accès natif pour des modules spécifiques. Ces propriétés sont ignorées lors de l'exécution sur des versions de Java antérieures à 24.

Les lignes de commande Java générées lors de l'utilisation de modules ont été simplifiées. Les valeurs d'options sont regroupées pour éviter les doublons, et 'org.tanukisoftware.wrapper' n'est plus ajouté de manière redondante à la liste des modules. La JVM reconnaît intrinsèquement 'org.tanukisoftware.wrapper' comme racine en raison de sa présence sur le chemin des modules d'upgrade.

Correction de la variable d'environnement CLASSPATH qui n'était pas définie avant les étapes de bootstrap et --dry-run. Lors de l'utilisation de wrapper.java.classpath.use_environment, cela pouvait provoquer l'échec de ces étapes.

Ajustement de la portée par défaut (APP, DRYRUN_APP, BOOSTRAP_DRYRUN_APP) de certaines options JVM spécifiques, et amélioration des messages de journalisation associés lorsqu'une portée est modifiée par rapport à sa valeur configurée. Correction également de la portée des options qui peuvent être scindées.

Correction d'un plantage lors de la personnalisation des binaires Wrapper sous Windows. Depuis la version 3.6.0.

Le processus de bootstrap a été allégé en n'initialisant plus la classe principale de l'application. Cette modification résout des problèmes potentiels de blocage au démarrage.

La lecture de la sortie des requêtes Java a été optimisée pour une meilleure réactivité et évite désormais de se bloquer lorsque le tube est plein. De plus, le Wrapper pourra continuer tant que la sortie reçue est correcte, même si d'autres erreurs se produisent dans le processus enfant.

Correction de problèmes lors du vidage de Stdin entre deux invocations de JVM. Si la première JVM se terminait prématurément avant que Stdin ne lui soit redirigé, le Wrapper restait bloqué en attendant le vidage, expirait, et finissait par désactiver l'entrée console. Le calcul du temps alloué au processus de vidage a également été rendu plus précis.

Le format de journal 'J' affiche désormais également le pid des processus 'java -version', bootstrap et --dry-run. Le pid est également affiché comme message de débogage lorsque chacun de ces processus est démarré.

Mise à jour du modèle de fichier de configuration Wrapper par défaut afin qu'un redémarrage dû à un filtre OutOfMemoryError correspondant ne soit plus déclenché par défaut si l'utilisateur active la sortie -Xlog:class+load.

Correction de wrapper.ignore_sequence_gaps qui était ignoré pour les propriétés wrapper.secure_file.check.windows.allowed_account.<n>, wrapper.secure_file.check.unix.allowed_group.<n>, wrapper.secure_file.additional.<n>.

Ajout des nouvelles propriétés wrapper.secure_file.additional.<n>.required pour indiquer si un fichier supplémentaire doit exister ou est facultatif.

Correction de cas rares où le Wrapper ne s'arrêtait pas malgré le signalement d'une erreur FATAL lors de la vérification des fichiers sécurisés.

Mise à jour des messages de débogage pour inclure la liste des propriétés et paramètres d'application transmis via le backend. Cela aidera à vérifier les valeurs réellement transmises à la JVM. Pour des raisons de sécurité, toute donnée sensible, telle que les mots de passe, est automatiquement masquée.

Sous macOS, si l'adaptateur WiFi a la randomisation d'adresse activée, il ne pourra pas être utilisé comme HostId fiable. Ajout d'un message demandant aux utilisateurs de désactiver la randomisation pour leur connexion WiFi afin de l'utiliser comme HostId. Cela devrait être sans danger sur les réseaux de confiance, mais comporte le risque de rendre votre PC plus facile à suivre sur les réseaux WiFi publics. Elle peut être désactivée pour des réseaux WiFi connus spécifiques. Mais le HostId ne sera pas disponible sur les réseaux WiFi avec la randomisation activée.

Correction d'un problème introduit dans la version 3.6.0 où les chemins relatifs des fichiers de configuration inclus n'étaient pas résolus correctement après un rechargement de la configuration si le répertoire de travail avait été modifié à l'aide de wrapper.working.dir.

La gestion des caractères spéciaux dans les arguments transmis à la JVM ou aux commandes d'événement a été retravaillée afin qu'ils soient reçus par l'exécutable cible exactement tels qu'écrits dans le fichier de configuration, quelle que soit la plateforme. Auparavant, les caractères spéciaux devaient être échappés différemment pour Windows ou Unix.

Cela implique les modifications suivantes :

• Les guillemets extérieurs, qui étaient utilisés sous Windows pour empêcher qu'une valeur contenant des espaces ou des tabulations soit scindée en plusieurs arguments, ne sont plus nécessaires et doivent être supprimés.

• Les propriétés wrapper.*.stripquotes ne sont plus prises en charge. Si elles sont utilisées, ces propriétés doivent être retirées du fichier de configuration et les valeurs de propriétés associées mises à jour pour ne plus échapper les guillemets et les barres obliques inverses.

• Les nouvelles propriétés wrapper.app.parameter.<n>.quotable, wrapper.app.property.<n>.quotable, wrapper.java.additional.<n>.quotable et wrapper.event.<event_name>.command.argv.<n>.quotable ont été ajoutées pour permettre la mise entre guillemets des valeurs contenant des espaces en début ou en fin. Ces propriétés peuvent être utilisées à la fois sous Windows et sous Unix.

• wrapper.app.parameter_file.quotable, wrapper.app.property_file.quotable et wrapper.java.additional_file.quotable peuvent être utilisées pour permettre d'interpréter les guillemets comme délimiteurs des arguments. La valeur par défaut de ces propriétés est FALSE, ce qui signifie que par défaut une ligne sera interprétée comme un seul argument et que les guillemets seront transmis tels quels à la cible. Une valeur TRUE permettra à un fichier de contenir plusieurs arguments sur une seule ligne.

Permettre aux options telles que --add-reads, --add-opens d'être séparées de leurs arguments par un espace dans les propriétés wrapper.java.additional.<n>. Auparavant, un signe égal (=) devait être utilisé.

Ne plus supprimer les caractères de tabulation des valeurs de propriétés.

Ajout de la nouvelle commande --cipher pour obfusquer les mots de passe ou les données sensibles destinés à être utilisés dans le fichier de configuration. Quatre méthodes différentes sont actuellement disponibles : 'base64', 'base64url', 'obf' et 'robf'. Les deux premières méthodes sont un encodage base64 standard, qui rend simplement plus difficile pour un observateur occasionnel de mémoriser la valeur. 'obf' et 'robf' offrent une obfuscation plus forte avec des méthodes propriétaires limitées aux éditions Standard et Professional. Avec 'obf', la même entrée produit toujours la même sortie, tandis que 'robf' génère des sorties aléatoires. Les deux méthodes peuvent éventuellement spécifier une clé privée pour plus de sécurité. Une nouvelle commande --keygen peut être utilisée pour générer des clés privées.

Ajout des nouvelles propriétés wrapper.secure_file.* pour aider à définir des permissions appropriées aux clés privées, fichiers de configuration et fichiers de paramètres contenant des données sensibles. Des permissions considérées comme trop ouvertes entraîneront l'arrêt du Wrapper. L'édition Standard ajoute les propriétés wrapper.secure_file.additional.<n> pour appliquer les mêmes contraintes de permission à tout fichier sensible supplémentaire que votre application pourrait utiliser.

Les fichiers de paramètres spécifiés avec wrapper.java.additional_file, wrapper.app.property_file ou wrapper.app.parameter_file ne sont désormais rechargés que si la propriété wrapper.restart.reload_configuration est définie à TRUE (FALSE par défaut). Lorsque ces fichiers sont rechargés, le Wrapper vérifie s'ils contiennent des données sensibles et, le cas échéant, s'arrêtera si les permissions du fichier sont trop ouvertes.

Pour empêcher la divulgation de données sensibles dans les journaux, e-mails, lignes de commande, environnement, etc., les modifications suivantes ont été apportées :

• Les jetons de chiffrement (%...|mask%, %...|obf%, etc.) ne sont pas autorisés dans les valeurs des propriétés de ligne de commande ni des propriétés à intégrer dans les binaires à l'aide de la commande --customize.

• Les jetons de chiffrement ne peuvent être référencés que dans les valeurs d'un ensemble prédéfini de propriétés : wrapper.app.property.<n>, wrapper.app.parameter.<n> et wrapper.*.password. Par défaut, ces propriétés ne sont plus partagées avec la JVM sauf si wrapper.java.share_configuration est défini à 'ALL'.

• Les paramètres d'application et les propriétés système contenant des données sensibles ne sont pas autorisés à apparaître sur la ligne de commande et doivent être transmis via le tube ou le socket backend interne. Ils ne seront déchiffrés qu'après avoir été reçus par la JVM. Pour que les paramètres d'application soient transmis via le backend, wrapper.app.parameter.backend doit être défini à TRUE.

• Les propriétés wrapper.*.password dont les valeurs ne sont pas protégées par un chiffrement généreront un avertissement dont le niveau de journalisation peut être contrôlé avec wrapper.password_warning.loglevel.

Le mode PIPE pour la communication backend entre le Wrapper et la JVM utilise désormais des tubes anonymes au lieu de tubes nommés sous Unix, et leurs droits d'accès ont été restreints au propriétaire uniquement.

Les caractères pourcentage '%' dans les valeurs de variables sont échappés pendant le processus d'évaluation des variables afin d'éviter qu'ils soient interprétés comme des délimiteurs et provoquent ainsi une détection erronée de variables. L'évaluation des variables a également été rendue plus efficace.

Introduction d'une nouvelle syntaxe pour les directives. Elles commencent désormais par le caractère '@' au lieu de '#' pour les distinguer des commentaires. L'ancienne syntaxe reste prise en charge pour la rétrocompatibilité.

Ajout d'une nouvelle directive @include.default_mode pour contrôler si les inclusions de fichiers sont obligatoires ou facultatives par défaut. Le mode par défaut est 'optional' pour la rétrocompatibilité, mais 'required' est préféré pour les fichiers d'inclusion dont le but est de contenir des données sensibles. En plus de la directive existante @include.required, une nouvelle directive @include.optional a été ajoutée pour contrôler le mode d'inclusion d'un fichier spécifique.

Modification de la portée de @include.debug, @properties.on_overwrite.exit et @properties.on_overwrite.loglevel pour n'affecter que le fichier de configuration courant et ses fichiers enfants inclus, et non plus le(s) fichier(s) parent(s). La même portée s'applique lors de l'utilisation de @include.default_mode.

Correction des messages de journal dupliqués lorsqu'un fichier d'inclusion obligatoire n'a pas pu être chargé.

Une déclaration @encoding invalide ou non prise en charge en tête d'une configuration est désormais considérée comme une erreur fatale et provoque l'arrêt du Wrapper. Auparavant, le chargement de la configuration continuait si le fichier était facultatif. Correction également de la notation d'encodage dans le message d'erreur, qui s'affichait sous forme de caractères illisibles sous Windows.

La directive @variables.expand peut désormais être utilisée dans les fichiers de paramètres.

Diverses autres améliorations (efficacité, sécurité, messages de journalisation, etc.) lors de la lecture des fichiers de configuration et des fichiers de paramètres.

Amélioration du message journalisé par le script shell Unix si le Wrapper n'a pas réussi à démarrer en raison d'une erreur de chargement de la configuration. Le message inclut le chemin vers le fichier journal par défaut, où des informations supplémentaires sont disponibles.

Amélioration du message journalisé lorsqu'une commande de lancement invalide est spécifiée.

Prise en charge des espaces dans le chemin du répertoire de travail (script shell Unix).

Ajout des nouvelles propriétés wrapper.system.library.path.<n> pour définir les chemins vers les bibliothèques natives qui sont chargées depuis d'autres bibliothèques natives (et non directement par Java). Auparavant, il était possible de définir les variables d'environnement PATH, LD_LIBRARY_PATH ou DYLD_LIBRARY_PATH pour obtenir le même résultat, mais cela nécessitait des définitions plus complexes pour être multiplateforme.

Correction d'un problème sous macOS lorsque wrapper.java.library.path.append_system_path était défini à TRUE. LD_LIBRARY_PATH était utilisée pour récupérer les chemins vers les bibliothèques dynamiques depuis l'environnement, mais la variable couramment utilisée sous macOS est DYLD_LIBRARY_PATH. Comme LD_LIBRARY_PATH est également utilisée pour la compatibilité avec Unix, le Wrapper ajoute désormais le contenu des deux variables lorsqu'elles sont définies.

Correction d'un problème où des caractères pourcentage '%' non fermés ou des références de variables non définies dans les paramètres d'application ou dans les arguments de commande d'événement pouvaient conduire à un pointeur dangling. Ce problème avait été corrigé pour les propriétés wrapper.java.additional.<n> dans la version 3.5.18, mais affectait encore les paramètres / arguments mentionnés précédemment.

Ajout de la nouvelle propriété wrapper.java.command.<platform>.format pour modifier le format utilisé lors de l'affichage de la ligne de commande Java. Sur les systèmes Unix, le format par défaut devient « LINE », qui affiche la commande sur une seule ligne au lieu de l'afficher sous forme de tableau comme dans les versions précédentes. Sous Windows, les arguments contenant des caractères spéciaux seront mis entre guillemets. De plus, un nouveau format 'POWERSHELL' a été ajouté pour formater la commande pour PowerShell. Ces modifications facilitent la copie de la commande et son exécution dans un terminal pour les tests.

Ajout de la nouvelle propriété wrapper.java.command.show_backend_properties. La valeur par défaut est FALSE, ce qui masquera les propriétés backend transmises à la JVM. Cela est fait pour faciliter la copie de la ligne de commande en vue d'une exécution sans le Wrapper.

Le classpath, le module_path et les autres arguments de modules ont été déplacés juste avant la classe principale dans la ligne de commande pour plus de clarté.

Modification de la façon dont WrapperSimpleApp, WrapperStartStopApp et WrapperJarApp démarrent l'application. Elle n'est plus démarrée dans le constructeur. Si ces classes sont étendues par du code utilisateur, elles nécessiteront une modification.

Ajout de la détection des Comptes de service gérés délégués (dMSA) introduits dans Windows Server 2025.

Suppression de l'erreur « Failed to validate HostIds » signalée lors de l'exécution du Wrapper dans un conteneur Windows sur Docker.

Suppression d'un message trompeur sous Windows lorsque la page de codes ANSI du système était codée sur quatre octets (par exemple 65001). Il s'agissait d'un message de débogage, mais comme il était journalisé avant le chargement de la configuration, le niveau de journalisation était ignoré.

Correction de la vérification du numéro de version de wrapper.jar qui était ignorée lorsque la version du jar était antérieure à 3.5.60. Ce problème était causé par l'ajout d'un préfixe dans la sortie de la classe Bootstrap dans la version 3.5.60. Dans le cas où la version du fichier jar ne correspond pas à la version du binaire natif, le Wrapper s'arrêtait toujours comme il le devait, mais un message plus précis est désormais journalisé.

Correction de la mise à l'échelle de l'interface graphique de l'application TestWrapper sous Windows 11.

Correction d'un problème de premier affichage de l'interface graphique de l'application TestWrapper sous macOS.

Correction d'un problème sous Windows où le Wrapper pouvait rencontrer une erreur « Access is denied » en tentant de tuer le processus Java, et ensuite annuler les redémarrages planifiés. Cela se produisait dans de rares conditions de course si la demande d'arrêt du Wrapper intervenait juste après que le système ait déjà initié l'arrêt. Depuis la version 3.5.52, le Wrapper tente d'être plus réactif pour redémarrer la JVM lorsque la communication backend est interrompue, ce qui rend plus probable la rencontre de cette erreur.

Amélioration du comportement en cas d'échec de lecture (ou d'écriture) sur le tube ou le socket connecté à la JVM. Dans de tels cas où le Wrapper n'est plus en mesure de surveiller la JVM, la connexion est fermée et un arrêt propre est initié par le code Java. Le Wrapper accordera ensuite le nombre de secondes défini dans wrapper.jvm_exit.timeout pour que le processus se termine. L'édition Professional déclenchera l'événement jvm_unexpected_exit si la JVM se termine effectivement d'elle-même. Plusieurs autres améliorations ont été apportées, telles qu'une plus grande clarté des messages de journal et une meilleure gestion des erreurs pouvant survenir pendant le handshake après l'établissement de la connexion.

Ne plus déclencher l'événement jvm_unexpected_exit lorsqu'un arrêt forcé est initié par un double CTRL-C.

Ajout de la nouvelle propriété wrapper.stats_on_unexpected_jvm_exit pour afficher les statistiques de performance chaque fois que la JVM se termine de manière inattendue.

Ignorer wrapper.request_thread_dump_on_failed_jvm_exit et wrapper.request_thread_dump_on_failed_jvm_exit.delay lorsque la JVM est tuée à la suite d'un timeout de ping. Cela signifie que la JVM ne répond plus et ne pourra de toute façon pas traiter le dump de threads.

Correction d'une fuite mémoire mineure sur les systèmes Unix lorsque wrapper.backend.type était défini à 'PIPE'. Elle se produisait à chaque redémarrage de la JVM.

Dépréciation de wrapper.java.additional.<n>.app_only au profit de wrapper.java.additional.<n>.scope pour permettre de spécifier si une option donnée doit être transmise uniquement à l'application (APP), à la fois à l'instance --dry-run et à l'application (DRYRUN_APP), ou à l'instance bootstrap, l'instance --dry-run et l'application (BOOSTRAP_DRYRUN_APP). Cela est utile pour les cas particuliers où des arguments supplémentaires sont requis par l'étape de bootstrap afin de charger la classe principale. Les options de classpath et de chemin de modules sont forcées à toujours rester synchronisées entre les trois lignes de commande.

Amélioration de l'étape de bootstrap en étant plus précise en cas d'erreurs, et ajout d'un préfixe pour s'assurer que seule la sortie de la classe WrapperBootstrap est analysée.

Ajout d'une vérification pour s'assurer que les noms de modules spécifiés avec wrapper.java.module.<n> ne contiennent pas d'espaces, car cela générerait une ligne de commande invalide.

Correction d'un plantage se produisant dans de rares occasions lors du remplacement du nom du fabricant du binaire avec la commande --customize.

Implémentation de la méthode WrapperProcessInputStream.available() pour permettre de voir si une sortie est disponible avant d'appeler read.

Correction de l'extension de fichier dans le message affiché lorsque la bibliothèque native de la distribution « universal » macOS n'a pas pu être chargée. Cette distribution est livrée avec une bibliothèque '.jnilib' pour la rétrocompatibilité avec les anciennes versions de Java, mais le Wrapper avec Java 7 et versions ultérieures référençait la bibliothèque native avec une extension « .dylib ».

Correction de wrapper.java.classpath.1 qui n'était pas défini pour DemoApp, provoquant une erreur où la classe principale n'était pas trouvée. Depuis la version 3.5.55.

Correction d'un problème qui empêchait le démarrage pendant l'étape de bootstrap si la classe principale de l'application contenait une référence statique à la classe WrapperManager.

Permettre d'appeler WrapperManager.fireUserEvent(int) jusqu'au moment où le backend a été fermé. Auparavant, cela n'était possible que jusqu'au début du processus d'arrêt.

Permettre d'appeler WrapperManager.exec() jusqu'au moment où le backend a été fermé. Auparavant, cela n'était possible que jusqu'au début du processus d'arrêt. L'appel à WrapperManager.exec() sera également désormais possible jusqu'à l'arrêt de la JVM si l'indicateur detached de WrapperManagerConfig est true.

Permettre de créer de nouvelles instances WrapperProcessConfig à tout moment. Auparavant, une exception était levée une fois le processus d'arrêt commencé.

Modification de WrapperManager.isNativeLibraryOk() afin qu'elle ne renvoie plus false une fois l'arrêt commencé.

Correction d'un problème où la méthode WrapperProcess.dispose() pouvait échouer à terminer le processus enfant pendant l'arrêt. Cela entraînait la non-fermeture des tubes stderr et stdout. WrapperProcess.isAlive() renvoyait correctement true dans ce cas.

Désactiver SeImpersonatePrivilege lors de l'exécution en tant que service Windows avec un compte autre que NT AUTHORITY\SYSTEM. Ce privilège est automatiquement ajouté par le gestionnaire de contrôle des services (SCM) via l'ajout dynamique du groupe SERVICE lorsqu'un service est démarré, mais peut soulever des préoccupations de sécurité car du code malveillant exploitant des vulnérabilités dans la hiérarchie des processus Java pourrait en abuser pour s'élever au compte LocalSystem qui possède le plus haut niveau de privilèges sur un système Windows. Étant donné que la plupart des applications Java n'ont pas besoin de ce privilège, il a été décidé de le supprimer par défaut. Si nécessaire, la propriété wrapper.ntservice.impersonation peut être utilisée pour le réactiver.

Corriger la latence lors de l'installation d'un service Windows et lors de la demande du mot de passe pour le compte du service. Améliorer également les vérifications pour s'assurer que le compte configuré existe.

Corriger un bug où wrapper.ntservice.account.prompt n'écrasait pas la propriété wrapper.ntservice.password.prompt à TRUE. Cela entraînait que le mot de passe n'était pas demandé sauf si cette dernière propriété était définie manuellement.

Supprimer l'avertissement "Update can not be used to change the wrapper.ntservice.account value." affiché lors de la mise à jour d'un service avec la propriété wrapper.ntservice.account.prompt définie à TRUE.

Les invocations de "wrapperm" utilisées pour contrôler le Wrapper en tant que service désactivent désormais par défaut la journalisation dans un fichier et dans le Journal des événements. Ces destinations de journalisation peuvent être réactivées à l'aide des propriétés wrapper.wrapperm.logfile.enable et wrapper.wrapperm.syslog.enable.

Les invocations de "wrapperm" ignorent désormais wrapper.logfile.close.timeout et ferment toujours le fichier journal après l'écriture de chaque entrée sur le disque. Cela contourne un problème où l'instance wrapperm pouvait bloquer le fichier journal, empêchant le service en cours d'exécution d'y accéder. Un échec d'accès pouvait également empêcher la rotation du journal.

Résoudre le compte de manière plus fiable lors de l'exécution en tant que service. Au lieu d'utiliser la valeur de wrapper.ntservice.account, qui pouvait être incorrecte si sa valeur avait été modifiée depuis l'installation du service ou si wrapper.ntservice.account.prompt était utilisé, le Wrapper utilise désormais le domaine et l'utilisateur auxquels appartient le processus actuel. L'ancienne méthode, en plus de potentiellement causer l'affichage incorrect du compte dans les journaux, pouvait également causer des problèmes de compatibilité avec les propriétés wrapper.share.<n>.account.

Améliorer le comportement et les messages de journalisation lorsqu'un service Windows ne parvient pas à démarrer en raison d'une erreur critique dans le fichier de configuration. Auparavant, le Wrapper signalait que le service n'avait pas réussi à démarrer avec l'erreur système "The service did not respond to the start or control request in a timely fashion.", ce qui était inexact.

Afficher des messages explicatifs lorsque le service ne parvient pas à écrire dans le fichier configuré et/ou le fichier journal par défaut au démarrage (Windows). De telles erreurs pouvaient être difficiles à remarquer lorsque seul le compte utilisé par le service n'avait pas les permissions d'écriture sur ces fichiers car aucune erreur n'était affichée sur la console. Supprimer également un message non formaté affiché lorsque "wrapperm" n'avait pas les permissions sur le fichier journal.

Corriger un bug où les anciens fichiers générés lors de la rotation du fichier journal par défaut dans le répertoire de travail n'étaient pas purgés. Normalement, un seul fichier renommé devrait être conservé.

Corriger un bug lorsque le fichier journal était rotaté par taille et date et contenait un jeton ROLLNUM dans son nom. Les premiers fichiers journaux de chaque date, qui ne contenaient pas de numéro de rotation, n'étaient pas purgés.

Ajouter des vérifications supplémentaires au démarrage du Wrapper pour détecter les erreurs de configuration dans les propriétés qui définissent les privilèges pour le processus Java et les commandes d'événements. Auparavant, les vérifications étaient effectuées juste avant le lancement de ces processus et tout privilège mal configuré entraînait l'abandon de leur exécution par précaution, mais il est préférable de détecter ces erreurs le plus tôt possible.

Corriger le nom de l'exécutable pour les commandes d'événements dans le dump des privilèges.

Ajouter une commande 'privileges' au script batch Windows AppCommand.bat.in pour interroger les privilèges du service.

Corriger un problème où les en-têtes de mail étaient malformés lorsque wrapper.event.<event_name>.email.maillog était INLINE. La plupart des serveurs de mail acceptaient silencieusement le mail, mais certains serveurs de mail pointilleux rejetaient les mails avec l'erreur "554 Transaction failed: Invalid Base 64 stream".

Ajouter wrapper.app.property.<n> et wrapper.app.property_file pour définir des propriétés spécifiques à l'application sans les exposer dans la ligne de commande Java. L'utilisation de cette nouvelle configuration est recommandée pour transmettre des données sensibles telles que des mots de passe à votre application Java.

Ajouter une nouvelle syntaxe %...|mask% pour masquer des portions de texte du fichier de configuration dans la sortie du journal.

Ajouter de nouvelles propriétés wrapper.java.additional.<n>.app_only qui peuvent être utilisées pour omettre certaines options pour la ligne de commande "--dry-run". Un cas d'utilisation est d'omettre l'option -XX:NativeMemoryTracking qui provoque un avertissement lorsqu'elle est utilisée avec l'option --dry-run.

Corriger le niveau de journalisation de la sortie JVM de l'invocation --dry-run : utiliser la valeur de wrapper.java.query.loglevel (DEBUG par défaut) si le processus se termine en temps voulu et avec un code de sortie de 0.

Corriger un problème sur certaines plateformes Unix où l'appel de WrapperManager.log() avec une sortie contenant un caractère '%' pouvait provoquer un plantage du processus Wrapper.

Les informations "Operating System ID" affichées en mode debug prennent désormais en charge les versions récentes de Windows (Windows 11 et Server 2019, 2022).

Améliorer les messages affichés lorsqu'une clé de licence est invalide.

Corriger l'encodage du fichier de configuration modèle src/conf/wrapper.conf.in_ja pour utiliser désormais UTF-8.

Corriger la commande 'wrapper -h' qui ne renvoyait aucun HostId dans les environnements s'exécutant sur IBM Power Systems.

Ajouter une nouvelle commande USER_{n} au fichier de commandes pour déclencher un événement utilisateur.

Ajouter plusieurs propriétés pour configurer les privilèges sous Windows. Les privilèges peuvent d'abord être configurés lors de l'installation d'un service, puis ajustés à l'exécution pour le processus Wrapper, le processus Java et les commandes d'événements.

Ajouter une nouvelle commande -qr[=serviceName] à la version Windows du Wrapper pour interroger l'état des privilèges du service actuellement installé. Optionnellement, un nom de service peut être spécifié pour interroger un service différent.

Commencer à encoder en Base64 le corps et le fichier journal joint dans les e-mails d'événements. Cela résout des problèmes avec certains serveurs qui rejetaient les e-mails en raison de lignes individuelles trop longues. Cela pouvait arriver occasionnellement en raison d'une longue sortie de la JVM. Le sujet était déjà encodé en Base64.

Supprimer un séparateur final superflu dans le contenu de l'e-mail lorsque wrapper.event.<event_name>.email.maillog est défini à NONE.

Mettre à niveau le certificat EV utilisé pour signer les binaires Windows, les installeurs et les fichiers jar.

Forcer wrapper.java.query.loglevel à être au moins DEBUG pour faciliter les demandes de support.

Corriger le niveau de journalisation auquel la commande 'java -version' est affichée lorsque wrapper.java.version.output est défini à TRUE. Le niveau de journalisation de la commande peut être contrôlé avec la propriété wrapper.java.query.loglevel.

Corriger le niveau de journalisation de la sortie JVM de l'appel bootstrap. Dans la version 3.5.55, le niveau de journalisation était élevé à INFO ou ERROR si une sortie inattendue était trouvée. Désormais le Wrapper attend également de voir si le processus se termine avec un code d'erreur ou ne répond pas avant de changer le niveau de journalisation.

Corriger un bug introduit dans la version 3.5.55 faisant que %WRAPPER_HOSTNAME% n'était pas développé dans les valeurs par défaut des propriétés wrapper.event.*.email.subject et wrapper.event.*.email.body. Définir manuellement ces propriétés dans le fichier de configuration résolvait ce problème.

Les binaires Windows et le fichier wrapper.jar de cette version sont signés avec un certificat qui a été révoqué en raison d'un problème lors de son émission. Les binaires du Wrapper sont corrects et sûrs à exécuter, mais pour éviter toute confusion, il a été décidé de ne plus fournir les distributions Windows pour cette version. Veuillez utiliser la version 3.5.56, qui est signée avec un certificat EV mis à niveau.

Ajouter de nouveaux ensembles de propriétés wrapper.java.module_path.<n>, wrapper.java.upgrade_module_path.<n> et wrapper.java.module.<n> pour simplifier la configuration des modules Java (nécessite Java version 9 ou supérieure).

Ajouter un descripteur de module à wrapper.jar. Les applications utilisant Java 9 et supérieur peuvent utiliser le nouveau module 'org.tanukisoftware.wrapper', qui, étant un module nommé, permet l'inclusion de wrapper.jar dans des images d'exécution personnalisées, en utilisant jlink. Avec les versions plus anciennes de Java, le descripteur de module est simplement ignoré.

Ajouter une nouvelle propriété wrapper.jarfile pour spécifier l'emplacement de wrapper.jar. Cette propriété permet au Wrapper d'identifier son fichier jar de manière plus fiable et de le référencer soit dans le classpath, soit dans le module path. wrapper.jarfile est obligatoire lors de l'utilisation de modules.

Ajouter de nouvelles étapes avant le lancement de l'application Java pour aider à préparer la ligne de commande Java et détecter les problèmes de syntaxe tôt. La première étape est une requête à la classe 'org.tanukisoftware.wrapper.bootstrap.WrapperBootstrap', tandis que la deuxième étape est l'exécution de la ligne de commande Java avec l'option --dry-run. La sortie peut être contrôlée avec la propriété wrapper.java.query.loglevel.

Ajouter la possibilité d'interrompre les appels "java -version", "bootstrap" et "--dry-run" avec des signaux tels que CTRL-C ou CTRL-CLOSE s'ils sont lents à se terminer.

Ajouter une nouvelle directive #variables.expand pour activer ou désactiver l'expansion des variables pour des sections du fichier de configuration.

Désactiver automatiquement les vérifications de deadlock lorsque le module java.management n'est pas disponible. Cela peut se produire avec des images d'exécution personnalisées. Auparavant, la JVM s'arrêtait avec une erreur "Server daemon died!".

Améliorer la collecte des statistiques de performance et corriger une fuite mémoire mineure.

Améliorer le comportement lorsque le processus Java est terminé de force par un processus externe ou lorsque la communication backend entre le Wrapper et sa JVM contrôlée est interrompue.

Sous Windows, la ligne de commande du service est désormais générée en utilisant des chemins longs pour le binaire Wrapper et le fichier de configuration. Cela a été fait parce que certaines tâches sous Windows peuvent convertir les chemins courts en leur forme longue dans le registre, ce qui peut introduire des espaces dans des chemins non quotés, causant des lignes de commande avec des arguments invalides. Si un service a été installé avec une version du Wrapper antérieure à 3.5.55, et que la ligne de commande contient des chemins courts non quotés, un avertissement recommandera de réinstaller le service.

Corriger la propriété wrapper.ntservice.preshutdown qui était ignorée sous Windows. Depuis 3.5.42.

Corriger les avertissements concernant les variables d'environnement non définies qui n'étaient pas signalés lorsqu'elles étaient utilisées dans les valeurs de listes de propriétés.

Corriger un problème où le fait de définir wrapper.disable_console_input à TRUE empêchait le processus Java de se lancer en tant que leader de groupe, résultant en une gestion des signaux moins cohérente (par ex. un double dump de threads déclenché en réponse à un signal QUIT).

Restaurer les vérifications (introduites dans 3.5.0 et désactivées dans 3.5.5) pour afficher une erreur et empêcher le Wrapper de démarrer si les scripts batch ou shell utilisés sont basés sur l'application de démonstration TestWrapper.

Ajouter un avertissement lorsqu'une ancienne version d'un script batch Windows est utilisée pour démarrer le Wrapper (auparavant cet avertissement n'existait que pour le script shell Unix). Sous Unix, la version du script était auparavant transmise via une propriété de ligne de commande, mais une variable d'environnement est désormais utilisée pour limiter la taille de la ligne de commande.

Corriger un problème où le fichier de configuration d'unité pour systemd était créé en utilisant la valeur de la variable APP_NAME déclarée dans le script shell principal, ignorant toute redéfinition de la variable dans le fichier .shconf. Lorsque la valeur de APP_NAME différait entre les deux scripts, cela provoquait l'échec de l'installation ou de la suppression du service. Depuis 3.5.47.

Corriger les cas où la sortie du Wrapper était dupliquée dans la sortie de la JVM lors de l'exécution dans Docker.

Augmenter la réactivité à la sortie console du processus Java. Pour éviter une utilisation élevée du CPU, le Wrapper se met en sommeil lorsqu'il n'y a pas de sortie du processus Java. La sortie de Java est stockée dans le pipe stdout jusqu'à ce qu'elle soit lue, mais provoquera le blocage du processus Java lorsqu'il est plein. Normalement ce n'était pas un problème, mais les versions plus récentes de macOS semblent avoir réduit la taille du pipe à une très petite taille.

Prise en charge de l'arrêt propre du Wrapper s'exécutant en tant que console lorsqu'il reçoit un signal CTRL+CLOSE sous Windows. Ce signal est généré lors de la fermeture de la console, soit manuellement, soit depuis le Gestionnaire des tâches. Auparavant, le processus Wrapper était simplement interrompu, le côté Java du Wrapper le détectait et demandait à l'application Java de s'arrêter proprement. Cependant, à ce stade, toute sortie de journal n'était plus capturée par le système de journalisation du Wrapper. Notez que le signal CTRL+CLOSE ne peut pas être ignoré et n'est donc pas affecté par wrapper.ignore_signals.

Changer la valeur par défaut de wrapper.jvm_terminate.timeout à 0 (ce qui signifie ne jamais expirer). Auparavant, la valeur par défaut était de 10 secondes et 5 secondes supplémentaires étaient ajoutées à la valeur configurée. Ces 5 secondes ne sont plus ajoutées, mais les valeurs inférieures à 5 secondes sont arrondies à 5 pour donner suffisamment de temps à la JVM pour se terminer dans la plupart des scénarios. Dans certaines situations rares, comme lorsque la mémoire du système est saturée, la fin du processus Java peut prendre jusqu'à plusieurs minutes. Dans de tels cas, le comportement par défaut est désormais de continuer à attendre, car l'alternative serait d'arrêter le Wrapper, ce qui anéantirait toute chance de redémarrer l'application.

Augmenter le temps d'attente avant de décider que le thread traitant stdin ne répond pas. Dans de très rares cas où le thread était lent, cela pouvait provoquer la désactivation de l'entrée console.

Commenter la déclaration de _PASS_THROUGH en haut de AppCommand.bat.in pour la rendre cohérente avec les autres modèles de scripts. Lorsqu'elle est commentée, cette variable vaut par défaut 'false', ce qui signifie que tout argument après la commande du script est ignoré. Auparavant, la valeur était 'app_args', permettant de transmettre des arguments à l'application Java. Lors de la mise à niveau du Wrapper, si votre application utilisait des arguments passthrough, veuillez décommenter la propriété pour conserver la compatibilité.

Améliorer le message rapporté lorsqu'un partage de fichiers Windows ne parvient pas à se mapper après une tentative de montage en arrière-plan.

Corriger une faute de segmentation sur les systèmes UNIX lorsque la variable d'environnement LANG n'est pas définie.

Ne pas effectuer de rotation du fichier journal lorsqu'il est vide.

Corriger un problème avec l'installeur macOS où le lien /usr/local/opt/wrapper vers la dernière version installée n'était pas créé si le répertoire /usr/local/opt n'existait pas déjà.

Améliorer le message rapporté lorsqu'un partage de fichiers Windows existe déjà et qu'il a été mappé manuellement depuis l'Explorateur de fichiers. Il s'agit d'une erreur différente de celle où le partage a été mappé depuis une invocation précédente du Wrapper.

Corriger de rares cas où le Wrapper échouait à initialiser stdin, résultant en une erreur "Bad file descriptor".

Déprécier wrapper.disable_console_input au profit de wrapper.console_input. La nouvelle propriété vaut par défaut 'AUTO', un mode qui désactive automatiquement la gestion de stdin s'il n'est pas connecté à quelque chose à lire (par ex. lorsque le Wrapper a été lancé en arrière-plan, ou lors de l'exécution dans un conteneur Docker sans TTY). Ceci afin de réduire l'utilisation du CPU.

Ajouter une vérification lors du démarrage en tant que service Windows pour s'assurer que son nom n'a pas changé dans la configuration depuis l'installation du service. Si le nom a changé, le Wrapper s'arrêtera, car cela est invalide et pourrait causer un comportement incorrect.

Corriger un problème de mapping des partages au démarrage du système causé par un échec de résolution du nom du serveur de partage juste après le démarrage du système. Cette erreur sera désormais considérée comme temporaire pendant la phase de démarrage afin que les tentatives répétées permettent au mapping de réussir. Mise en œuvre d'un moyen de continuer à essayer de mapper un partage après le démarrage du service pour permettre le cas où un serveur de partage est arrêté lorsque le service démarre. Ajout des nouvelles propriétés wrapper.share.<n>.background.retry_interval, wrapper.share.<n>.background.failure.action et wrapper.share.<n>.background.success.action. Changer la valeur par défaut de la propriété wrapper.share.<n>.startup.failure à la nouvelle valeur 'BACKGROUND'.

Lorsqu'un wrapper.share.<n>.account est spécifié mais que le service s'exécute en tant que compte système, arrêter plutôt que d'ignorer la propriété de compte. Continuer pourrait conduire à des erreurs confuses.

Changer la valeur par défaut de wrapper.share.<n>.startup.premapped à SHUTDOWN, mais désormais vérifier la ressource réseau mappée au périphérique existant et ignorer la propriété (donc continuer) si l'emplacement est le même que celui configuré.

Corriger un bug où l'écriture depuis/vers le processus élevé échouait si wrapper.lang.windows.encoding était défini à UTF-8. Cela n'était un problème que sous Windows et lorsque les identifiants Administrateur étaient demandés.

Convertir automatiquement les chemins référencés dans FILES_TO_SOURCE (dans le script shell Unix) en chemins absolus. Cela est fait pour éviter les problèmes d'accès lors de l'exécution en tant que démon où le répertoire de travail est différent de l'emplacement du script.

Améliorer la détection de systemd sous Linux (script shell).

Corriger l'ordre de liaison afin que 'lm' apparaisse après les sources dans le fichier Make Linux PPC (Community Edition).

Ajouter une commande 'permissions' au script batch Windows AppCommand.bat.in pour interroger les permissions du service.

Meilleure gestion des erreurs de socket ou de pipe qui peuvent survenir pendant la communication backend entre le Wrapper et la JVM. En cas d'erreurs qui ne peuvent pas être récupérées, le Wrapper cessera d'utiliser ces canaux et décidera plus rapidement de redémarrer la JVM.

Mettre en pause l'envoi des pings et des paquets de vérification de deadlock lorsque la JVM ne répond pas. Cela permet d'être plus léger dans les scénarios où la JVM (ou le système entier) est déjà sous forte charge, et évite d'encombrer inutilement la communication backend. Le ping reprendra dès que la JVM rattrapera son retard.

Corriger un problème où 'java -version' était laissé comme processus zombie s'il expirait.

Ajouter un nouvel ensemble de propriétés wrapper.stats* pour dumper les statistiques d'utilisation de la mémoire et du CPU pour le système, le processus Wrapper et la JVM. Uniquement sous Windows pour l'instant. La propriété wrapper.stats_on_failed_jvm_exit, qui est TRUE par défaut, provoquera le dump de statistiques rétroactives au cas où la JVM est détectée bloquée. De plus, le dump de statistiques peut être déclenché à tout moment en utilisant le mot-clé 'STATS' dans la valeur d'une propriété d'action, ou depuis le fichier de commandes.

Le Wrapper n'essaiera plus de charger un pack de langue pour ses propres messages lorsque l'anglais est utilisé. Pour plus d'efficacité et une journalisation plus claire.

Ajouter une configuration par défaut dans wrapper.conf.in pour la rotation du fichier journal.

Les distributions z/Linux sont désormais compilées sur une machine IBM z14 avec RedHat Linux 8.7 (Glibc 2.28). Suppression du support s390 31/32 bits.

Corriger un bug où certaines tâches de nettoyage liées au pipe ou socket backend (généralement effectuées entre un arrêt de la JVM et le redémarrage suivant) étaient ignorées. Cela n'était un problème que si la JVM avait planté, était figée ou si le processus Wrapper était anormalement retardé. Depuis 3.5.47.

Corriger l'échec d'installation des services Windows lors de l'utilisation d'un compte de service géré, d'un compte de service géré par groupe, ou d'un compte virtuel. Améliorer également la détection des comptes de service intégrés, qui ne nécessitent pas d'authentification.

Corriger un problème sous Windows où la propriété système 'file.encoding', si spécifiée dans les propriétés wrapper.java.additional.<n>, était écrasée.

Améliorer le comportement lorsque la commande utilisée pour demander la version Java échoue. Pour tout échec en attendant que le processus se termine, un redémarrage automatique sera planifié (car cela pourrait simplement être dû au système temporairement sous forte charge). Si, de plus, le processus ne peut pas être tué, le Wrapper s'arrêtera.

Corriger le message de statut qui ne s'affichait pas lorsque la JVM était reprise (avec SIGCONT) sous macOS.

Corriger un problème de timing où une partie de la sortie restante de la JVM était parfois affichée après confirmation que le processus JVM s'était terminé.

Augmenter la largeur des colonnes 'W' et 'J' du format de journal pour s'adapter à la taille de la valeur maximale de PID.

Changer l'ordre de liaison des Makefiles pour la Community Edition, afin que les bibliothèques apparaissent après les sources. Cela est fait pour être plus compatible avec certains lieurs, qui n'acceptent que cet ordre.

Corriger la commande 'wrapper -h' qui ne renvoyait aucun HostId sur Microsoft Azure ou les machines virtuelles Hyper-V.

Améliorer les messages affichés lorsqu'il y a un problème avec la licence, et indiquer le nom de propriété de l'identifiant de clé actuellement utilisé pour aider à identifier l'ensemble de propriétés problématique lorsque le fichier de clés de licence contient plusieurs clés.

Corriger un problème mineur de journalisation où le format 'D' affichait "unknown" pour les messages journalisés par l'instance principale du Wrapper lorsque wrapper.single_invocation.notify était défini à TRUE.

Corriger un problème où le Wrapper échouait parfois à valider le HostId de licence sur certaines installations Windows.

Corriger un bug de rotation de journal où les anciens fichiers n'étaient pas purgés au démarrage du Wrapper si le mode était WRAPPER, JVM, SIZE_OR_WRAPPER ou SIZE_OR_JVM. Depuis 3.5.45.

Mettre à jour les titres des installeurs macOS et Windows pour inclure l'architecture. Ceci afin d'éviter la confusion entre les installeurs x86 (ou universal pour macOS) et arm.

Ajouter la propriété wrapper.check_certificate.default.loglevel pour contrôler le niveau de journalisation des erreurs non critiques détectées lors de la vérification de confiance sur la chaîne de certificats construite par le Wrapper. Changer le niveau de journalisation par défaut à DEBUG.

Renforcer la sécurité lors de l'exécution sur d'anciennes versions de Windows où seul l'algorithme de hachage SHA-1 est pris en charge. Le Wrapper s'arrêtera si la signature du certificat ne peut pas être vérifiée, comme c'est le cas pour les certificats SHA-2.

Arrêter le Wrapper lorsque la contre-signature de l'horodatage de signature de code n'était pas valide.

Corriger un problème de blocage sous Windows causé par la validation du certificat plus lente que l'exécution du thread principal. Cela pouvait se produire sur des machines avec une installation de certificats incomplète, et lorsque le Wrapper s'arrêtait peu après son démarrage (par ex. lorsque la configuration est incorrecte).

Améliorer le comportement à la sortie pour attendre les threads qui sont encore en cours d'exécution pendant que le Wrapper gère encore les signaux CTRL-C, et avant d'afficher le message final "Wrapper stopped".

Corriger wrapper.startup_thread.timeout qui était quelques millisecondes plus court que configuré.

Ajouter l'option de compilation '-fPIC' manquante pour FreeBSD 32 bits (l'absence de cette option pouvait causer des erreurs dans l'exécution de la bibliothèque native).

Supprimer le message de journal redondant lorsque le chemin vers le fichier journal est soit incorrect, soit n'a pas les permissions suffisantes.

Supprimer le message de statut trompeur "JVM process is gone" qui concernait en réalité l'instance JVM lancée pour obtenir la version Java (UNIX uniquement).

Améliorer l'affichage de la colonne 'J' dans le format de journal pour n'afficher le PID du processus Java que lorsqu'il existe. Sinon "-----" est affiché.

Améliorer le comportement lors de la demande d'un dump de threads alors que le processus Java n'existe pas : ne pas envoyer de signal, et simplement journaliser un message indiquant que la JVM n'est pas en cours d'exécution.

Améliorer les messages affichés lorsqu'il y a un problème avec la licence, et indiquer l'emplacement du fichier de clé de licence actuellement utilisé pour aider lorsqu'il doit être remplacé.

Supprimer un message de debug inutile et omettre certains chargements de configuration lors du lancement du Wrapper avec une commande qui n'implique pas de JVM.

Corriger un faux positif lors de la vérification de la reprise du processus JVM si une commande d'événement se terminait pendant que le processus JVM était à l'état arrêté.

Corriger un problème potentiel où un signal SIGCHLD de la JVM pouvait être reçu par d'autres threads en cours d'exécution du Wrapper et ignoré. Cela entraînerait une détection plus lente de l'arrêt de la JVM.

Corriger des problèmes de mémoire lors de l'utilisation de wrapper.timezone ou wrapper.java.timezone. Depuis 3.5.46.

Corriger le calcul incorrect du décalage lors de l'utilisation d'un fuseau horaire au format 'UTC' si des minutes étaient spécifiées. Les horodatages détaillés affichés avec wrapper.timezone.debug_timestamps, qui montraient le décalage de l'heure système sous Windows, sont également corrigés.

Lorsque wrapper.java.timezone utilise (ou vaut par défaut) une valeur avec 'UTC', elle est désormais transmise à la ligne de commande en utilisant la notation 'GMT' correspondante pour être compatible avec Java.

Corriger une utilisation élevée du CPU observée sur certaines plateformes Unix lors de l'exécution en tant qu'application console. La plateforme Windows, ainsi que les installations en démon sous Unix ne sont pas affectées. Depuis 3.5.47. Les applications utilisant la version 3.5.48 qui n'ont pas besoin de gérer stdin peuvent contourner le problème en ajoutant wrapper.disable_console_input=TRUE à leur fichier de configuration. Cette solution de contournement n'est pas recommandée pour 3.5.47 en raison d'un autre problème (voir ci-dessous).

Réintroduire les versions Solaris SPARC dans le Delta Pack.

Corriger un problème où les architectures Linux armel et armhf (32 bits) ne chargeaient pas correctement la bibliothèque native. Cela n'était un problème que lors de l'utilisation du Delta Pack.

Corriger les installeurs Windows qui ignoraient le répertoire d'installation s'il était modifié par l'utilisateur.

Corriger un bug critique sous UNIX où le Wrapper pouvait se bloquer et échouer à redémarrer si un redémarrage de la JVM était demandé par la JVM ou le Wrapper. Cela se produisait lorsque wrapper.disable_console_input était défini à TRUE, ce qui est la valeur par défaut lors de l'exécution en tant que démon. Depuis 3.5.47.

Corriger un bug sous UNIX où les messages console étaient parfois tronqués, faisant commencer le message suivant sur la même ligne. Il s'agissait uniquement d'un problème d'affichage et n'affectait pas le fonctionnement du Wrapper. Le fichier journal n'était pas affecté. Depuis 3.5.47.

Les versions Windows n'ont pas été modifiées par rapport à 3.5.47.

Les versions Solaris SPARC qui avaient été retirées dans les versions 3.5.46 et 3.5.47 sont à nouveau disponibles. Les binaires sont désormais compilés sur Solaris 10 (précédemment Solaris 9).
Notez que cette architecture a été ajoutée quelques semaines après la sortie de 3.5.48, ce qui signifie qu'elle n'est pas incluse dans le Delta Pack. Il est possible d'ajouter manuellement les binaires aux dossiers bin et lib du Delta Pack après les avoir renommés comme suit :
wrapper-solaris-sparc-64 (ou wrapper-solaris-sparc-32) pour l'exécutable, et libwrapper-solaris-x86-64.so (ou libwrapper-solaris-x86-32.so) pour la bibliothèque native.
Le Wrapper les chargera correctement lors de l'exécution sur une machine SPARC.
Les binaires SPARC seront inclus dans le Delta Pack dans les versions futures.

Correction d'un bug où le paramétrage de wrapper.share.<n>.startup.premapped ou wrapper.share.<n>.startup.failure à 'SHUTDOWN' annulait l'action spécifiée par wrapper.on_exit.<n>. Depuis la version 3.5.30.

Correction de l'exception 'Invalid permission eventType: "serviceremote control"' lors de l'utilisation d'un Security Manager. Le Security Manager a toutefois été déprécié depuis Java 17 et son utilisation n'est plus recommandée.

Correction du code de retour incorrect des scripts batch Windows en cas de problème.

Sous Windows, Oracle Java version 12 et supérieure commence à utiliser la page de codes par défaut de la langue de l'interface utilisateur (au lieu de la page de codes ANSI Windows par défaut). Le Wrapper ajoutera la propriété système 'file.encoding' à la ligne de commande afin de pouvoir afficher correctement la sortie Java quelle que soit la version de Java.

Refonte de l'initialisation du script shell Unix : validation améliorée des arguments de démarrage, meilleur contrôle de l'utilisateur et des permissions, etc.

Amélioration du script shell afin qu'il mette désormais à jour son contexte SELinux (type vers 'bin_t') lors de l'installation en tant que démon systemd, et le restaure lors de la suppression de l'unité. Ceci est nécessaire pour être autorisé à démarrer, et n'est effectué que lorsque SELinux est activé.

Amélioration du message pour indiquer le(s) fichier(s) journal du Wrapper lorsque le Wrapper est lancé depuis le script shell et échoue à démarrer.

Dépréciation du paramètre SU_BIN du script shell Unix. La commande de substitution d'utilisateur est désormais résolue en 'runuser' lorsqu'elle est présente sur le système, et se rabat sur 'su' sinon. Ce comportement est indépendant du type de démarrage (console ou démon). De plus, la fonctionnalité RUN_AS_USER vérifiera désormais toujours que l'utilisateur root est utilisé.

Amélioration de la gestion des signaux envoyés au groupe de processus du script afin qu'ils soient transmis au Wrapper et traités en synchronisation avec celui-ci. Cela fonctionne à la fois lors d'une exécution normale ou en tant qu'utilisateur de substitution. En particulier, cela permet d'envoyer des demandes d'interruption avec CTRL-C dans le shell lors de l'exécution en tant qu'utilisateur, mais garantit également que le script ne se termine jamais en laissant le processus Wrapper s'exécuter en arrière-plan. Lorsque l'on ne cible pas un groupe de processus, il est conseillé d'envoyer les signaux directement au processus Wrapper.

Lancement de Java dans un nouveau groupe de processus. Cela permet au Wrapper de gérer les signaux de manière plus cohérente et résout des problèmes tels que le double thread dump se produisant lors de l'appui sur CTRL-\ ou de l'envoi d'un signal QUIT au groupe de processus (UNIX).

Ajout de nouvelles propriétés wrapper.event.<event_name>.command.new_process_group pour contrôler si les commandes d'événement doivent être lancées dans de nouveaux groupes de processus.

Ajout d'une nouvelle méthode setAutoCloseInputStreams() à la classe WrapperProcessConfig pour permettre de contrôler le mode de lecture des pipes des processus enfants. La valeur par défaut est désormais "true" pour UNIX. Elle était effectivement "false" pour les versions précédentes, ce qui provoquait le blocage du flux d'entrée si des processus sous-enfants utilisaient encore les pipes, ou dans certains cas où le processus enfant direct plantait.

Délais d'attente plus précis lors de l'utilisation de WrapperProcess.destroy() et de meilleures performances pour WrapperProcess.waitFor().

Correction d'une exception levée sous Windows lors du lancement d'un processus enfant si le répertoire de travail avait été modifié.

Amélioration du nettoyage des groupes de processus enfants surveillés lorsque leur chef de groupe est terminé mais que d'autres membres sont encore en cours d'exécution. Le Wrapper s'assurera que le statut du groupe est au moins vérifié toutes les 5 secondes.

Correction d'un problème où l'application TestWrapper en mode console continuait à demander une action dans une boucle infinie si le flux d'entrée était fermé.

Les distributions z/OS ne sont pas disponibles pour cette version. Veuillez nous contacter si vous en avez besoin, car nous pourrons peut-être les fournir ultérieurement.

Ajout de nouveaux installateurs signés pour Windows.

Ajout de nouvelles versions Apple silicon "aarch64".

Ajout de nouvelles versions FreeBSD ARM 64 bits (aarch64). Compilées sur FreeBSD 13.0.

Changement du nom d'architecture en "arm" pour linux 64 bits. "armhf" est toujours utilisé pour les distributions 32 bits afin de les différencier de "armel".

Arrêt de la fourniture de nouvelles versions pour Solaris SPARC. Aucune utilisation n'a été signalée récemment. Veuillez nous contacter s'il y a un besoin pour cette plateforme.

Ajout de vérifications supplémentaires pour os.arch sur macOS afin que seules les architectures prises en charge "ppc", "ppc64", "x86" et "x86_64" soient mappées vers l'architecture "universal".

Ajout d'une nouvelle propriété wrapper.java.timezone pour permettre de remplacer la valeur de wrapper.timezone et de configurer un fuseau horaire différent pour l'application Java. Ajout également de la valeur 'SYSTEM' pour permettre à ces propriétés d'être définies avec le fuseau horaire local du système.

Toujours s'assurer de restaurer la valeur de la variable d'environnement TZ définie par le Wrapper avant de lancer la JVM.

Correction d'un conseil signalé à tort lors de l'utilisation de 'UTC' pour la valeur de wrapper.timezone.

Ajout d'une nouvelle méthode setNewProcessGroup() à la classe WrapperProcessConfig pour permettre de contrôler si les processus enfants seront ou non assignés à un nouveau groupe de processus (PGID). La valeur par défaut est désormais true pour UNIX. Elle était effectivement false pour les versions précédentes, ce qui rendait facile de se retrouver avec des processus orphelins lancés indirectement, par exemple via un processus bash intermédiaire.

L'arrêt des processus enfants à la sortie du Wrapper, ainsi que lors de l'appel à WrapperProcess.dispose(), attendait le délai d'arrêt progressif après avoir tenté d'envoyer un CTRL-C à un processus enfant console. En raison du fonctionnement de l'API Windows, ces signaux CTRL-C ne seront jamais vus par le processus enfant, et le délai d'attente sera toujours utilisé. Pour éviter ce retard, le Wrapper termine désormais immédiatement les processus console, car c'était de toute façon toujours le résultat final. Cela sera réexaminé si un moyen d'envoyer le signal CTRL-C peut être implémenté. Les processus Windows sont invités à s'arrêter proprement, puis le délai d'attente est utilisé pour attendre qu'ils se terminent correctement.

Ajout de la méthode WrapperProcessConfig.getSoftShutdownTimeout() pour plus de cohérence.

Correction d'une fuite mémoire lors du lancement d'un processus enfant avec POSIX_SPAWN. Amélioration également des méthodes FORK_EXEC et VFORK_EXEC pour terminer proprement le processus enfant en cas d'erreur lors de sa création.

Ajout de la prise en charge du type de démarrage POSIX_SPAWN pour les processus enfants sur FreeBSD 8+.

Correction de la sortie de journal des processus enfants qui n'était pas affichée sur z/OS et amélioration des performances sur les autres plateformes.

Correction d'un message d'avertissement sur les plateformes UNIX où le Wrapper signalait qu'une commande d'événement s'était terminée de manière inattendue si wrapper.event.<event_name>.command.block.timeout valait 0. La commande se terminait autrement correctement. Les délais d'attente positifs fonctionnaient correctement.

Correction des fichiers jar signés avec un ancien certificat de signature de code (expirant le 2020-12-15 mais avec un horodatage valide jusqu'au 2027-06-27). Le nouveau certificat est le même que celui utilisé pour signer les binaires Windows et expire le 2023-11-19 avec un horodatage valide jusqu'au 2031-01-06.

Correction d'un chemin incorrect vers la commande id dans le script shell. Cela causait principalement un problème lors de l'utilisation de RUN_AS_USER sur Solaris. Le démon srcmstr doit être réinstallé après la mise à niveau du Wrapper.

Correction d'un problème où aucun HostId n'était listé lors de l'utilisation du teaming NIC sur Windows Server.

Normalisation des chemins utilisés dans le script shell Unix. Les chemins non normalisés provoquaient l'échec de certaines commandes systemd.

Correction du code de sortie qui n'était pas défini sur une erreur (valeur de wrapper.exit_code.error) lorsque la JVM est tuée parce qu'elle ne répond plus pendant l'arrêt.

Correction de l'interface graphique de l'application de démonstration qui n'était pas mise à l'échelle correctement avec Java 9+ sous Windows. Si vous utilisiez WrapperManager.nativeGetDpiScale(), vous devrez peut-être faire précéder son appel de WrapperManager.nativeGetDpiAwareness() pour récupérer la sensibilité dpi du processus, et WrapperManager.nativeSetDpiAwareness() pour la définir à une valeur différente.

Sous Windows, bascule automatiquement vers la surveillance du processus Java lorsqu'il est redirigé depuis le processus lancé par le Wrapper. Utilisez wrapper.java.monitor=LAUNCHED pour restaurer le comportement précédent et surveiller le processus lancé à la place.

Ajout de wrapper.java.monitor.redirect.loglevel pour contrôler le niveau de journalisation des messages affichés si une redirection du processus Java est détectée et lorsque le processus surveillé change.

Correction du niveau de journalisation de certains avertissements de propriétés. Utilise la valeur de wrapper.property_warning.loglevel.

Correction d'un problème où le Wrapper pouvait planter en tentant de formater un message. Cela a été observé lorsque la JVM renvoyait un code de sortie négatif.

Correction de 'wrapper -h' renvoyant "No valid HostId(s)" sur z/OS.

Amélioration des traductions allemandes.

Correction d'un problème où les binaires Windows n'étaient pas signés correctement dans la version 3.5.44. Ajout de vérifications supplémentaires.

Correction d'une erreur d'analyse provoquant le blocage du Wrapper au démarrage si le fichier 'etcetera' (faisant partie de la base de données tz de l'IANA) était présent à l'emplacement spécifié par wrapper.timezone.folder. La suppression de ce fichier résolvait le problème.

Ajout de la prise en charge des encodages ajoutés dans Java 11 (ISO-8859-16, x-Big5-HKSCS-2001, x-IBM1129, x-IBM1166, x-IBM1364, x-IBM833, x-MS932_0213, x-MS950-HKSCS-XP).

Correction d'un problème où le Wrapper échouait à démarrer si le script shell se trouvait sur un chemin contenant plusieurs espaces consécutifs. (Bug #311)

Lors de la compilation des tests (Community Edition), vérification de la présence d'un moteur Javascript au lieu de supposer sa disponibilité en fonction de la version de Java. Si aucun moteur intégré n'est trouvé, un moteur externe peut être spécifié en définissant la propriété 'external.js.engine.dir' lors de l'appel à Ant. (Bug #313)

Ajout d'un nouveau paramètre _WRAPPER_TIMEOUT dans les scripts batch Windows qui permet de contrôler le nombre maximal de secondes de pause à la sortie lorsqu'il y a un problème. (Feature #136)

Permet de compiler la Community Edition avec Java 10+ en utilisant automatiquement 'javac -h' au lieu de 'javah'. (Bug #312)

Utilisation de la valeur de javac.target.version dans default.properties (fichier Ant) comme version minimale de Java prise en charge par le Wrapper au lieu d'une valeur codée en dur (utile lors de la compilation de la Community Edition).

N'affiche plus d'avertissement lorsque Java est lancé via un script. À la place, le Wrapper vérifiera que le PID Java est celui attendu pour confirmer que Java a été lancé correctement.

Correction d'un problème où le Wrapper affichait une erreur au démarrage si le pipe stdin n'était pas lié à une fenêtre de console. Cela peut se produire lors d'un appel depuis d'autres programmes. Depuis la version 3.5.43.

Modification de DemoApp afin que son instance Wrapper interne ne journalise plus dans le fichier wrapper.log principal, car cela provoquait de la confusion. Correction d'une NPE dans DemoApp si le Wrapper était arrêté en dehors de la boîte de dialogue DemoApp.

Correction d'un problème de rotation des journaux si le fichier journal actuel était supprimé manuellement ou s'il n'existait pas parce que la journalisation était temporairement désactivée. Les modes WRAPPER, JVM, SIZE_OR_WRAPPER, SIZE_OR_JVM continuaient à faire tourner les anciens fichiers et le plus récent se retrouvait avec un numéro de rotation de "2". Désormais, la rotation n'a lieu que lorsqu'un fichier journal sans numéro de rotation existe.

Correction d'un problème où certains messages précoces étaient journalisés avant que le fichier journal ne soit rotaté au démarrage.

Correction des messages en double générés lors du chargement de la configuration : lorsque le chemin vers le fichier de configuration ou le répertoire de travail ne peut pas être résolu, lorsque le Wrapper est élevé pour contrôler un service Windows, ou dans certains cas lorsque les propriétés ne sont pas définies correctement.

Utilisation du fichier journal configuré, si possible, lorsqu'une propriété de ligne de commande invalide est trouvée ou lorsque le Wrapper échoue à charger les propriétés de ressources (non final). Auparavant, un fichier journal par défaut était créé dans le répertoire de travail.

Correction du niveau de journalisation de certains avertissements de propriétés (wrapper.*.group, wrapper.*.action, wrapper.event.<event_name>.email.attach_log). Utilise la valeur de wrapper.property_warning.loglevel.

Correction d'un problème où le fichier pid était détecté à tort comme obsolète et supprimé par le script shell sur certains systèmes Linux. Cela se produisait lorsque le chemin vers le répertoire de travail dépassait un certain nombre de caractères.

Permet d'interroger les permissions d'un service avec WrapperW. La sortie sera affichée dans la fenêtre de dialogue.

Affiche le chemin du fichier journal lorsque le Wrapper est lancé depuis le script shell et échoue à démarrer.

S'assure que la sortie console est complètement désactivée lors de l'exécution en tant que processus en arrière-plan sur les systèmes UNIX. Auparavant, certains messages générés juste après le démarrage ou lors du chargement de la configuration étaient affichés avant que la sortie ne soit désactivée.

Correction d'un bug lorsque la sortie de version Java contenait des caractères '%'. Dans des situations normales, cela ne devrait pas se produire, mais un tel problème peut survenir lorsque wrapper.java.command n'est pas défini correctement.

Affiche la sortie de la commande utilisée pour demander la version Java au niveau INFO en cas d'échec.

Désactive les filtres pour la sortie de version Java car ils ne doivent s'appliquer qu'à la sortie JVM affichée par l'application Java.

Correction de wrapper.java.command.resolve qui était ignoré lors de l'interrogation de la version Java (Unix). C'est critique car cela pouvait provoquer l'arrêt du Wrapper. Depuis la version 3.5.44.

Correction d'un problème sur les plateformes UNIX où jdb n'était pas détecté s'il était utilisé directement dans la valeur de wrapper.java.command. Voir wrapper.java.detect_debug_jvm.

Lorsque jdb ou javaw sont utilisés comme commande Java, leur sortie ne peut pas être utilisée pour analyser des informations telles que la version ou le fournisseur de Java. Le Wrapper essaie désormais de trouver la commande 'java' dans le même répertoire (ou simplement 'java' si la commande doit être résolue à l'aide du PATH système), et l'utilise pour interroger les informations.

Correction de plusieurs messages dans le script qui n'étaient pas traduits en raison de simples et doubles quotes non échappées correctement. Certains avaient également des erreurs de syntaxe.

Les distributions z/Linux sont désormais compilées sur une machine IBM z14 avec RedHat Linux 7.8.

Ajout d'un message de journal lorsqu'un classpath avec joker, défini avec une propriété wrapper.java.classpath.<n>, ne correspond à aucun fichier. Le niveau de journalisation est contrôlé par la propriété wrapper.java.classpath.missing.loglevel.

Ajout d'une nouvelle propriété wrapper.java.pid.loglevel qui permet de contrôler quand le PID d'une JVM nouvellement lancée est journalisé.

Modification du fonctionnement des arguments -q, -qs et -qp pour interroger le statut ou les permissions d'un service Windows. Le fichier de configuration est désormais requis. Cette modification n'est pas compatible avec l'implémentation de la version 3.5.43.

Mise à jour du bloc d'init LSB dans le script shell par défaut afin qu'il fonctionne plus harmonieusement avec les anciens systèmes Linux utilisant update-rc.d.

Amélioration de la journalisation lorsque la valeur de wrapper.java.command n'est pas un binaire Java.

Ajout de la propriété wrapper.ntservice.account.logon_as_service pour contrôler si le Wrapper doit ou non ajouter le privilège 'Ouvrir une session en tant que service' au compte configuré lors de l'installation du service Windows.

Correction d'un problème où la tentative d'authentification effectuée lors de l'installation d'un service Windows échouait si le wrapper.ntservice.account configuré n'avait pas le privilège 'Ouvrir une session en tant que service'. Depuis la version 3.5.42.

Correction d'un problème où les comptes de service spéciaux (LocalService, NetworkService et LocalSystem) ne pouvaient pas être utilisés par wrapper.ntservice.account lors de l'installation d'un service. Depuis la version 3.5.42.

Correction d'un problème de timing où le Wrapper affirmait parfois que la JVM s'était terminée de manière inattendue si la JVM demandait un arrêt pendant le démarrage.

Signature des binaires dans les distributions tar.gz macosx ainsi que dans les distributions delta pack.

Ajout d'une nouvelle distribution de paquet signée et notariée pour Mac OS X.

Arrêt de la fourniture de nouvelles versions pour Windows et Linux Itanium. L'architecture Itanium est abandonnée et aucune utilisation n'a été signalée récemment. Veuillez nous contacter s'il y a un besoin pour ces plateformes.

Compilation de la distribution z/OS sur z/OS 2.4. Auparavant, z/OS 1.8 était utilisé.

Renommage de sh.script.in en App.sh.in dans le répertoire src/bin.

Création de 'App.shconf.in' dans le répertoire src/bin. Ce modèle contient une copie de tous les paramètres du script shell. Il est recommandé de personnaliser ce fichier plutôt que le script shell afin de simplifier les mises à niveau du Wrapper.

Amélioration de la personnalisation des binaires Wrapper pour limiter les échecs lorsque l'exécutable cible est temporairement verrouillé par un processus externe (souvent un antivirus).

Correction de messages d'erreur trompeurs lors de la personnalisation des binaires Wrapper.

Correction d'un bug où les appels à WrapperManager.signalStarting() écrasaient la désactivation de wrapper.startup.timeout (lorsque sa valeur est définie à 0). Cela se produisait également avec WrapperManager.signalStopping() et wrapper.shutdown.timeout=0.

Ajout d'une nouvelle option '--conf-optional' à utiliser lors de la personnalisation du Wrapper. Elle permet à l'exécutable cible de s'exécuter sans fichier de configuration si la configuration a été intégrée en tant que ressource binaire. Sans cette option, le fichier de configuration sera requis. Auparavant, les binaires Wrapper avec une configuration intégrée étaient autorisés à s'exécuter sans fichier de configuration, mais pouvaient potentiellement échouer lors du lancement de l'application.

Amélioration de la journalisation lorsque le fichier de configuration échoue à se charger, et s'assure que le Wrapper s'arrête toujours si un fichier a été spécifié mais n'a pas pu être trouvé.

Ajout de la possibilité d'interroger le statut d'un service en spécifiant son nom au lieu du fichier de configuration (par ex. 'wrapper -q=testwrapper', 'wrapper -qs=testwrapper').

Ajout d'une nouvelle propriété wrapper.console.quickedit pour activer ou désactiver le mode QuickEdit de la console attachée au processus Wrapper. La valeur par défaut désactivera le mode QuickEdit car il peut provoquer le gel de l'application Java.

Correction d'un problème d'exécution de l'application de démonstration avec le delta pack.

Ajout d'une nouvelle méthode WrapperManager.generateDetailedNativeBaseName(baseName) qui permet au code utilisateur de générer un nom de fichier de base en fonction de la plateforme actuelle.

Correction d'un plantage qui se produisait lorsque le Wrapper gérait des signaux de contrôle pendant son processus d'arrêt. Cela n'avait pas de conséquences graves car le Wrapper était presque arrêté et déjà libéré, mais sous Windows cela provoquait la génération d'un fichier dump vide dans le répertoire de travail.

Correction d'un problème où WrapperManager.stop() échouait si la bibliothèque native n'était pas chargée avec succès.

Correction de messages de débogage trompeurs décrivant les codes de sortie de la JVM et du Wrapper.

Élévation au niveau STATUS du niveau de journalisation des notifications concernant la sortie de la JVM chaque fois qu'elle se termine avec un code de sortie résultant d'un plantage sous Windows.

Correction du fichier de script 'demoapp' qui n'était pas exécutable dans le dossier bin (UNIX).

Correction de certains messages malformés/corrompus en allemand.

Correction de cas où la JVM était détectée comme 64 bits sur des systèmes 32 bits (pour le débogage uniquement).

Correction de la fenêtre de dialogue qui ne s'affichait pas si une erreur se produisait lors du contrôle d'un service Windows avec WrapperW.

Ajout de la possibilité d'interroger et modifier les permissions accordées aux utilisateurs ou groupes sur les services Windows. Avec les permissions appropriées, le Wrapper peut contrôler un service sans demander à l'utilisateur les identifiants Administrateur.

Correction du Wrapper qui n'attendait pas les interfaces réseau lors de l'utilisation de clés de licence préfixées par des HostIds (wrapper.wait_for_hostid=TRUE était ignoré).

Correction d'un problème où les instances Wrapper utilisées pour contrôler le Wrapper en tant que service Windows écrivaient la sortie en caractères larges (UTF-16). Lorsque la sortie du Wrapper était transmise par pipe, la console lisait la sortie du pipe dans sa page de codes, provoquant ainsi une mauvaise traduction des caractères.

Correction de problèmes de sortie lorsque le Wrapper est élevé pour contrôler un service Windows :
- si wrapper.console.direct est défini à TRUE (par défaut), force l'utilisation de stdout uniquement pour préserver l'ordre de la sortie.
- si wrapper.console.direct est défini à FALSE, gère stdout et stderr séparément (auparavant tout était redirigé vers stdout).
- ne se bloque plus lorsque les messages sont trop volumineux.

Ne demande plus les informations requises pour installer un service Windows si le service existe déjà.

Vérifie que le compte et le mot de passe fournis sont corrects lors de l'installation d'un service Windows, plutôt qu'au démarrage. Vérifie également que le compte a le privilège de service activé.

Gère le mot de passe du service Windows de manière plus sécurisée et ne le charge en mémoire que lorsque cela est nécessaire.

Ajout de nouvelles propriétés wrapper.monitor_exit et wrapper.java.monitor_exit, qui sont utilisées par la commande --setup (-su) sous Windows pour permettre au Journal des événements de surveiller les processus Wrapper ou Java chaque fois qu'ils se terminent. Ceci est utile pour diagnostiquer les cas où le Wrapper ou Java sont tués par un autre processus.

Modification de la façon dont les HostIds sont générés sous Windows et autorisation des HostIds liés aux interfaces réseau sans fil.

N'arrête plus automatiquement un service Windows avant de le mettre à jour. Si le service est en cours d'exécution lorsque l'utilisateur tente de le mettre à jour, la commande échouera.

Modification de la valeur par défaut de wrapper.java.version.timeout à 30 secondes (auparavant elle était de 10 secondes).

Correction de cas où la version Java n'était pas résolue à sa valeur par défaut si elle ne pouvait pas être récupérée depuis la sortie de la JVM (par exemple lorsque wrapper.java.version.timeout expirait). Cela provoquait l'arrêt du Wrapper.

Ajout d'un message de débogage journalisé chaque fois que stdout ou stderr sont réassignés par l'application Java. Cela aide à comprendre les cas où les flux standard ne sont plus transmis à la sortie du Wrapper.

Correction d'un problème où le code du script shell résolvant le statut d'un démon vérifiait la présence de certaines commandes qui n'étaient en réalité pas utilisées. Cela provoquait un statut incorrect signalé lorsque la variable d'environnement PATH ne contenait pas l'emplacement des commandes.

Amélioration de la façon dont un démon est installé et supprimé en utilisant les outils disponibles sur les différentes distributions Linux.

Suppression de la prise en charge de Linux PPC-BE. Cette architecture est abandonnée par manque d'utilisation.

Correction de java.lang.IllegalArgumentException se produisant lors de l'affichage de l'utilisation des méthodes d'intégration WrapperSimpleApp, WrapperStartStopApp et WrapperJarApp.

Ignore wrapper.java.additional.auto_bits et wrapper.java.additional.auto_bits.<platform> pour Java 9 et supérieur. Cela signifie que les options "-d32" ou "-d64" ne seront plus ajoutées à la ligne de commande Java. Ces options ont été dépréciées dans Java 9 et leur utilisation a commencé à provoquer une exception fatale après leur suppression dans Java 10.

Ajout d'une nouvelle variable d'environnement 'WRAPPER_RUN_MODE', qui est définie à 'console' lors de l'exécution en tant que console, ou 'service' lors de l'exécution en tant que service Windows / démon Unix.

Ajout d'une nouvelle variable d'environnement 'WRAPPER_BASE_NAME', qui est définie au nom du binaire sans l'extension, et sans l'OS, l'architecture et les bits (s'ils sont inclus dans le nom).

Modification du nom du fichier de configuration par défaut pour qu'il soit la valeur de 'WRAPPER_BASE_NAME' suffixée par '.conf'. Cela signifie que le fichier de configuration par défaut lors de l'utilisation du delta pack n'inclura plus l'OS, l'architecture et les bits.

N'exige plus qu'une interface réseau soit active pour que son HostId soit utilisé par le Wrapper.

Correction d'un délai au démarrage qui peut se produire lorsque l'adresse IP de la machine est résolue via un DNS qui n'est pas configuré correctement (Unix).

Correction d'un bug où le Wrapper échouait à analyser la version de Java et s'arrêtait lorsque wrapper.javaio.use_thread était défini à true. Depuis la version 3.5.35.

Correction d'un bug où la version Java échouait à être analysée sur certaines implémentations de JVM (observé sur Raspbian avec openjdk 9+).

Correction d'un problème où les threads n'étaient pas utilisés de manière sûre sur HPUX (Itanium et PA-RISC), et à l'intérieur de libwrapper.so (Linux et FreeBSD). Par exemple, cela provoquait des erreurs de journal répétées lorsque le thread Java IO (wrapper.javaio.use_thread=TRUE) ne lisait aucun octet depuis le pipe.

Correction de cas rares où la boîte de dialogue de journal WrapperW s'affichait sans message ou avec des caractères illisibles.

Ajout d'une sortie dans le journal pour un dump de crash afin de indiquer clairement si le binaire Wrapper avait été personnalisé.

Modification du message de débogage lorsqu'une ressource de langue échoue à être chargée.

Correction d'un plantage sous Windows lorsque wrapper.lang.windows.encoding était défini et que la sortie JVM contenait certaines séquences de formatage C comme '%s'. Depuis la version 3.5.35.

Amélioration de la détection des distributions Linux dans le script shell et correction d'Amazon Linux qui n'était pas reconnu.

Correction d'un plantage lorsque le Wrapper demande un mot de passe à l'utilisateur lors de l'installation d'un service Windows. Depuis la version 3.5.33.

Correction d'un problème où les caractères non-ASCII n'étaient pas lus correctement dans le mot de passe saisi par l'utilisateur lors de l'installation d'un service Windows.

Dépréciation de wrapper.max_hostid_timeout au profit de wrapper.wait_for_hostid.timeout, et modification de la valeur par défaut à 15 qui est le nombre maximal de secondes que le Wrapper doit attendre que les interfaces réseau soient disponibles. Auparavant, la valeur par défaut était 0 pour attendre indéfiniment.

Ajout d'une nouvelle propriété wrapper.wait_for_hostid.strict pour forcer l'attente d'un HostId spécifique jusqu'à la valeur de wrapper.wait_for_hostid.timeout. La valeur par défaut est FALSE, ce qui indique au Wrapper d'arrêter d'attendre dès qu'au moins une interface réseau est trouvée.

Vide toujours chaque sortie de journal vers le fichier journal au démarrage jusqu'à ce que le Wrapper entre dans son cycle de surveillance de l'application.

Correction d'une erreur de segmentation sur les systèmes UNIX lorsque l'utilisateur du processus Wrapper ne fait pas partie du groupe spécifié par une propriété wrapper.*.group.

Ajout de Full RELRO à tous les binaires Wrapper Linux (sauf zLinux et Linux ia64). RELRO est une mesure de sécurité qui protège contre certains types d'attaques par corruption de mémoire GOT-overwrite.

Renforcement de la sécurité avec FORTIFY_SOURCE niveau 2 (détection des débordements de tampon) pour Linux (sauf zLinux, Linux x86 32 bits et Linux ia64) et Mac OS X.

Empêche les installations parallèles du Wrapper en tant que démon en utilisant différents outils de gestion de services.

Correction d'un statut incorrect signalé lorsque le démon était installé avec systemd et que la variable SERVICE_MANAGEMENT_TOOL était changée vers un système différent. Cela modifiait le comportement lors de l'installation, de la suppression ou de l'affichage du statut d'un démon. Une mauvaise utilisation ou des faux positifs lors de la vérification des arguments du script ont également été observés.

Correction d'une corruption mémoire potentielle lors de l'affichage des informations du certificat sous Windows.

Ajout de la possibilité de suspendre et de reprendre les délais d'attente pendant que la JVM s'exécute. Ces deux actions peuvent être déclenchées par des filtres, des minuteries, lors d'une vérification d'interblocage, lors d'un timeout de ping, en utilisant le fichier de commandes, ou depuis le code Java en utilisant les nouvelles méthodes WrapperManager.suspendTimeouts() et WrapperManager.resumeTimeouts(). Cela donne un moyen d'indiquer au Wrapper de ne pas s'inquiéter que la JVM ne réponde plus pendant que l'application Java exécute une tâche bloquante longue.

Amélioration du fichier de commandes en supprimant les espaces de fin avant de traiter la commande. Les espaces de fin provoquaient l'interprétation du dernier argument de certaines commandes comme vide au lieu de NULL.

Correction d'un problème d'arrondi provoquant une légère inexactitude des délais d'attente des états de la JVM (moins d'une seconde).

Correction de problèmes de syntaxe incompatible avec sh dans le script shell introduits dans la version 3.5.38, et la version 3.5.36 lorsque RUN_AS_USER est défini.

Ajout de la possibilité de définir les propriétés wrapper.*.group avec un identifiant de groupe.

Amélioration des messages de journalisation lorsque les propriétés wrapper.*.group sont définies à des valeurs invalides.

Correction d'un problème où WRAPPER_JAVA_VERSION, WRAPPER_JAVA_VERSION_MAJOR, WRAPPER_JAVA_VERSION_MINOR, WRAPPER_JAVA_VERSION_REVISION n'étaient pas définies si la version Java échouait à être analysée et était résolue à la valeur de wrapper.java.version.fallback ou à la version minimale prise en charge.

Correction d'un problème introduit dans la version 3.5.38 où un démon installé avec systemd échouait à démarrer et à s'arrêter, au démarrage du système ou lors de l'utilisation de systemctl.

Ajout de la prise en charge des plateformes ARMHF 64 bits (aarch64). Compilé sur SUSE Linux Enterprise Server 12 SP4 (glibc 2.22).

Correction d'un problème où le Wrapper, s'exécutant en tant qu'application console, et la JVM n'étaient pas arrêtés proprement sous Windows Vista, Server2008 et versions ultérieures lorsque l'utilisateur se déconnectait.

Ajout d'une nouvelle propriété wrapper.user_logoffs.message pour modifier le message affiché par Windows lorsque le Wrapper s'arrête et bloque la déconnexion d'un utilisateur.

Correction d'un problème sous UNIX où le Wrapper pouvait se bloquer en essayant de lire depuis le tube de sortie d'une JVM si le fork pour lancer le processus JVM échouait. Cela se produisait lorsque le nombre maximum de processus disponibles pour l'utilisateur (ulimit -u) était atteint exactement.

Ne plus afficher la sortie de débogage "active log file changed" lors du chargement de la configuration.

Correction de messages trompeurs lors de la définition de wrapper.lang avec un nom de locale inconnu.

Arrêt de l'affichage des avertissements concernant les fichiers mo manquants. Afficher des messages uniquement s'il y a eu une erreur lors du chargement d'un fichier de langue qui existe mais est invalide.

Correction d'un bug où le Wrapper considérait que le processus wrapperw avait une console attachée. Cela provoquait plusieurs petits problèmes : dégradation des performances en cas de journalisation intensive, avertissement non pertinent concernant le mode QuickEdit activé, et impossibilité d'utiliser certaines locales lorsque l'encodage OEM, généralement utilisé pour les consoles, n'était pas compatible.

Amélioration du message d'erreur enregistré lorsque tous les ports de la plage de ports configurée sont déjà utilisés.

Correction d'un plantage dans WrapperManager.nativeGetPortStatus() causé par un code de retour non géré lors de la vérification de l'état du port à utiliser par la JVM pour se connecter au Wrapper (Windows uniquement). Ce problème a été introduit dans la version 3.5.27, mais n'a été observé qu'une seule fois. Le plantage n'est possible qu'immédiatement après le lancement de la JVM. Il peut également être contourné en utilisant un tube plutôt qu'un socket avec la propriété wrapper.backend.type.

Ajout d'un nouvel ensemble de propriétés wrapper.group et wrapper.*.group pour modifier le groupe de plusieurs fichiers créés par le Wrapper sur les systèmes Unix.

Correction d'un bug introduit dans la version 3.5.37 où les invocations du script shell pendant l'exécution du Wrapper supprimaient le fichier PID défini dans le fichier de configuration. La commande status, en particulier, non seulement supprimait le fichier PID, mais renvoyait ensuite un statut erroné en supposant que le processus Wrapper n'existait plus.

Correction d'un bug où la version Java n'était pas analysée correctement sur HPUX Itanium. Le suffixe "-hp-ux" attaché à la version causait l'échec.

Ajout d'une nouvelle propriété wrapper.java.version.fallback qui sera utilisée si le Wrapper échoue à analyser la sortie de 'java -version'. Si cette propriété n'est pas définie, la version Java sera résolue vers la version la plus basse prise en charge, mais le Wrapper s'arrêtera lorsque certaines propriétés nécessitant la version Java seront utilisées.

Ne plus arrêter le Wrapper en cas d'échec d'écriture du fichier de verrouillage sous Windows, et permettre son écriture par les services Windows. Ces modifications ont été apportées pour correspondre au comportement sous Unix. Le fichier de verrouillage n'est pas utilisé par le système Windows, mais est mis à disposition des applications externes qui en feraient usage.

Ajout de 'WRAPPER_PERCENTAGE' pour représenter les caractères '%' dans les valeurs des propriétés de configuration. L'utilisation de cette variable résout une ambiguïté syntaxique survenant lorsque deux caractères % ou plus sont utilisés, provoquant l'interprétation du contenu entre eux comme une variable d'environnement.

Correction du fichier '.shconf' qui n'était pas chargé lorsque le script shell a une extension '.sh'.

Correction d'un plantage lors de l'installation du Wrapper en tant que service Windows, se produisant si les binaires contenaient une configuration intégrée et que '-' était utilisé à la place du fichier de configuration dans la ligne de commande utilisée pour lancer le Wrapper.

Correction d'un problème où wrapper.console.flush et wrapper.internal.namedpipe étaient copiés dans la ligne de commande du service Windows lorsque le Wrapper était lancé pour la première fois pour l'installation sans privilèges d'administrateur. Cela affectait les performances des services interactifs si une console était attachée et visible.

Correction de FIXED_COMMAND qui était ignoré lorsqu'il était défini dans le fichier .shconf.

Ajout de la valeur 'both' pour la variable PASS_THROUGH des fichiers script shell et batch Windows afin de permettre à la fois de passer les arguments du script comme propriétés du Wrapper et comme paramètres d'application. Voir la description dans les scripts pour l'utilisation.

Restriction de l'utilisation des arguments passés aux fichiers script shell et batch Windows, uniquement pour les commandes qui en font usage, et lorsque PASS_THROUGH n'est pas désactivé. Sous Windows, les commandes pouvant être utilisées avec des arguments sont 'console', 'install', 'installstart' et 'update'. Sous UNIX, uniquement la commande 'console' et, s'il n'est pas installé en tant que démon UNIX, les commandes 'start', 'restart', 'condrestart'. Contrairement à Windows, les arguments ne sont pas stockés lors de l'installation d'un démon UNIX, cette restriction a donc été ajoutée pour éviter les cas où le script peut être appelé manuellement avec des arguments, et lancé automatiquement sans arguments au démarrage du système.

Plusieurs petites corrections dans les fichiers script shell et batch Windows, notamment des avertissements et messages d'erreur améliorés, et une meilleure aide affichée en cas de commande incorrecte.

Ajout d'un fichier 'README.txt' dans le dossier bin des versions Windows pour expliquer la fenêtre contextuelle "Windows protected your PC" qui peut s'afficher lors de l'exécution des fichiers batch. En production, ce fichier readme peut être supprimé.

Chargement de la propriété wrapper.ntservice.preshutdown.timeout lors de l'installation d'un service Windows et non plus au démarrage du service. La valeur du délai d'attente de pré-arrêt est stockée dans la configuration du service, qui ne peut être modifiée que par un utilisateur disposant des permissions suffisantes, et tous les utilisateurs qui démarrent des services Windows n'ont pas ces permissions.

Permettre d'utiliser des locales système avec une notation d'encodage qui n'est pas directement prise en charge par iconv, si l'alias canonique de cet encodage est pris en charge.

Correction d'une corruption de mémoire se produisant lorsque l'encodage de la locale configurée n'est pas pris en charge par iconv.

Ne plus afficher d'avertissement lorsque la locale configurée correspond à une locale système avec un encodage par défaut.

Correction d'un problème de locale lors du lancement du Wrapper avec RUN_AS_USER défini dans le script shell Unix. Selon le système d'exploitation et la façon dont le Wrapper est lancé, les commandes 'runuser' ou 'su' peuvent être utilisées, mais jusqu'à présent, seule 'su' utilisait la locale système pour le processus forké. Désormais, la locale système est explicitement transmise au processus forké lors de l'utilisation de runuser afin d'assurer le même comportement avec les deux commandes.

Correction de la valeur initiale du temps écoulé depuis la dernière sortie JVM (affichée avec la colonne 'R' du format de journal), qui était '99999999' lors du lancement de l'instance JVM utilisée pour obtenir la version Java. Elle affiche désormais le temps écoulé depuis le démarrage de la JVM.

Correction des caractères de tabulation en début et fin de ligne qui n'étaient pas supprimés lors de l'analyse des lignes du fichier de configuration et du fichier de fuseau horaire. Cela provoquait l'ignorance des propriétés et directives précédées d'une tabulation.

Correction d'un problème où le fichier de configuration ne pouvait pas être lu s'il contenait des caractères non pris en charge par l'encodage du contexte dans lequel le Wrapper était lancé. Il est désormais possible de modifier l'encodage en utilisant wrapper.lang.<platform>.encoding et ainsi donner au Wrapper une seconde chance de lire le fichier de configuration et de le convertir dans le bon encodage.

Correction d'un problème où les fichiers de configuration inclus contenant des caractères corrompus étaient ignorés au lieu de provoquer une erreur fatale.

Ajout d'une nouvelle variable d'environnement : WRAPPER_JAVA_VENDOR. Cette variable est définie après le chargement de la configuration, lors de l'analyse de la sortie de 'java -version'.

Amélioration de la gestion de la ligne de commande de personnalisation et de la journalisation des erreurs en cas de format incorrect.

Permettre d'omettre le fichier de configuration en spécifiant '-' dans la ligne de commande utilisée pour lancer le Wrapper si le binaire a été personnalisé pour intégrer la configuration. Cela permet à l'utilisateur d'ajouter des propriétés de ligne de commande après le '-' et de remplacer la configuration par défaut.

Permettre de combiner la rotation des journaux par date avec n'importe quels autres modes existants (SIZE, WRAPPER, JVM, SIZE_OR_WRAPPER, SIZE_OR_JVM).

Modification de la valeur par défaut de wrapper.logfile.purge.sort en 'NAME_SMART' pour tous les modes de rotation. Auparavant, la valeur par défaut était 'TIMES' sauf lors de la rotation par date. 'NAME_SMART' purgera les fichiers journaux en les triant à l'aide des dates et index inclus dans leurs noms. Avec ce mode, les fichiers seront toujours purgés dans le bon ordre sans être affectés par des modifications manuelles qui changent leurs dates de dernière modification.

Ajout d'un avertissement au démarrage lorsque le Wrapper s'exécute dans une console avec le mode QuickEdit activé (Windows), et d'une propriété wrapper.console.quickedit.loglevel pour contrôler son niveau de journalisation. Le QuickEdit facilite la sélection de texte dans la console, mais doit être utilisé avec prudence car la sélection de texte fige le Wrapper et bloque l'application Java.

Lors de l'exécution du delta pack sur un système d'exploitation 64 bits, le script lançant le Wrapper enverra d'abord une requête pour déterminer si la licence est 32 bits ou 64 bits, puis lancera les binaires Wrapper appropriés. Auparavant, les binaires correspondant à l'architecture du système d'exploitation étaient utilisés.

Ajout d'un fichier source optionnel pouvant contenir la configuration personnalisée du script shell UNIX. Ce fichier sera exécuté après la définition des variables en haut du script, donnant à l'utilisateur la possibilité de remplacer n'importe laquelle d'entre elles. Le fichier doit avoir le même nom de base que le script et être suffixé d'une extension '.shconf'. Cela devrait permettre à l'utilisateur de conserver le script shell dans son état d'origine, et de faciliter sa mise à jour.

Définition des valeurs par défaut des variables APP_NAME et APP_LONG_NAME dans le script shell UNIX. APP_NAME prendra par défaut le nom du script shell, puis APP_LONG_NAME prendra par défaut la valeur de APP_NAME.

Ajout d'une propriété wrapper.forced_shutdown.delay pour contrôler le délai minimum requis entre deux signaux CTRL-C ou TERM pour initier un arrêt forcé. La valeur par défaut est 2 (200 ms) pour empêcher les doubles signaux d'arrêter de force l'application.

Ajout des nouvelles propriétés wrapper.java.additional.<n>.java_version.min et wrapper.java.additional.<n>.java_version.max pour permettre de passer différentes options à la JVM selon la version Java.

Permettre à WRAPPER_JAVA_HOME d'être mis à jour à chaque redémarrage de la JVM. Cette variable est définie lorsque la commande Java est localisée à l'aide du registre Windows et effacée lors de l'utilisation de wrapper.java.command. Auparavant, cette variable était finale, ce qui signifie qu'une fois définie elle ne pouvait plus être modifiée, provoquant un éventuel décalage avec l'emplacement de la commande Java utilisée.

S'assurer qu'une variable ne peut pas être définie par l'utilisateur si elle est également utilisée par le Wrapper en interne. Auparavant, cela n'était fait que pour certaines variables mais pas pour celles définies après le chargement de la configuration (telles que les variables WRAPPER_EVENT_* et WRAPPER_JAVA_HOME). En cas de conflit, un message d'avertissement sera enregistré et la valeur définie par l'utilisateur sera ignorée.

Ajout de nouvelles variables d'environnement : WRAPPER_JAVA_VERSION, WRAPPER_JAVA_VERSION_MAJOR, WRAPPER_JAVA_VERSION_MINOR et WRAPPER_JAVA_VERSION_REVISION. Ces variables sont définies après le chargement de la configuration, lors de l'analyse de la sortie de 'java -version'.

Ajout des nouvelles variables d'environnement WRAPPER_VERSION et WRAPPER_EDITION.

Dépréciation de wrapper.environment.dump au profit de wrapper.environment.dump.loglevel et génération d'un nouveau dump à chaque fois que la configuration est rechargée si wrapper.restart.reload_configuration est défini à TRUE.

Ajout des nouvelles propriétés wrapper.java.additional_file.required et wrapper.app.parameter_file.required.

Permettre de lancer le Wrapper sans spécifier de fichier de configuration si les binaires ont été personnalisés avec des propriétés intégrées.

Correction d'une taille de tampon insuffisante provoquant le plantage du Wrapper lors de l'affichage de messages volumineux en UTF-8 sous Windows.

Modification de la valeur par défaut de la directive #properties.on_overwrite.loglevel en 'AUTO' qui est résolue en :

• 'WARN' :
  - Lorsqu'une propriété est remplacée dans le même fichier de configuration ou dans un fichier avec une profondeur d'inclusion inférieure à celle du fichier de la définition précédente ;
  - Lorsqu'une propriété finale intégrée lors de la personnalisation est remplacée.
• 'DEBUG' : dans tous les autres cas.

Correction d'un problème où le Wrapper ignorait les propriétés système entourées de guillemets doubles et référencées dans les propriétés wrapper.java.additional.<n> (Windows uniquement). Au lieu de donner la priorité aux propriétés du fichier de configuration, le Wrapper créait des doublons dans la ligne de commande Java lors de l'utilisation des mêmes propriétés système en interne.

Correction d'un problème où les variables d'environnement étaient développées trop tôt lors de l'intégration des propriétés de configuration dans les binaires du Wrapper. Elles sont désormais laissées intactes et développées à l'exécution. Lors de la personnalisation, les propriétés et définitions de variables seront stockées en tant que ressource binaire dans l'ordre d'origine du fichier de configuration afin de garantir que les variables seront développées avec les mêmes règles que lors du chargement depuis le fichier.

Correction d'un bug où le Wrapper échouait à analyser la version Java si certains messages système étaient insérés avant la sortie de la JVM.

Correction d'un bug provoquant parfois le gel ou le plantage du Wrapper lors du lancement d'un processus enfant sur les systèmes UNIX autres que Linux (observé sur AIX).

Permettre le rechargement de la propriété wrapper.console.title lorsque wrapper.restart.reload_configuration est défini à TRUE.

Utilisation de l'option '-K PIC' au lieu de '-K pic' lors de la compilation des binaires Wrapper 64 bits (mais pas pour la bibliothèque native) sur Solaris SPARC. Cela était nécessaire car la taille des binaires a augmenté, mais ne devrait pas affecter le comportement du Wrapper.

Ajout d'une nouvelle propriété wrapper.registry.java_version, qui permet de cibler une version spécifique de Java lors de la localisation de la commande à l'aide du registre Windows. Si cette propriété n'est pas définie, le Wrapper utilisera la chaîne CurrentVersion du registre. Notez que Java 9 et versions ultérieures utilisent un emplacement différent dans le registre Windows, donc par défaut le Wrapper recherchera d'abord dans ce nouvel emplacement afin de privilégier les JVM récentes.

Correction d'un bug où un démon installé avec systemd échouait à démarrer si le chemin vers le script shell contenait des espaces.

Correction de messages corrompus enregistrés par la bibliothèque native si l'encodage système et l'encodage de la JVM étaient différents. Cela était surtout perceptible lors de l'utilisation de la localisation sous Windows (sur les systèmes UNIX, cela ne se produisait que si 'file.encoding' était ajouté manuellement aux options de la JVM).

Ajout d'une vérification pour s'assurer que le script shell UNIX peut être accédé à l'aide d'un chemin absolu. Dans le cas contraire, les permissions de chaque dossier intermédiaire seront listées et le script s'arrêtera.

Autres petites corrections, améliorations de performances et messages de journal corrigés.

Correction d'un bug où l'icône de la console cachée allouée par wrapperw réapparaissait dans la barre des tâches chaque fois que l'application Java ouvrait une fenêtre plein écran. Si cela se produisait, l'icône était rapidement masquée, mais un scintillement pouvait être observé dans la barre des tâches car l'icône s'affichait encore brièvement.

Correction d'un bug introduit dans la version 3.5.31 où la définition de wrapper.logfile à une valeur vide ne désactivait pas la journalisation dans un fichier. À la place, le Wrapper affichait un avertissement et se rabattait sur le fichier journal par défaut dans le répertoire de travail. Cette version rétablit la possibilité de désactiver la journalisation dans un fichier avec une valeur vide.

Gestion de la communication backend (via tube ou socket) du Wrapper natif vers la JVM en UTF-8. Auparavant, l'encodage de la locale actuelle était utilisé, mais certains encodages ne pouvaient pas prendre en charge tous les caractères lorsque le côté Java du Wrapper lisait la configuration.

Correction de problèmes de conversion de chaînes dans la bibliothèque native se produisant lorsque la JVM utilisait un encodage par défaut ne correspondant pas à l'encodage système. Cela entraînait des sorties JVM illisibles.

Ajout de la capacité d'analyser n'importe quel encodage spécifié dans les arguments de la JVM (via file.encoding, sun.stdout.encoding ou sun.stderr.encoding) et de lire la sortie de la JVM en utilisant le même encodage.

Dépréciation de wrapper.lang.encoding au profit de wrapper.lang.unix.encoding et ajout de wrapper.lang.<platform>.encoding pour spécifier un encodage par plateforme. Alors que les systèmes Unix utilisent souvent la même syntaxe pour les encodages, Windows utilise des pages de codes au lieu de noms. Le nouvel ensemble de propriétés créé aide à définir l'encodage utilisé par le Wrapper de manière multiplateforme. La valeur spécifiée sera utilisée à la fois pour encoder la sortie de la JVM et la sortie du journal du Wrapper.

Amélioration de la portabilité de wrapper.lang.unix.encoding. Si sa valeur ne correspond à aucun encodage des locales installées sur le système, le Wrapper recherchera une correspondance avec une notation différente du même encodage (sans distinction de casse, tirets, etc.).

Ajout de wrapper.jvm.encoding pour contrôler l'encodage par défaut de la JVM. L'utilisation de cette propriété nécessite Java 8 et versions ultérieures, et devrait être limitée aux cas où l'encodage de la JVM doit être différent de l'encodage de sortie du Wrapper. Sinon, wrapper.lang.[windows|unix].encoding est préféré.

Amélioration de la façon dont l'encodage est transmis à la JVM sur les différentes plateformes :

- Sous Windows, depuis la version 3.5.8 (éditions Professional et Standard), file.encoding était ajouté aux arguments de la JVM pour garantir que le Wrapper lise toujours la sortie de la JVM en utilisant un encodage adapté à sa propre langue indépendamment de la langue du système d'exploitation. Cependant, cela forçait l'application Java à utiliser un encodage qui pouvait ne pas être approprié. Désormais, l'encodage n'est transmis à la JVM que si wrapper.lang.windows.encoding ou wrapper.jvm.encoding sont définis, ou si la version de Java est antérieure à 7 (les versions récentes de Java ont leur encodage par défaut défini sur la page de codes ANSI Windows par défaut, comme le Wrapper, mais ce n'était pas toujours le cas sur les anciennes versions de Java).

- Sous Mac OS X, les JVM antérieures à la version 7 ont leur encodage par défaut défini sur "MacRoman" indépendamment de la locale actuelle. Cela provoquait des problèmes d'encodage car le Wrapper utilise l'encodage de la locale pour lire la sortie de la JVM. Pour lire correctement la sortie de ces JVM, le Wrapper définit file.encoding sur l'encodage de la locale (sauf s'il est déjà présent parmi les arguments de la JVM).

- Sur toutes les autres plateformes UNIX, l'encodage de la JVM est automatiquement résolu à partir de la locale actuelle, il n'est donc ajouté aux arguments de la JVM que si wrapper.jvm.encoding spécifie une valeur différente.

Sous Windows, user.language et user.country seront définis et transmis à la JVM chaque fois que wrapper.lang diffère de la langue et du pays de l'interface utilisateur. Auparavant, seul user.language était transmis.

Permettre d'utiliser wrapper.lang.folder, wrapper.lang.domain, wrapper.lang.window.encoding et wrapper.lang.unix.encoding sans définir wrapper.lang. Cela peut être utile si l'un de ces éléments de configuration doit être modifié tout en utilisant la langue par défaut du système d'exploitation. Sous Windows, si wrapper.lang est défini à 'DESKTOP' ou 'DEFAULT', l'encodage doit être défini à 'ANSI', 'OEM' ou 'UTF-8' pour garantir un encodage correct sur les différentes plateformes.

Correction de messages illisibles lorsque des exceptions sont levées depuis la bibliothèque native sous UNIX.

Correction d'un problème où le Wrapper échouait à charger un pack de langue (*.mo) autre que ceux fournis par défaut (allemand et japonais).

Correction d'un code de sortie erroné (0) renvoyé si le Wrapper échouait à lancer une JVM.

Permettre à wrapper.exit_code.error d'être utilisé à un stade plus précoce si le Wrapper doit s'arrêter pendant le chargement de la configuration (par exemple lorsque des propriétés en double sont trouvées avec #properties.on_overwrite.exit défini à TRUE).

Permettre de modifier l'affinité CPU du processus Wrapper lorsque la configuration est rechargée.

Ajout de wrapper.java.version.min et wrapper.java.version.max pour contrôler les versions de Java pour lesquelles le Wrapper est autorisé à s'exécuter. En dehors de la plage spécifiée, le Wrapper s'arrêtera.

Correction de wrapper.console.title qui était ignoré avec wrapperw.exe et wrapper.ntservice.console défini à TRUE.

Ajout de quatre options de personnalisation (properties-default, property-file-default, properties-final, property-file-final) pour inclure des propriétés de configuration dans les binaires du Wrapper (Windows). Les propriétés spécifiées avec les options 'default' peuvent être remplacées depuis le fichier de configuration ou la ligne de commande, tandis que celles spécifiées avec les options 'final' sont marquées comme finales et ne peuvent pas être remplacées.

Ajout d'une nouvelle propriété, wrapper.properties.dump.format, pour afficher différents types d'informations lors du dump des propriétés de configuration. Notez que le formatage par défaut passe de 'NAME=VALUE' à 'SOURCE | FINAL | NAME | VALUE'.

Ajout d'une nouvelle propriété wrapper.test.no_jvm. En la définissant à TRUE, le Wrapper s'exécutera jusqu'à ce qu'il soit sur le point de lancer une JVM, puis s'arrêtera. Cela peut être utile pour tester une configuration, confirmer l'état de la licence, vérifier les dumps de propriétés ou de variables d'environnement, etc. sans démarrer l'application Java.

Si wrapper.timezone est défini, -Duser.timezone sera ajouté à la ligne de commande Java pour synchroniser l'heure entre l'application Java et le Wrapper. Il est possible de passer un fuseau horaire différent en utilisant l'une des propriétés wrapper.java.additional.<n>, auquel cas le Wrapper n'ajoutera pas son propre fuseau horaire à la ligne de commande Java.

Amélioration de la détection de la distribution Linux dans le script shell en vérifiant que update-rc.d est présent sur le système avant d'installer le démon. Cela corrige un échec d'installation sur Amazon Linux AMI.

Ne plus utiliser IBM Advanced Toolchain lors de la compilation du Wrapper pour Linux PPC-LE. Advanced Toolchain a été introduit dans la v. 3.5.34, mais depuis, certains utilisateurs ont signalé que les binaires du Wrapper ne pouvaient pas être exécutés sur leur machine.

Correction d'un bug se produisant sur Red Hat Enterprise Linux, CentOS, Amazon Linux AMI et Fedora, où le fichier journal ne subissait pas de rotation si le jeton ROLLNUM était utilisé dans la valeur de wrapper.logfile.

Toujours s'assurer de traiter les messages de journal en file d'attente avant que le Wrapper ne quitte sur les plateformes UNIX (auparavant, cela n'était fait que sous Windows).

Correction d'un problème de compatibilité avec les versions récentes de Java (depuis la version 9, ou la version 1.8.0_261) provoquant une violation d'accès mémoire lorsque le Wrapper utilise des fichiers de localisation.

Correction de fuites de mémoire mineures (après la validation du certificat et lors du lancement de processus enfants).

Amélioration de la journalisation lors de l'établissement de la connexion à un serveur SMTP et lors de l'envoi d'e-mails.

Double signature des binaires du Wrapper avec les algorithmes de hachage SHA-1 et SHA-2 et horodatages pour permettre une vérification plus forte au niveau du système d'exploitation tout en conservant la compatibilité avec les anciennes versions de Windows qui ne prennent pas en charge SHA-2.

Ajout du paramètre "--silent" pour ne jamais afficher la boîte de dialogue de journal lors de la personnalisation de wrapperw.exe.

Renvoi d'un code de sortie de 1 chaque fois que la personnalisation de wrapper.exe a échoué. Les versions précédentes renvoyaient toujours 0.

Amélioration de la détection de l'emplacement de plusieurs commandes utilisées par le script shell lors d'actions telles que la détection de l'outil de gestion des services.

Suppression de la variable ID_BIN définie en haut du fichier de script, car elle était ignorée sur la plupart des plateformes. L'emplacement de la commande id est désormais résolu automatiquement.

Correction des méthodes du script shell pour redémarrer un démon installé avec launchd ou upstart. Elles se comportaient comme 'condrestart', ce qui signifie qu'elles se terminaient avec un code d'erreur de 1 si le service n'était pas en cours d'exécution.

Correction de la commande condrestart du script shell pour utiliser les méthodes de redémarrage intégrées d'upstart, systemd, launchd et src, au lieu d'effectuer un arrêt suivi d'un démarrage.

Amélioration des messages lors du démarrage/arrêt/redémarrage du démon Wrapper avec les différents outils de gestion des services disponibles sur les systèmes Unix.

Correction d'erreurs lors de l'interrogation de l'état d'un service sur AIX sans être root.

Ajout d'une nouvelle propriété, SYSTEMD_KILLMODE, dans le script shell pour contrôler comment systemd doit tuer les processus enfants du Wrapper à l'arrêt. Lors de l'utilisation de l'édition Professional, il peut être utile de définir cette propriété à 'process'. Cela empêchera systemd de tuer les processus enfants détachés qui devraient normalement continuer à s'exécuter à l'arrêt.

De nombreuses améliorations dans les traductions japonaise et allemande.

Correction d'un faux positif lors de la détection d'Upstart sous Linux.

Correction d'un bug où il était nécessaire d'enregistrer le Wrapper dans le journal des événements sous Windows afin d'envoyer des messages à un serveur syslog distant via UDP.

Correction d'une fuite de mémoire lors de l'envoi de messages à un serveur syslog distant. Depuis la version 3.5.27.

Correction d'un code de sortie erroné lorsque le Wrapper était configuré pour s'arrêter sur un délai d'attente de ping. Le code de sortie était toujours 1 alors qu'il devrait être la valeur de la propriété wrapper.exit_code.error.

Vérification que l'outil de gestion des services configuré est disponible avant d'installer un démon sous Linux et renvoi d'un code de sortie de 1 chaque fois que l'installation échoue.

Ajout des nouvelles propriétés wrapper.ulimit.data.{soft|hard} pour limiter la taille du segment de données de tout processus démarré par le Wrapper. C'est similaire à l'exécution de la commande "ulimit -d X" dans un terminal.

Amélioration du traitement du fichier de commandes en ignorant les lignes vides et tous les espaces avant la commande.

Correction d'un code de sortie invalide pouvant être écrit dans le fichier de commandes avec une commande STOP. Si le code de sortie est hors de la plage 0-255, il sera résolu vers la valeur de la propriété wrapper.exit_code.error.

Amélioration des messages lorsque le Wrapper est mis en pause ou repris.

Correction d'un bug où, sur certaines plateformes UNIX, la locale n'était pas correctement définie à partir de l'environnement au démarrage.

Correction d'un bug sous FreeBSD où les conversions des sorties JVM vers un encodage différent (spécifié avec wrapper.lang.encoding) échouaient systématiquement car la bibliothèque iconv n'était pas chargée par la bibliothèque native.

Sous FreeBSD, il a été observé que certaines versions d'iconv échouent à convertir certains caractères comme les barres obliques inverses lorsque l'encodage SJIS est spécifié. Dans ce cas, le Wrapper considérera SJIS comme non pris en charge et se rabattra sur l'encodage de la console qui a lancé le Wrapper.

Correction de points d'interrogation illisibles qui apparaissaient dans les messages enregistrés lors de l'exécution d'actions (install, start, pause, etc.) sur un service Windows lorsque la langue du Wrapper était différente de la langue du système.

Sous Windows, au lieu d'afficher les erreurs système dans la langue de l'interface utilisateur, le Wrapper essaiera désormais d'abord d'utiliser la langue spécifiée dans la configuration (anglais pour l'édition Community).

Renforcement de la sécurité en ajoutant une option de l'éditeur de liens pour activer ASLR (Address Space Layout Randomization) sous Windows Vista et versions ultérieures (Windows Itanium non pris en charge), et en tentant d'activer DEP (Data Execution Prevention) juste après le lancement du Wrapper (Windows XP SP3 et versions ultérieures). L'application de DEP n'affectera que les versions 32 bits car Windows active automatiquement DEP pour les binaires 64 bits.

Correction du problème de double dump de threads lors de l'appui sur CTRL-\ pendant que le Wrapper s'exécute en tant que console sous Linux. Le problème persiste sur les autres plateformes UNIX.

Correction d'un problème où les barres obliques inverses dans le chemin du fichier journal, configuré avec la propriété wrapper.logfile, n'étaient pas gérées correctement, ce qui empêchait le Wrapper de créer le fichier journal (Unix uniquement).

Correction d'un bug introduit dans la version 3.5.31 où le Wrapper ne nettoyait pas les processus enfants lors de l'arrêt.

Correction d'un bug sous z/OS où les commandes étaient ignorées si le fichier de commandes contenait un caractère de nouvelle ligne EBCDIC.

Dans le fichier de script, arrêt de l'utilisation de "runuser" lors de l'exécution du Wrapper en mode console et utilisation de "su" à la place pour gérer correctement les signaux.

Dans le fichier de script, il est désormais possible de passer des options à la commande "runuser" avec $SU_OPTS.

Correction d'un problème où certains messages provenant d'invocations du Wrapper utilisées pour contrôler le Wrapper en tant que service n'étaient pas marqués avec la source de journalisation "wrapperm".

Correction d'une faute mémoire se produisant lorsque le Wrapper quitte après avoir échoué à écrire le fichier pid. Cela provoquait le renvoi de 139 au lieu du code de sortie normal. Depuis la version 3.5.31.

Correction d'une fuite de mémoire mineure lors de l'envoi d'e-mails.

Corriger le fichier de script pour résoudre correctement le nom de l'architecture sous Z/Linux.

Modifier le comportement par défaut du fichier de script pour détecter automatiquement l'outil de gestion des services sous Linux et AIX. Voir 'SERVICE_MANAGEMENT_TOOL' dans le fichier de script.

Ajouter de nouvelles propriétés wrapper.ulimit.nofile.{soft|hard} pour limiter l'utilisation des fichiers ouverts. C'est similaire à l'exécution de la commande "ulimit -n X" dans un terminal.

Corriger un bug introduit en 3.5.30 où le fichier journal était ouvert pour des sorties avec un niveau de journalisation inférieur à la valeur spécifiée par wrapper.logfile.loglevel. Cela pouvait entraîner un problème de performance si la propriété wrapper.logfile.close.timeout était définie à une valeur basse, car cela provoquait la réouverture régulière du fichier.

Corriger un bug où les messages générés peu après le démarrage du Wrapper ne pouvaient pas être redirigés vers le fichier journal configuré. Cela se produisait lors de l'utilisation d'un répertoire de travail personnalisé et lorsque le chemin du fichier journal était défini de manière relative à celui-ci.

Corriger des problèmes lors du traitement des messages de journal en file d'attente qui pouvaient entraîner des fuites de mémoire mineures et un dysfonctionnement dans la façon dont les événements de changement de fichier journal sont déclenchés.

Corriger un problème où la rotation des journaux par date cessait de fonctionner si, à un moment donné, le Wrapper ne pouvait pas accéder au fichier journal configuré et basculait vers le fichier journal par défaut. Désormais, la rotation continuera dès que le fichier journal configuré redeviendra disponible. Quant au fichier journal par défaut, il est toujours configuré pour effectuer une rotation avec un autre fichier unique, chaque fichier ayant une limite de taille de 5 Mo.

Corriger des messages d'erreur trompeurs lorsque le Wrapper échoue à écrire dans le fichier journal ou échoue à terminer le processus JVM. Les codes d'erreur système et leurs descriptions étaient incorrects.

Plusieurs améliorations lorsque le Wrapper bascule vers un fichier journal différent. Lorsque le fichier journal n'était pas accessible, si son chemin était modifié et la configuration rechargée, le Wrapper échouait à reprendre dans le nouveau fichier journal. Amélioration également des notifications de journalisation chaque fois que le fichier journal change.

Améliorer la façon dont le Wrapper vérifie s'il existe une source pour le journal des événements Windows. Auparavant, cela était fait lors du premier message journalisé. Désormais, cette vérification est effectuée au lancement pour de meilleures performances et une meilleure lisibilité. S'il n'y a pas de source enregistrée, la journalisation vers le journal des événements sera désactivée, à l'exception des messages critiques tels que lorsque le fichier journal a changé.

Plusieurs améliorations dans les sorties de journalisation, telles que des entrées erronées dans le dump des propriétés, des sorties en double, des messages de thread insérés au milieu de messages multilignes, etc.

Corriger un bug où le Wrapper ne s'arrêtait pas même si l'action spécifiée par wrapper.event.wrapper_pause.command.on_exit.<n>=SHUTDOWN était déclenchée.

Plusieurs améliorations et corrections de bugs liées aux fuseaux horaires, en particulier lors de l'analyse du fichier de fuseaux horaires IANA.

Ajouter les nouvelles méthodes WrapperManager.getOS() et WrapperManager.getArch() pour faciliter l'accès au même OS et à la même architecture résolus utilisés par le Wrapper.

Corriger un problème de débordement de tampon se produisant lors de la collecte des HostIds si le nombre d'adaptateurs sur la machine locale dépassait 10. Amélioration également de l'affichage des HostIds lors de l'appel de 'wrapper -h'.

Lors du lancement du Wrapper en mode console, le script shell UNIX retournera désormais le code de sortie du Wrapper. Lors de l'utilisation de l'action start, le script n'attendra pas que le Wrapper se termine et ne retournera pas son code de sortie.

Ajouter une nouvelle propriété, wrapper.exit_code.error, qui permet à l'utilisateur de spécifier le code de sortie à utiliser lorsque le Wrapper s'arrête avec une erreur. Cela peut être utilisé pour distinguer les codes de sortie du Wrapper des autres codes que l'application Java peut retourner. Notez que cela ne prendra effet qu'après le chargement de la configuration.

Corriger le code de sortie d'un processus enfant lancé par WrapperManager.exec() sur les plateformes UNIX lorsqu'il s'est terminé à cause d'un plantage.

Plusieurs corrections de bugs et améliorations lors de la définition de la langue et de l'encodage. Si la configuration ne correspond à aucune locale installée sur le système, le Wrapper essaiera d'utiliser une locale similaire en ignorant la casse et les modificateurs. Voir la page Internationalisation/Localisation pour plus de détails.

Ne plus définir la variable d'environnement LANG sous Windows.

Corriger un problème où wrapper.lang.encoding était ignoré si la variable d'environnement LC_ALL était définie sur le terminal qui a lancé le Wrapper. Pour résoudre ce problème, LC_ALL est désormais définie par le Wrapper avec la même valeur que LANG. Cela s'applique uniquement aux plateformes UNIX lorsque wrapper.lang est défini.

En raison de modifications dans la façon dont les locales sont définies, la valeur de la variable d'environnement WRAPPER_LANG peut être affectée. Cette variable était et est toujours définie avec les 2 premiers caractères de la locale utilisée par le Wrapper, mais elle est désormais toujours en minuscules. Cela la fait correspondre au suffixe utilisé dans le fichier de langue. Dans l'édition Community, la valeur est toujours 'en'.

Après qu'un timeout de ping se produise, le Wrapper n'attendra plus que wrapper.shutdown.timeout s'écoule et tuera immédiatement la JVM si une action RESTART ou SHUTDOWN a été spécifiée. Un processus JVM bloqué ne peut pas être arrêté proprement, il n'est donc pas nécessaire d'attendre un timeout supplémentaire.

Déprécier l'utilisation des propriétés wrapper.event.<event_name>.email.attach_log au profit de wrapper.event.<event_name>.email.maillog. Ces nouvelles propriétés permettent de contrôler si les journaux doivent être envoyés en pièce jointe et/ou directement dans le corps des e-mails de notification. Notez également que, contrairement aux propriétés dépréciées, l'inclusion des journaux peut désormais être définie pour des événements individuels sans l'activer pour le type d'événement "default".

Ajouter les nouvelles actions PAUSE, RESUME et CLOSE_LOGFILE aux propriétés de signal wrapper.signal.mode.hup, wrapper.signal.mode.usr1 et wrapper.signal.mode.usr2. CLOSE_LOGFILE peut être utilisé pour forcer le Wrapper à recréer un nouveau fichier journal après qu'il a été déplacé ou renommé.

Ajouter la possibilité de mettre en pause et de reprendre le Wrapper depuis le script shell UNIX. Deux modes ont été ajoutés et peuvent être activés avec la variable PAUSABLE_MODE. Le premier mode, qui est le mode par défaut, utilise les signaux SIGUSR1 et SIGUSR2 pour demander la pause et la reprise. Le second mode utilise le fichier de commandes. Par défaut, le script n'autorisera pas la pause ou la reprise sauf si la variable PAUSABLE est explicitement définie. Lorsque cette fonctionnalité est activée, soyez conscient que, selon le mode, wrapper.signal.mode.usr1, wrapper.signal.mode.usr2 ou wrapper.commandfile seront passés comme propriétés de commande au Wrapper et remplaceront ainsi les propriétés correspondantes du fichier de configuration.

Ajouter des méthodes de gestion d'événements à l'application Demo pour montrer comment gérer l'événement de contrôle de service envoyé par le Wrapper lorsque wrapper.pausable.stop_jvm est défini à FALSE.

Ne plus autoriser le Wrapper à s'exécuter lorsque les versions de l'exécutable Wrapper, de la bibliothèque native et du fichier jar ne correspondent pas. Le Wrapper affichait toujours un avertissement puis tentait de continuer, mais cela menait souvent à un comportement imprévisible et à certaines fonctionnalités simplement non fonctionnelles. Veuillez vous assurer de mettre à jour tous les fichiers du Wrapper lors de la mise à jour du Wrapper.

Déprécier l'utilisation des propriétés wrapper.command.poll_interval et wrapper.anchor.poll_interval au profit de wrapper.commandfile.poll_interval et wrapper.anchorfile.poll_interval.

Corriger un problème d'arrondi faisant que les intervalles entre deux pings ou deux vérifications de deadlock étaient 900 ms plus courts que la valeur spécifiée dans la configuration.

Améliorer les messages de journalisation lors de l'utilisation des fuseaux horaires IANA introduits dans la version 3.5.29 et ajouter une nouvelle propriété, wrapper.timezone.debug_timestamps, pour afficher des informations supplémentaires (décalage par rapport à GMT et si l'heure d'été est en vigueur) dans les horodatages des sorties de journal.

Améliorer le comportement lorsque le Wrapper échoue à analyser le fichier de fuseau horaire ou échoue à résoudre l'heure d'été. Toute erreur au démarrage fera basculer le Wrapper vers l'heure système. Si une erreur se produisait pendant un changement d'heure, le Wrapper continuera avec l'heure actuelle.

Ajouter de nouvelles propriétés wrapper.ntservice.preshutdown et wrapper.ntservice.preshutdown.timeout pour permettre aux services Windows ayant un temps d'arrêt long de s'arrêter proprement avant que le système ne commence son processus d'arrêt. La première propriété spécifie que le service acceptera les notifications PRESHUTDOWN. La seconde propriété indique au gestionnaire de contrôle des services combien de temps attendre jusqu'à ce que le service s'arrête. Ces propriétés ne sont pas prises en charge sous Windows Itanium ni sous Windows XP et versions inférieures.

Corriger une fuite de mémoire sous Fedora 21 et versions inférieures. Ce problème a été corrigé pour RHEL, CentOS et Amazon Linux AMI dans la version 3.5.28, mais se produisait encore sous Fedora lors de la rotation du fichier journal en mode taille.

Corriger un bug où, dans certaines conditions, un carré blanc apparaissait brièvement à l'écran juste avant que l'écran de démarrage ne soit dessiné (wrapperw).

Changer le nom de l'architecture pour Linux PPC. Depuis la version 3.5.29, le Wrapper est disponible sous Linux PPC little-endian et big-endian. Pour éviter toute confusion, 'linux ppc' est désormais 'linux ppcbe' et 'linux ppc64le' devient 'linux ppcle'.

Dans le fichier de script, ajouter la variable FILES_TO_SOURCE qui doit contenir une liste de fichiers à sourcer avant d'exécuter toute commande.

Ajouter deux jetons, 'W' et 'J', au format de journalisation pour afficher l'identifiant de processus du Wrapper et l'identifiant de processus Java.

Corriger un bug où le Wrapper cessait de journaliser les messages provenant de l'application Java, ou de l'un de ses processus enfants, lorsqu'il rencontrait un caractère null (\0). Cela entraînait également une fuite de mémoire si l'application Java journalisait des messages à une fréquence supérieure à la valeur spécifiée avec wrapper.log.lf_delay.threshold.

Corriger une implémentation incorrecte de la propriété 'wrapper.log.lf_delay.threshold'. La durée spécifiée par cette propriété était comptée à partir de la dernière sortie de journal reçue au lieu du dernier saut de ligne reçu.

Si le Wrapper est incapable d'écrire dans le wrapper.logfile configuré, il basculait vers un fichier journal par défaut dans le répertoire de travail. Si cela échouait également, le fichier journal sera désactivé et la journalisation ne continuera que dans la console, syslog ou EventLog. À partir de la version 3.5.30, le Wrapper reprendra la journalisation dans le fichier configuré dès qu'il sera à nouveau disponible. Si le fichier journal avait été désactivé et que le fichier journal configuré était encore verrouillé, alors il tentera de reprendre la journalisation dans le fichier journal par défaut.

Corriger un bug où une action RESTART ou PAUSE spécifiée avec wrapper.on_exit.<n> (ou wrapper.on_exit.default) interrompait un SHUTDOWN déclenché par un événement, un filtre, un timer, un deadlock, un timeout de ping ou des échecs de partages montés.

Améliorer les messages de journalisation lorsque l'action 'KILL_RESTART' est spécifiée pour la propriété 'wrapper.event.<event_name>.command.block.action'. Selon l'événement, RESTART n'est pas toujours applicable, mais le Wrapper notifiait toujours qu'une nouvelle JVM allait être lancée. Désormais, il informera clairement lorsque le redémarrage n'est pas applicable.

Améliorer la sortie lors de l'interrogation du statut d'un service sous Unix. Elle indiquera si le service est installé ou non, et quel système est utilisé s'il y a plusieurs possibilités pour l'OS actuel (init.d, systemd, etc.).

Corriger un bug où le démon n'était pas rechargé lorsque le Wrapper était installé en utilisant systemd et un fichier de service personnalisé.

Lors de l'installation d'un démon avec systemd ou upstart, le Wrapper vérifiera désormais s'il existe une installation précédente comme il le fait pour les autres systèmes d'init. Cela implique que le service doit d'abord être supprimé pour forcer la réinstallation.

Ajouter la possibilité de journaliser les propriétés chaque fois que le Wrapper charge ou recharge le fichier de configuration. Une nouvelle propriété wrapper.properties.dump.loglevel a été créée pour contrôler à quel niveau elles seront journalisées.

Corriger un bug se produisant lors du lancement de plusieurs instances du script shell dans un court intervalle de temps. Si une instance démarrait le Wrapper tandis qu'une autre tentait de l'arrêter, le fichier PID du nouveau processus Wrapper pouvait éventuellement être supprimé. L'exécution sans fichier PID pouvait causer certains problèmes et laissait ouverte la possibilité qu'une seconde instance du Wrapper s'exécute simultanément même si wrapper.pidfile.strict était défini à TRUE.

Corriger deux problèmes lorsque wrapper.lang.folder était passé en ligne de commande à la JVM. Le chemin était limité à 78 caractères et n'était pas mis entre guillemets sous Windows.

Ajouter une nouvelle plateforme prise en charge : Linux PPC64LE 64 bits. Compilé sur une machine RedHat 7.1 LE, GNU libc 2.17.

Corriger un bug se produisant au démarrage où les timers définis avec un intervalle inférieur à wrapper.timer.max_catchup étaient exécutés plusieurs fois.

Ajouter une variable dynamique 'WRAPPER_SYSMEM_<P>' où <P> est un pourcentage de la mémoire physique disponible sur le système. Cette variable peut être utilisée dans les propriétés wrapper.java.additional.<n> pour définir les valeurs d'options JVM comme -Xmn, -XX:PermSize ou -XX:MaxMetaspaceSize.

Corriger un bug sous AIX où les propriétés wrapper.java.maxmemory.percent et wrapper.java.initmemory.percent ne fonctionnaient pas car le Wrapper échouait à obtenir la taille de la mémoire physique du système.

Corriger le script (AIX uniquement) pour permettre aux utilisateurs de démarrer et d'arrêter le Wrapper sans utiliser SRC et corriger une erreur de syntaxe dans un message lors de la validation de la taille de APP_NAME.

Ajouter la possibilité de spécifier un fuseau horaire de la base de données tz IANA dans lequel le Wrapper sera exécuté. Bien que les anciennes abréviations de fuseau horaire soient toujours disponibles pour la rétrocompatibilité, l'utilisation des nouveaux identifiants IANA est préférée car elle résout plusieurs problèmes, notamment concernant l'heure d'été. Par défaut, les changements d'heure d'été/d'hiver sont automatiques et mettront à jour les timers, les paramètres d'e-mail et les horodatages de toutes les sorties de journal.

Corriger le script pour Mac OS X où les utilisateurs ne pouvaient démarrer le démon que s'il était installé (bug introduit en 3.5.28). Il n'est désormais plus nécessaire de l'installer.

Améliorer une solution de contournement à un bug dans une fonction libc sous AIX qui provoque des erreurs de mémoire lorsque des messages contenant des caractères japonais sont journalisés. Il pourrait encore y avoir des erreurs si l'application Java journalise des messages très longs via le Wrapper, mais dans ce cas une configuration spéciale est possible comme solution de contournement.

Corriger un bug sous FreeBSD 10.x où la bibliothèque libiconv ne pouvait pas être chargée. Cela provoquait l'arrêt du Wrapper au démarrage.

Corriger un problème de mise à l'échelle dans l'interface graphique de l'application Demo. La fenêtre principale était trop petite sur les écrans haute résolution (high-DPI).

Corriger une fuite de mémoire sous Red Hat Enterprise Linux, CentOS et Amazon Linux AMI. Elle se produisait lors de l'activation de la rotation des journaux en mode taille. Cette fuite de mémoire provenait d'un problème dans la bibliothèque GNU C (glibc) qui a été corrigé dans la version 2.21. Cependant, une solution de contournement a été ajoutée afin que le Wrapper puisse s'exécuter sans problèmes sur n'importe quelle version de glibc.

Corriger un problème sous z/OS : si le chemin vers les binaires du Wrapper était plus long que 79 caractères, le script ne pouvait pas exécuter correctement les commandes 'start' et 'stop'. Il signalait un fichier PID obsolète lors du démarrage du processus démonisé et échouait ensuite à l'arrêter car il ne pouvait pas trouver ce fichier PID.

Corriger le bug de scintillement de la console qui se produisait encore lors du lancement de wrapperw.exe depuis un raccourci Windows.

Ajouter la possibilité de configurer l'affinité processeur pour AIX, FreeBSD, HP-UX et Solaris. Pour HP-UX et Solaris, il n'est possible de lier qu'un seul CPU par processus.

Corriger un problème où les propriétés de configuration booléennes ne se voyaient pas attribuer leurs valeurs par défaut si une valeur incorrecte était définie. Le Wrapper résolvait toujours les valeurs inconnues en FALSE même si la valeur par défaut devait être TRUE.

Ajouter un nouvel événement 'WrapperSecondInvocationEvent' qui peut être consommé dans l'application Java sous Windows. Cet événement sera déclenché chaque fois qu'une seconde instance du Wrapper tente de démarrer lorsque le mode d'invocation unique a été spécifié. Cela vous permet d'exécuter des tâches personnalisées comme afficher un message ou mettre une fenêtre de votre application au premier plan.

Avec le mode d'invocation unique, il est désormais possible de spécifier que le Wrapper mettra le focus sur la fenêtre au premier plan de l'application Java en cours d'exécution au lieu de la lancer une seconde fois. Si aucune fenêtre ne peut être trouvée, le focus sera défini sur le Wrapper surveillant l'application. Cela peut être utilisé en combinaison avec la gestion des événements pour activer n'importe quelle fenêtre qui a été mise au premier plan.

Corriger un bug sous Linux où RUN_AS_USER était ignoré lors de l'exécution du Wrapper en tant que service contrôlé par systemd. Le service s'exécutait toujours en tant que root.

Corriger un bug sous AIX où l'exécution du Wrapper en tant que service n'utilisait pas le System Resource Controller (SRC) et ignorait la valeur de RUN_AS_USER. Merci à Miroslaw d'avoir signalé cela et pour ses contributions au script shell.

Ajouter un nouvel indicateur de bit (0x8000) pour indiquer qu'une erreur s'est produite lors de l'interrogation du statut d'un service Windows. Si l'interrogation est silencieuse (option -qs), wrapperw.exe n'affichera plus les messages d'erreur dans la boîte de dialogue, mais ces erreurs seront toujours journalisées dans le fichier journal.

Ajouter une nouvelle propriété système à WrapperStartStopApp (méthode d'intégration n°2) pour gérer les paramètres de passthrough. Ces paramètres peuvent être passés à la méthode start et/ou stop de votre application Java. Par défaut, les paramètres de passthrough sont ignorés (voir les javadocs de la classe WrapperStartStopApp pour plus de détails).

Sous Windows, le Wrapper vérifiera désormais que la page de codes de la console prend en charge la langue spécifiée. Si ce n'est pas le cas, il basculera vers l'anglais.

Ajouter deux nouvelles valeurs pour la propriété wrapper.lang : 'DESKTOP' et 'SYSTEM'. Ces valeurs sont utilisées sous Windows et ignorées sur les autres systèmes. La première, qui est la valeur par défaut, spécifie que la langue du Wrapper sera résolue selon la langue de l'interface utilisateur. La seconde fera qu'il utilisera la langue du système. Auparavant, le Wrapper utilisait la langue des paramètres de format régional.

Corriger un bug où les messages en japonais provenant de la JVM étaient mal encodés. Cela se produisait sous Windows lorsque la langue pour les programmes non Unicode n'était pas définie sur le japonais.

Améliorer le message d'erreur s'il y a des problèmes lors de l'initialisation du pipe ou du socket backend.

Ajouter la commande 'installstart' au script shell UNIX afin d'installer puis de démarrer automatiquement le Wrapper en tant que processus démon.

Sous AIX et HPUX Itanium, le Wrapper n'aura plus la version GNU de libiconv comme dépendance. Cette dépendance a été introduite dans la version 3.5.26 pour AIX et 3.5.27 pour HPUX Itanium, mais causait des problèmes de compatibilité.

Ajouter une nouvelle option '--teardown' (et TeardownApp.bat.in) à la version Windows qui peut être utilisée pour annuler les modifications effectuées avec l'option '--setup'. Des identifiants d'administrateur seront demandés. À partir de la version 3.5.28, cela désenregistrera uniquement l'application/le service du système de journal des événements.

Ajouter une nouvelle propriété, wrapper.syslog.ident.enable, qui indique au Wrapper de créer ou de supprimer une identification (également connue sous le nom de source) pour le journal des événements. À partir de Windows Vista ou Windows Server 2003, cette action nécessite des identifiants d'administrateur. Lors de l'exécution avec des permissions inférieures, le Wrapper ignorera cette propriété et démarrera normalement.

Corriger un bug où les actions spécifiées par wrapper.ping.timeout.action n'étaient effectuées que la première fois que la JVM se bloquait. Tous les blocages suivants étaient ignorés. Avec la configuration par défaut, cela signifiait que le Wrapper ne pouvait redémarrer une JVM bloquée qu'une seule fois. Depuis la version 3.5.16.

Le Wrapper est désormais signé avec un certificat SHA-2. SHA-2 offre une sécurité plus forte que l'algorithme SHA-1 précédemment utilisé. La décision de changer le certificat a été prise conformément au plan de dépréciation de SHA-1 de Microsoft qui indique que Windows 7 et versions ultérieures ne prendront plus en charge SHA-1 après le 1er janvier 2016. Il convient de noter que Windows XP SP2 et versions inférieures, ainsi que Windows Server 2003, ne prennent pas en charge SHA-2 et que le nouveau certificat ne s'appliquera pas sur ces plateformes. Les binaires fournis pour Windows Itanium ne seront également plus signés.

Corriger des erreurs de mémoire se produisant sous AIX lorsque le système utilise certaines localisations comme le japonais.

Corriger un message d'erreur trompeur lorsqu'il y a un problème de traitement d'un message d'erreur système sous Windows.

Gérer les codes de sortie système avec des descriptions (Windows uniquement).

Ajouter de nouvelles directives de fichier de configuration (#properties.on_overwrite.loglevel et #properties.on_overwrite.exit) pour mieux contrôler le comportement du Wrapper lors de la détection de définitions de propriétés en double.

Correction : Ne tente plus de reprendre un service Windows déjà en cours d'exécution, ni de mettre en pause un service déjà en pause.

Améliorer la précision des messages de statut lors de l'installation, de la suppression, du démarrage, de l'arrêt, de la reprise et de la mise en pause d'un service Windows.

Améliorer l'affichage des HostIds disponibles lors de l'appel de 'wrapper -h'.

Corriger le bug de scintillement de la console. Se produisait lorsque wrapper.ntservice.generate_console était défini à TRUE, ce qui est requis pour le dump de threads.

Corriger un problème sous Windows avec la version sans console du Wrapper. Si un écran de démarrage était défini au lancement, et si le Wrapper échouait finalement à démarrer normalement, l'écran de démarrage ne disparaissait pas et restait au-dessus de la fenêtre de journal.

Corriger un problème sur les plateformes Windows qui faisait que la fenêtre de journal recouvrait tous les autres formulaires même lorsque le focus était défini sur une autre application.

Ajouter la possibilité de définir l'affinité CPU pour les processus Wrapper et JVM (systèmes Windows et Linux).

Le Wrapper peut désormais être exécuté avec une option '--setup' afin d'installer des composants en mode élevé sous Windows. Pendant l'installation, le Wrapper enregistrera l'application dans le système de journal des événements Windows. Après l'exécution du Wrapper avec l'option '--setup', l'Observateur d'événements ne signalera plus que l'installation était corrompue.

wrapper.exe et wrapper.dll sont désormais manifestés pour la compatibilité avec les versions plus récentes de Windows (8.1 et ultérieures).

Modifier la licence de l'édition Community pour permettre au Wrapper d'être intégré et distribué avec des produits publiés sous les licences GPL version 2 ou GPL version 3.

Inclure le PID des processus Wrapper et Java dans la sortie de débogage.

Corriger un problème où les propriétés wrapper.jvm.port.min et wrapper.jvm.port.max étaient ignorées. Cela signifiait que les valeurs par défaut étaient toujours utilisées. Depuis la version 3.5.26.

Corriger un problème très rare dans lequel le Wrapper produisait une erreur de mémoire insuffisante ou échouait en tentant d'obtenir le chemin vers le Wrapper sous Windows XP.

Modifier les propriétés wrapper.pausable et wrapper.pausable.stop_jvm afin qu'elles ne soient plus rechargées lorsque wrapper.restart.reload_configuration=TRUE.

Corriger un bug lorsque le processus enfant affichant la version de la JVM devenait un zombie après son achèvement (problème connu sous CentOS). Ajouter la propriété wrapper.java.version.timeout pour permettre à l'utilisateur de définir un timeout pour que le processus enfant affiche la version de la JVM avant d'être terminé.

Éviter les événements 4227 dans le journal Windows lors de l'utilisation de valeurs SOCKET pour la propriété wrapper.backend.type. Nous essayons désormais de vérifier le statut du port en code natif avant de l'ouvrir en Java. Le Wrapper fonctionnait correctement, mais un problème Windows provoquait des avertissements dans l'EventLog si le port avait un socket existant dans l'état TIME_WAIT provenant d'une invocation JVM précédente.

Corriger un problème sous AIX avec OpenJRE où le Wrapper échouait à charger la bibliothèque native. La bibliothèque native a désormais une extension '.so' comme sur les autres plateformes UNIX.

Corriger un problème sous HP-UX lors de la liste des HostIds. Si plusieurs HostIds étaient disponibles sur la machine, le Wrapper ne pouvait obtenir que le premier et signalait des erreurs DLPI en tentant d'obtenir les autres.

Corriger le chemin pour supprimer les fichiers lors de la désinstallation du processus démon Wrapper sous HPUX.

Ajouter les binaires Linux Itanium dans le "Delta Pack". Ils avaient été retirés depuis la version 3.5.18.

Corriger une erreur de conversion d'encodage lors de l'envoi d'e-mail sous HP-UX.

Sous Mac OS X, définir la clé KeepAlive de launchd à "false" par défaut comme recommandé par Apple. Cependant, il est possible de la définir à "true" en modifiant la nouvelle variable MACOSX_KEEP_RUNNING dans le fichier de script.

Amélioration des messages de journalisation lorsqu'un redémarrage de la JVM est demandé alors que le Wrapper est dans un état où il sera ignoré.

Ajout d'un message de débogage supplémentaire lorsqu'un balayage de deadlock se termine. Aucun changement fonctionnel, mais ceci a été ajouté pour faciliter la détermination de la durée du balayage pour une application donnée.

Nettoyage du suivi interne de l'endroit où les variables d'environnement ont été définies. Aucun changement fonctionnel.

Lors de la détection de Cygwin avec 'uname -o' dans le fichier de script, certains OS (Solaris, macOS, etc.) affichent un message d'erreur car '-o' n'est pas un paramètre valide. Nous masquons désormais ce message d'erreur pour éviter toute confusion et nous pouvons en déduire que Cygwin n'est pas en cours d'exécution.

Ajout de la possibilité de contrôler le service avec systemd à l'aide du fichier de script.

Sur Mac OS X, correction d'une faute de frappe, ajout d'une autre méthode alternative pour trouver Java afin de définir la variable d'environnement JAVA_HOME, et utilisation du chemin complet pour exécuter sysctl au cas où il ne serait pas dans le PATH. Merci à Dannes Wessels d'avoir signalé ce point.

Correction d'un problème sur les versions plus récentes de Windows lors de la personnalisation du Wrapper. Le certificat n'était pas supprimé lors de la création de la cible. Cela entraînait une erreur lors de la tentative de signature de la cible avec un nouveau certificat.

Ajout du support manquant dans le script shell pour redémarrer/arrêter le service Wrapper avec launchctl sur Mac OS X.

Ajout du support manquant dans le script shell pour redémarrer/arrêter le service Wrapper avec Upstart.

Ajout de la possibilité de définir le chemin de la commande 'su' ainsi que de spécifier des arguments supplémentaires dans le script shell du Wrapper à l'aide des nouvelles variables SU_BIN et SU_OPTS.

Correction d'un problème dans les classes d'aide WrapperSimpleApp, WrapperStartStopApp et WrapperJarApp où les problèmes de ligne de commande entraînant la sortie de la JVM au démarrage ressemblaient à des sorties inattendues. Cela signifiait que le Wrapper tentait de relancer la JVM plutôt que d'abandonner dès la première tentative.

Modification des classes d'aide WrapperSimpleApp, WrapperStartStopApp et WrapperJarApp afin que leurs bannières d'utilisation ne s'affichent désormais que pour les problèmes liés à la ligne de commande. Les problèmes avec les classes, méthodes ou fichiers jar spécifiés sont toujours journalisés comme des erreurs, mais afficher l'utilisation à l'utilisateur dans ces cas était source de confusion.

Correction de la méthode WrapperResources.getString() qui n'a pas d'arguments de remplacement afin que le traitement de la chaîne brute soit identique à celui des méthodes qui ont des arguments de remplacement. Désormais, toutes les chaînes sont traitées par la classe MessageFormat avant d'être renvoyées. Les versions précédentes n'étaient pas cohérentes quant à la nécessité d'échapper les apostrophes.

Ajout d'une validation optionnelle des clés pour s'assurer que les chaînes passées à la méthode WrapperResources.getString() sont formatées correctement. Consultez la classe WrapperResources pour savoir comment l'activer.

Ajout de nouvelles options pour la propriété wrapper.backend.type : AUTO, SOCKET, SOCKET_IPv4, SOCKET_IPv6, PIPE. Lorsque définie sur AUTO, le Wrapper tentera d'ouvrir un socket ipv4 et basculera vers ipv6 puis vers pipe en cas d'erreur.

Correction d'un bogue lors de la conversion de caractères multi-octets vers des caractères larges sans définir la locale au démarrage (Unix uniquement). Merci à Bert.

Ajout d'un alias 'CLOSE_BACKEND' à 'CLOSE_SOCKET' comme commande de test pour la propriété wrapper.commandfile. Cela s'explique par le fait qu'il existe depuis un certain temps plusieurs options pour la connexion backend et que ce nom est plus portable.

Correction d'un problème sur Mac lors de l'exécution d'OS X Yosemite où le script ne parvenait pas à comparer correctement les versions '10.10' et '10.5.0'. Cela amenait le script à penser que seuls des binaires 32 bits pouvaient être exécutés. Ce problème ne se produisait que si la nomenclature delta pack des binaires du Wrapper était utilisée.

Ajout d'une nouvelle propriété wrapper.java.classpath.missing.loglevel qui permet de contrôler la façon dont le Wrapper journalise les avertissements concernant les éléments de classpath manquants. Auparavant, cela était toujours journalisé en sortie de débogage et ne pouvait pas être désactivé.

S'il y a des problèmes de bas niveau lors du lancement du processus Java qui ne sont pas liés à la configuration ou à la JVM elle-même, le Wrapper ne réessaiera plus, car de telles tentatives n'avaient aucun sens.

Les API système Windows ont un problème qui provoque le plantage d'un processus s'il tente de définir une variable d'environnement de plus de 32767 caractères. Le Wrapper vérifie désormais cela et journalise une erreur plutôt que de définir la variable. C'était un problème si des classpaths très volumineux étaient utilisés lorsque la propriété wrapper.java.classpath.use_environment était TRUE.

Windows n'autorise pas une ligne de commande de plus de 32766 caractères. Les différentes versions de Windows gèrent cela différemment lorsqu'une commande aussi longue est fournie. Le Wrapper effectue désormais sa propre vérification et affiche une erreur de manière cohérente.

Amélioration du message d'erreur sur les plateformes UNIX lorsque la ligne de commande est plus longue que le maximum du système. Ce maximum varie considérablement selon la plateforme et l'environnement et est difficile à calculer de manière fiable, c'est pourquoi la longueur maximale n'est actuellement pas indiquée dans le message.

Correction d'un problème sur les plateformes UNIX où un fichier de configuration très volumineux pouvait empêcher le WrapperManager de démarrer. Cela était dû au transfert partiel du fichier de configuration vers le WrapperManager via la connexion backend. Cela se produisait quel que soit le type de backend utilisé. La taille du fichier de configuration pouvant causer un problème variait considérablement selon le système spécifique.

Correction d'un problème sur les plateformes Windows où un fichier de configuration très volumineux n'était pas envoyé au WrapperManager au démarrage lorsque la propriété wrapper.backend.type était définie sur PIPE. Le seul problème était que la méthode WrapperManager.getProperties() était vide.

Ajout de vérifications aux méthodes WrapperManager.exec() sous Windows pour la longueur maximale de ligne de commande de 32766, et la longueur maximale de paire nom-valeur de variable d'environnement de 32767.

Correction d'un problème où une libération d'un pointeur NULL était effectuée dans le cadre du processus de nettoyage d'un appel WrapperManager.exec(). Il n'est pas connu que cela ait causé des problèmes.

Ajout des méthodes getStdOut(), getStdErr() et getStdIn() à la classe WrapperProcess comme alias des méthodes getInputStream(), getErrorStream() et getOutputStream() pour éviter toute confusion.

Correction d'un problème sous Windows 7 où les longues lignes de journal étaient corrompues après 31397 caractères lorsque wrapper.console.direct était true. Cela semble être un problème de l'API Windows sous-jacente et n'était qu'un problème d'affichage. Réduction du nombre maximal de caractères pouvant être écrits avec un seul appel API à 30000 pour contourner le problème. Cette modification est interne et il n'y a toujours aucune limite à la longueur des lignes journalisées.

Correction d'un deadlock si le Wrapper échouait à écrire vers le backend lorsque la propriété wrapper.backend.type était PIPE. Découvert lors d'une revue de code et il n'est pas connu que cela se soit réellement produit.

À partir de Mac OSX 10.5.0, le fichier de script utilisera la clé 'KeepAlive' dans le fichier de configuration launchctl. Les versions antérieures de Mac OSX continueront d'utiliser la même clé 'OnDemand'. Merci à Robin d'avoir signalé ce point.

Interdiction de l'utilisation des HostIds liés aux périphériques Bluetooth Apple lors de l'exécution sur un système Windows virtualisé hébergé sur un système OS X.

Correction d'un problème où WrapperManager.log() ne fonctionnait pas correctement lorsque des messages multi-octets étaient journalisés.

Dans la sortie de débogage, le paquet complet des propriétés de configuration est masqué de la sortie du journal car il est énorme et peut contenir des données sensibles. Ajout d'une taille à la sortie abrégée pour faciliter le débogage.

Correction d'une fuite de mémoire sur les plateformes UNIX chaque fois qu'un message d'erreur était signalé. Ce n'était un problème que si le message était journalisé de manière répétée.

Correction de quelques autres fuites de mémoire potentielles découvertes lors d'une revue de code. Il n'est pas connu qu'elles aient causé des problèmes réels.

Amélioration de la propriété wrapper.timer.<n>.interval afin qu'il soit désormais possible de spécifier des plages et des listes de valeurs ainsi que des décalages pour les valeurs d'intervalle afin de contrôler plus précisément le déclenchement des minuteries.

Correction d'un problème avec la propriété wrapper.timer.<n>.interval où les minuteries ne se déclenchaient pas pendant un intervalle où l'heure système était reculée. Correction également d'un problème où les minuteries cessaient définitivement de se déclencher si l'heure système était avancée de plus que la valeur de la propriété wrapper.timer.max_catchup et qu'une minuterie avait été programmée pour se déclencher pendant cet intervalle. Ces deux problèmes se produisaient le plus probablement lors du changement d'heure d'été.

Correction d'un problème où les signaux reçus par la JVM n'étaient pas journalisés correctement dans la sortie de débogage si la propriété wrapper.ignore_signals est définie sur true. Nous journalisons désormais également la sortie de débogage même si un écouteur d'événements utilisateur consomme l'événement de signal.

Correction d'un problème sur Gentoo Linux où le script shell ne détectait pas correctement l'architecture du système. Cela peut également poser problème sur d'autres distributions dont 'uname -p' renvoie une architecture détaillée.

Dans le script shell, lorsque l'indicateur d'utilisation de systemd (USE_SYSTEMD) est défini, le script shell génère un fichier ".service" dans /etc/systemd/system/ lors de l'installation du Wrapper en tant que démon.

Dans le script shell, ajout d'une fonction pour valider la taille de APP_NAME lors de l'installation ou de la suppression du démon sur AIX.

Il était possible de désactiver la journalisation de la ligne de commande Java même lorsque la sortie de débogage était activée en définissant la propriété wrapper.java.command.loglevel sur NONE. Cela rendait le débogage des problèmes difficile et n'est plus possible.

Lorsque la propriété wrapper.java.version.output est définie sur true, ajout d'une sortie de journal de débogage pour afficher la ligne de commande réellement utilisée.

Correction d'un problème sous Windows lorsque la propriété wrapper.java.version.output est true où il était possible que l'exécutable java lancé pour obtenir la version soit différent de celui utilisé pour exécuter l'application si l'exécutable java était localisé à la fois dans le PATH système par défaut et dans le PATH défini dans l'environnement. Le Wrapper recherche désormais une seule fois et utilise le même chemin entièrement résolu aux deux endroits. Pour plus de clarté, les deux lignes de commande java sont désormais incluses dans la sortie de journal de débogage lorsque la version est demandée. (Bogue n° 288)

Modification du moment de la journalisation de la ligne de commande Java sous UNIX afin qu'il soit cohérent avec Windows.

Amélioration du texte du message d'erreur généré lorsqu'une fonctionnalité native n'est pas disponible depuis Java afin de préciser plus clairement si le problème est que la bibliothèque native n'a pas pu être chargée ou que la mauvaise édition est utilisée.

Sous Windows, détection lorsque le Wrapper s'exécute sous Cygwin et définition de la valeur par défaut de wrapper.console.flush sur TRUE. Sur les autres plateformes, le script affichera un message et s'arrêtera.

Ajout du support des références de variables WRAPPER_EVENT_TIME_* et WRAPPER_EVENT_RAND_* afin que les heures d'événements puissent être utilisées lors du déclenchement des événements.

Correction d'un problème de débordement de tampon sur AIX qui provoquait des plantages ou des deadlocks au démarrage pour certains utilisateurs. Ce problème existait depuis la version 3.5.0 mais n'a été signalé que récemment.

Suppression des messages de débogage en sortie sous UNIX lorsque la propriété wrapper.port.address était définie.

Nettoyage du code lors de la conversion de caractères multi-octets en caractères larges. Certaines vérifications d'erreurs n'étaient pas implémentées correctement. Découvert lors d'une revue de code et il n'est pas connu que cela ait réellement causé des problèmes.

Correction d'un problème où la source des messages syslog distants provenant de la JVM était journalisée comme "jvm %d" plutôt que "jvm 1".

Ajout d'une nouvelle propriété wrapper.syslog.split_messages qui contrôle si les messages multi-lignes seront journalisés tels quels ou d'abord découpés en lignes individuelles.

Correction d'un problème sous Windows Vista et versions ultérieures où la propriété wrapper.single_invocation n'identifiait pas correctement les instances du Wrapper s'exécutant dans différentes sessions dans certaines circonstances.

Nettoyage des messages d'erreur journalisés lorsque le Wrapper échouait à s'élever sur les plateformes Windows. Ils sont désormais plus informatifs.

Correction d'une fuite de handles sous Windows dans WrapperProcess.isAlive().

Modification de l'exception levée lorsque WrapperManager.exec() est appelé alors que le Wrapper est arrêté afin qu'elle l'indique désormais plutôt que de dire que la bibliothèque native n'est pas chargée.

Le Wrapper est désormais plus prudent pour s'assurer que le backend n'est jamais fermé pendant le lancement d'un processus enfant afin de garantir que le Wrapper a connaissance de tous les processus enfants lancés.

Ajout d'un message d'avertissement au cas où le Wrapper ne serait pas notifié d'un processus enfant lancé en raison de la fermeture de la connexion backend.

Correction d'une NPE potentielle qui pouvait être levée lors de la lecture de la sortie stdout ou stderr d'un processus enfant pendant l'arrêt du Wrapper et après la sortie du processus enfant.

Correction d'un problème sur les plateformes UNIX où nous restions bloqués en tentant de nettoyer après un processus qui était actuellement bloqué sur une lecture depuis stdout ou stderr.

Correction d'un problème sur les plateformes UNIX où un délai d'attente lors de la tentative d'obtention d'un verrou interne de la liste des processus enfants provoquait un compteur interne désynchronisé, amenant d'autres processus enfants terminés à rester comme zombies défunts jusqu'à la terminaison du processus Java.

Correction d'un problème sur les plateformes UNIX où les descripteurs de fichiers de tubes utilisés pour communiquer avec les processus enfants étaient incorrectement transmis à tous les processus enfants. Ils n'augmentaient pas au fil du temps.

Correction d'un problème potentiel de synchronisation lors de l'appel de WrapperProcess.waitFor() ou WrapperProcess.exitValue().

Ajout d'une sortie de journal de débogage supplémentaire affichant les diverses valeurs de délai d'attente pour aider au débogage des problèmes des utilisateurs.

Correction d'un problème où le script shell ne détectait pas correctement la version de l'OS avec Mac OSX Maverick.

Ajout d'avertissements concernant les variables d'environnement non définies dans les références de fichiers d'inclusion dans le fichier de configuration.

Ajout du support de l'expansion des variables d'environnement dans les fichiers spécifiés avec les propriétés wrapper.java.additional_file et wrapper.app.parameter_file.

Correction du formatage des entiers dans la méthode WrapperUNIXGroup.toString() afin qu'il soit cohérent avec le reste du Wrapper.

Correction d'un problème où l'exigence de la bibliothèque iconv ne pouvait pas être satisfaite sous FreeBSD 10. Nous localisons désormais la bibliothèque dynamiquement en recherchant /usr/local/lib/libiconv.so, /usr/local/lib/libbiconv.so ou /lib/libkiconv.so.4 dans cet ordre.

Correction de la méthode WrapperPrintStream.println() afin que les chaînes contenant des sauts de ligne aient correctement chaque ligne précédée de l'en-tête configuré.

Lorsqu'un type de licence inconnu est rencontré, inclusion du type inconnu dans le message d'erreur pour faciliter le débogage.

Correction d'un problème sur les systèmes FreeBSD où wrapper.lang.encoding ne se résolvait pas correctement en UTF-8 lorsque la variable d'environnement LANG n'était pas définie.

Correction d'un problème de corruption de mémoire sur z/OS lorsque la langue était définie sur une locale double octet comme le japonais.

Parcours du code pour rendre le Wrapper beaucoup plus robuste lorsque des caractères double octet mal encodés sont rencontrés.

Correction d'un plantage dans le code natif derrière les instances WrapperResources qui pouvait se produire si le système manquait fortement de mémoire. Depuis la version 3.5.7.

Correction de quelques fuites de mémoire lentes dans le code natif impliqué dans le lancement et la vérification de l'état des processus enfants.

Correction d'un problème où une tentative de lever une WrapperJNIError dans le code natif sur Z/OS entraînait la levée d'une ClassNotFoundException.

Revue du code JNI natif et correction de quelques plantages et fuites de mémoire potentiels qui pouvaient se produire dans des conditions de mémoire faible.

Modification du fonctionnement de la propriété wrapper.console.direct afin que le Wrapper se rétrograde désormais toujours vers l'écriture console par tube dès qu'il a déterminé qu'aucune console physique n'existe. Dans la version 3.5.21, nous tentions de prédire quand la console n'existerait pas et de la désactiver à l'avance. Il y avait des cas où cela n'était pas correct, entraînant des messages d'erreur dans la sortie console.

Correction d'un problème où des opérations comme l'installation d'un service sous Windows 7 et versions ultérieures nécessitant une élévation entraînaient une erreur indiquant que le Wrapper ne pouvait pas écrire vers la console. L'opération réelle fonctionnait correctement mais la sortie console était incorrecte. Depuis la version 3.5.21.

Déplacement plus tôt dans le processus de démarrage de la vérification que les versions du jar et du Wrapper correspondent afin de garantir qu'un avertissement sera toujours affiché. Il y avait certaines erreurs qui pouvaient interrompre le processus de démarrage avant que cet avertissement ne soit journalisé.

Correction d'un problème où la valeur de wrapper.lang.folder n'était pas reconnue si une valeur wrapper.lang n'était pas définie.

Correction d'une petite fuite de mémoire lors de la résolution de la langue avec laquelle exécuter le Wrapper.

Correction d'un débordement de tampon potentiel lors de la lecture de données depuis le stderr ou le stdout d'un processus enfant si la quantité de données disponibles dans le tube est supérieure à la longueur du tampon passée à WrapperProcessInputStream.read(byte b[], int off, int len).

Correction d'un problème où les lectures depuis un WrapperProcessInputStream consommaient trop de CPU en attendant des données sous Windows. Désormais correctement effectuées de manière asynchrone.

Correction d'un problème où le nettoyage de la JVM, y compris le nettoyage des processus enfants, n'était pas toujours effectué complètement si l'utilisateur demandait un arrêt immédiat en appuyant deux fois sur CTRL-C.

Ajout d'un nouveau format de journal 'R' qui suivra le nombre de millisecondes depuis la précédente sortie de journal de la JVM. Utile pour des vérifications de performance simples. Consultez chaque page de propriété pour plus de détails : propriétés wrapper.console.format, wrapper.event.default.email.maillog.format, wrapper.logdialog.format et wrapper.logfile.format.

Lorsque la commande de test ACCESS_VIOLATION de wrapper.commandfile était utilisée pour tuer le Wrapper, certaines sorties de journal n'étaient pas écrites dans le fichier wrapper.log. Ajout d'un flush forcé juste avant de faire planter le Wrapper pour s'assurer que tout est écrit dans le fichier journal.

Ajout d'une nouvelle propriété wrapper.javaio.buffer_size qui permet de contrôler la taille du tampon interne utilisé pour traiter la sortie console de la JVM. Augmentation également de la valeur par défaut, de la valeur par défaut du système à 65536 octets.

Renommage de la propriété wrapper.use_javaio_thread en wrapper.javaio.use_thread. L'ancienne propriété existe toujours en tant qu'alias déprécié.

Ajout d'une nouvelle propriété wrapper.console.direct sous Windows qui indique au Wrapper d'utiliser les API Windows pour afficher la sortie de journal vers la console plutôt que d'écrire vers stdout et stderr. Cela entraîne une amélioration majeure de la vitesse. L'inconvénient est que cela supprime la possibilité de rediriger la sortie vers un autre programme sur la ligne de commande. Nous avons choisi d'activer ceci par défaut afin que la majorité des utilisateurs puisse profiter de l'amélioration de vitesse. Si votre application tire parti de la redirection sous Windows, vous devrez désactiver cette propriété pour retrouver l'ancien comportement.

Ajout d'une nouvelle source de journalisation "wrapperm" sous Windows pour aider à différencier les entrées de journal provenant des invocations du Wrapper utilisées pour contrôler le Wrapper en tant que service, telles que le démarrage, l'arrêt, l'installation, etc. Auparavant, les entrées de journal du processus de service Wrapper et du processus de lancement utilisaient toutes deux une source de journalisation "wrapper", ce qui pouvait prêter à confusion.

Sous UNIX, modification de la façon dont nous suivons si le processus est démonisé ou non. Ceci a été fait pour un peu de nettoyage, mais ne devrait pas affecter le fonctionnement du Wrapper.

Sous Windows, modification du moment où les fichiers PID sont créés lors de l'exécution en tant que service afin que tout échec de leur création soit correctement signalé comme une erreur de service. Si le Wrapper ne pouvait pas écrire dans un fichier PID parce qu'il était en lecture seule, l'utilisateur recevait un message confus indiquant que le service expirait au démarrage. Cela s'ajoutait à l'erreur correcte déjà journalisée.

Correction d'un problème potentiel où des entrées de journal mises en file d'attente en interne pouvaient ne pas être journalisées à l'arrêt. La file d'attente de journal est désormais toujours traitée dans le cadre du processus d'arrêt.

Modification du script shell UNIX pour supprimer tous les fichiers rc de niveau d'exécution existants pour l'application à la fois à l'installation et à la suppression, plutôt que seulement ceux du niveau d'exécution actuellement configuré, afin d'éviter un comportement inattendu dû à d'anciens fichiers rc laissés en place. Cela n'affecte que les plateformes qui utilisent des fichiers rc.

Ajout d'une nouvelle variable RUN_LEVEL au script shell UNIX pour faciliter la configuration des niveaux d'exécution lors de l'installation en tant que démon sur diverses plateformes.

Ajout des nouvelles propriétés wrapper.logfile.close.timeout et wrapper.logfile.flush.timeout, et dépréciation de la propriété wrapper.logfile.inactivity.timeout, pour augmenter le contrôle sur le moment et la façon dont le fichier journal est vidé et fermé.

Ajout d'un nouveau paramètre PIDFILE_CHECK_PID dans le script shell UNIX qui permet de contrôler si le script vérifie deux fois que le pid dans un fichier PID existant est effectivement le pid du Wrapper de l'application. Cette propriété permet de désactiver cette vérification afin que plusieurs applications puissent être liées au même fichier pid.

Parcours du code pour s'assurer qu'aucune des méthodes JNI natives du Wrapper n'est appelée après que l'arrêt du WrapperManager soit terminé. Cela provoquait un plantage de la JVM sur certaines JVM Linux. Cela se produisait lorsqu'une instance WrapperResources était finalisée par le ramasse-miettes à l'arrêt.

Correction d'un problème où les processus créés en appelant les fonctions WrapperManager.exec() pouvaient ne pas être enregistrés auprès du Wrapper pour le nettoyage si l'appel était effectué alors que la JVM s'arrêtait. Cela a été résolu en s'assurant que les appels JNI ne peuvent pas être effectués après que l'arrêt du WrapperManager soit terminé.

Modification du thread interne de tick du WrapperManager afin qu'il soit autorisé à se terminer une fois que le WrapperManager s'est complètement arrêté. C'était la seule référence restante à la classe WrapperManager.

Ajout d'une nouvelle propriété wrapper.property_warning.loglevel qui contrôle le niveau de journal auquel le Wrapper journalisera les avertissements concernant les variables d'environnement non définies mais référencées, ainsi que les valeurs boolean ou integer invalides.

Mise à jour de la façon dont les références de variables d'environnement dans les valeurs de propriétés sont analysées afin de pouvoir signaler celles qui ne sont pas définies. Chaque paire de '%' est désormais censée faire partie d'une référence de variable. Par exemple "%AAA%BBB%CCC%", auparavant si "AAA" n'était pas défini, "BBB" était localisé, mais désormais seuls "AAA" et "CCC" seront reconnus comme des variables.

Correction d'un problème sous Windows où un répertoire wrapper.working.dir inexistant provoquait plusieurs messages d'erreur dans le fichier journal.

Modification du fonctionnement de la propriété wrapper.environment.dump afin qu'elle journalise désormais au niveau INFO avec le reste de la sortie du Wrapper lorsqu'elle est définie sur TRUE. Lorsqu'elle est FALSE cependant, la sortie sera journalisée en sortie DEBUG si elle est activée. Les versions précédentes journalisaient toujours la sortie au niveau de journal INFO dans les deux cas.

Correction d'un problème sous Linux IA64 où le WrapperActionServer levait une IOException lorsque la JVM était arrêtée en appelant System.exit. Cela ne causait aucun problème autre que le message dans le journal.

Ajout de nouveaux événements "jvm_ping_timeout", "jvm_ping_slow" et "jvm_ping_response_slow" pour aider à répondre aux problèmes liés au ping.

Correction d'un problème où une valeur de 0 pour la propriété wrapper.ping.alert.threshold ne désactivait pas correctement les alertes de seuil de ping.

Correction d'un problème où le thread qui gère les événements restait définitivement bloqué si la file d'attente d'événements se remplissait. C'était très peu probable mais pas impossible si un grand nombre d'événements de filtre étaient déclenchés en un temps très court. Correction du problème afin qu'il se rétablisse correctement, mais également augmentation de la taille de la file d'attente pour rendre le débordement encore plus improbable.

Correction d'un problème où la sortie console des processus wrapperW.exe lancés lorsque la propriété wrapper.ntservice.console était TRUE n'était pas affichée correctement. Ce problème a été introduit dans la version 3.5.19.

Améliorations supplémentaires de l'empreinte mémoire du Wrapper pour minimiser la mémoire requise lors de la journalisation de la sortie JVM constituée de très longues lignes.

Correction d'un débordement de tampon potentiel mineur, qui pouvait se produire si le chemin du premier élément de classpath est supérieur à 1024 caractères. Ce débordement a été détecté lors d'une revue de code et nous n'avons aucun rapport indiquant qu'il ait réellement causé des problèmes.

Amélioration du message d'erreur affiché lorsque le fichier de configuration du Wrapper n'a pas pu être chargé afin qu'il inclue désormais le nom du fichier.

Contournement d'un bogue de la bibliothèque système libc sur certaines plateformes HPUX dans lequel les appels à vswprintf peuvent provoquer un plantage si la chaîne développée ne tient pas dans le tampon. Contournement du problème avec l'aide du support HP en s'assurant que la longueur du tampon suivait une règle afin que sa longueur soit 1+N où N est un multiple de 8.

Correction d'un problème sur les plateformes HPUX où la JVM restait parfois bloquée à l'arrêt, lorsque l'arrêt était initié depuis la JVM, amenant le Wrapper à devoir la tuer de force. Cela était dû au Wrapper tentant de fermer le socket backend alors qu'une autre lecture était bloquée en tentant de lire depuis le même socket. Ceci a été introduit dans la version 3.5.8.

Correction d'une corruption potentielle du journal lorsque des messages de journal mis en file d'attente étaient plus grands que la taille du tampon interne. Découvert lors d'une revue de code et il n'est pas connu que cela ait réellement causé des problèmes.

Correction d'une faute de frappe dans le script shell qui cassait la commande 'install' sur les plateformes Solaris.

Correction d'un plantage potentiel sur les plateformes HPUX si la valeur de la propriété wrapper.port.address avait un problème d'encodage.

Correction d'un problème dans le fichier batch, où un espace dans le chemin vers le fichier wrapper.exe empêchait le script de localiser le fichier wrapper.exe. Introduit dans la version 3.5.18.

Lors de l'exécution en tant que service Windows avec masquage de la console, le Wrapper désactivera la journalisation inutile vers la console afin d'améliorer les performances.

Correction d'un problème où un caractère pourcentage '%' non fermé ouvrait la possibilité d'un pointeur dangling dans les paramètres java supplémentaires. Le caractère '%' est un caractère spécial, spécifiant une variable d'environnement. Merci et crédits à Geoff.

Ajout de la variable _WRAPPER_DIR aux fichiers batch pour permettre de spécifier n'importe quel autre répertoire où se trouve le fichier binaire du Wrapper. Jusqu'à présent, le fichier batch et le fichier exe devaient se trouver au même emplacement.

Ajout de la propriété wrapper.port.address, qui permet de spécifier une adresse différente à laquelle lier le socket lors de l'utilisation de la connexion backend par socket entre le Wrapper et la JVM. Jusqu'à présent, le socket était toujours lié à l'interface de bouclage localhost.

Le script utilisera désormais également update-rc.d pour installer une application en tant que démon sous Debian. Merci et crédits à Haifeng.

Chaque fois que le Wrapper provoque la terminaison forcée de la JVM, le Wrapper s'assurera que la JVM a effectivement été terminée. Si ce n'était pas le cas après wrapper.jvm_terminate.timeout secondes, un redémarrage en attente sera annulé et le Wrapper se terminera.

Refonte de la façon dont le Wrapper traite la sortie de la JVM, afin d'augmenter les performances sur une sortie volumineuse sur une seule ligne et également de réduire l'utilisation mémoire.

Ajout d'une nouvelle propriété wrapper.java.additional.default.stripquotes pour permettre de spécifier la valeur par défaut de la propriété wrapper.java.additional.<n>.stripquotes.

Correction d'un bogue où la minuterie échouait à calculer l'heure de déclenchement lorsque cette heure était à plus d'une semaine dans le futur. Cela était possible pour les minuteries hebdomadaires qui chevauchaient un changement d'heure d'été reculant l'heure d' une heure à l'automne.

Correction d'un problème dans le script shell, où il pouvait échouer à supprimer un démon installé après que l'emplacement du script ait été modifié. Merci à Leo.

Ajout de messages de conseil supplémentaires lorsqu'un service Windows échoue à démarrer en raison de problèmes d'accès aux fichiers impliquant le binaire du Wrapper, la configuration ou les fichiers journaux.

Correction d'un problème où la bibliothèque dynamique sous Mac OS X n'était pas capable de charger ses fonctions. Les versions affectées étaient toutes les versions Mac OS X de la série 3.5.16.

Ajout de la propriété wrapper.app.parameter_file, qui fonctionne de manière similaire à la propriété wrapper.java.additional_file

Réduction de la consommation CPU de la fonction WrapperProcess.waitFor().

Réessayer les mappages de partages ayant échoué si l'hôte cible ou le réseau est inaccessible, car il peut s'agir d'un problème temporaire.

Il y avait un problème où la redirection d'E/S d'un processus enfant créé avec l'API WrapperManager.exec et utilisant la fonctionnalité d'exécution du processus enfant sur le bureau de l'utilisateur connecté ne permettait de créer un processus qu'une fois par seconde.

Inclure des informations sur le fichier de configuration de base dans la sortie de débogage lorsque le débogage des fichiers de configuration en cascade a été activé.

Ajouter une vérification dans le script UNIX pour afficher un message d'erreur plus descriptif lorsque l'utilisateur spécifié dans la variable RUN_AS_USER n'existe pas.

Corriger un problème où la sortie des journaux de la console n'était pas affichée correctement lors de l'exécution avec le binaire wrapperW.exe lorsque la propriété wrapper.ntservice.console était définie sur « TRUE ».

Implémenter la propriété wrapper.ntservice.generate_console lors de l'utilisation du binaire wrapperW.exe afin qu'il soit désormais possible de désactiver la création de la console cachée.

Modifier le fonctionnement de la propriété wrapper.ntservice.generate_console afin qu'il soit désormais plus facile de désactiver la génération de la console en utilisant uniquement cette propriété.

Améliorer le message enregistré lorsque le Wrapper tente d'effectuer un vidage de threads sans qu'une console valide soit disponible.

Ajouter les nouvelles propriétés wrapper.ping.alert.threshold et wrapper.ping.alert.loglevel qui facilitent grandement le débogage des problèmes de délai d'attente de ping en demandant au Wrapper d'enregistrer des messages concernant les réponses de ping plus courtes que le wrapper.ping.timeout enregistré, mais plus longues que le seuil.

Ajouter une nouvelle méthode WrapperManager.appearSlow qui facilite le test du comportement du Wrapper lorsque la JVM est lente à répondre aux commandes.

Ajouter une nouvelle propriété wrapper.disable_tests qui peut être utilisée pour désactiver toutes les méthodes de test de la classe WrapperManager. Il a toujours été possible de contrôler leur accès avec un SecurityManager, mais c'est plus simple pour la plupart des applications.

Mettre à jour le modèle de fichier de configuration par défaut du Wrapper wrapper.conf afin qu'un redémarrage dû à un filtre OutOfMemoryError correspondant ne soit plus déclenché par défaut si l'utilisateur active la sortie -verbose:class.

Corriger un problème sur les plateformes UNIX où le Wrapper échouait à démarrer s'il se trouvait dans le PATH du système. Ce problème existait depuis la version 3.3.0 mais était passé inaperçu car le Wrapper n'est généralement pas référencé de cette manière.

Retravailler les indicateurs internes régissant la génération et le masquage de la console backend sous Windows afin de pouvoir presque toujours obtenir le handle de fenêtre de la console.

Nettoyer une partie du code de démarrage pour réduire la duplication et s'assurer que davantage de messages de débogage et d'avertissement sont enregistrés après le message "Wrapper Started".

Ajouter les nouvelles propriétés wrapper.java.additional_file et wrapper.java.additional_file.stripquotes pour permettre de spécifier des paramètres JVM dans un fichier.

Ajouter la prise en charge de Linux sur les systèmes ARM.

Réactiver le rechargement forcé du registre SYSTEM (et, s'il est défini sur un compte spécifique, de l'utilisateur) avant de lancer le Wrapper en tant que service sous Windows XP et 2003. Cela avait été désactivé à l'origine pour Windows XP et 2003 depuis la version 3.5.5.

Corriger un problème où les noms de classes d'instances enregistrés lors d'un interblocage impliquant des instances ReentrantLock étaient corrompus. La détection réelle de l'interblocage fonctionnait correctement et seule la sortie contenait potentiellement des caractères illisibles, ce qui pouvait à son tour entraîner d'autres problèmes causés par la corruption de la sortie. Une solution de contournement pour les versions antérieures à 3.5.16 consisterait à définir la propriété wrapper.check.deadlock.output sur SIMPLE.

Permettre de désactiver complètement les détails d'un interblocage en définissant la propriété wrapper.check.deadlock.output sur NONE.

Les identifiants d'objets dans les rapports de vidage de threads n'étaient pas correctement enregistrés en tant qu'identifiants 64 bits sur les JVM 64 bits dans certains cas.

Corriger un problème où les valeurs de code source renvoyées par la méthode WrapperServiceActionEvent.getSourceCode() étaient incorrectes. Les valeurs des constantes étaient incorrectes et ont été corrigées à partir de cette version.

Ajouter les nouvelles méthodes WrapperServiceActionEvent.getSourceCodeName() et WrapperServiceActionEvent.getSourceCodeName(int actionSourceCode) qui renvoient un nom localisé de la source d'où l'événement est originaire.

Corriger un problème mineur où quelques codes de paquets backend peu courants n'étaient pas correctement identifiés par leur nom dans la sortie du journal de débogage. Fonctionnellement, ils fonctionnaient tous correctement.

Ajout de la propriété wrapper.ping.timeout.action , qui permet de spécifier une action en cas de déclenchement du délai d'attente. Jusqu'à présent, la seule action était de redémarrer la JVM.

Corriger un problème où un processus JVM n'était pas complètement arrêté sur une plateforme UNIX et restait zombie après un arrêt forcé jusqu'à ce que le processus Wrapper lui-même s'arrête. Cela était particulièrement notable si la JVM est figée et que la JVM est tuée de force.

Mettre un texte plus descriptif dans le cas où le Wrapper utilise la méthode d'intégration 4, mais que le fichier jar ne spécifie pas correctement la Main-Class dans ses méta-informations.

Corriger un bug lors de l'échec de l'octroi de la permission LogOnAsService à un utilisateur de domaine.

Corriger un bug où l'ident pour le syslog sur les plateformes UNIX était cassé depuis la version 3.5.0. Cela était dû au fait que, lors de l'ouverture du syslog, le Wrapper libérait la mémoire pointant vers ident. Cependant, le pointeur de chaîne ident est conservé en interne par les routines Syslog. Et il ne faut pas libérer la mémoire vers laquelle ident pointe. Bug #3404978.

Ajouter une vérification dans le script pour s'assurer que la commande 'tr' existe sur les plateformes UNIX.

Améliorer l'analyse des formats de journal afin que les jetons de format soient reconnus même s'ils sont en minuscules. Cela concerne les propriétés wrapper.console.format, wrapper.event.default.email.maillog.format, wrapper.logdialog.format et wrapper.logfile.format.

Le Wrapper analyse les formats de journal en recherchant des jetons connus, et tous les jetons invalides sont simplement ignorés. Si l'ensemble du format est constitué de jetons invalides, cela entraînait l'enregistrement d'une ligne vide par le Wrapper, ce qui n'était pas très utile et causait de la confusion. Le Wrapper revient désormais au format de journal par défaut dans de tels cas. Cela concerne les propriétés wrapper.console.format, wrapper.event.default.email.maillog.format, wrapper.logdialog.format et wrapper.logfile.format.

Améliorer la sortie de débogage lors du chargement des bibliothèques natives afin d'éviter toute confusion sur la signification de l'avertissement enregistré concernant les tentatives de chargement de fichiers de bibliothèques natives portant des noms alternatifs.

Corriger un problème sur les plateformes UNIX où le umask par défaut était défini sur 0000 plutôt que d'être hérité du processus parent lors de l'exécution en tant que processus démon. Cela peut poser un problème de sécurité car les fichiers journaux et autres ont un accès en lecture/écriture global. Introduit dans la version 3.5.8. Peut être contourné en définissant la propriété wrapper.umask sur une valeur sûre.