Conseils techniques

• Comment puis-je distribuer le Java Service Wrapper et mon application Java sur différentes plates-formes ?
• Qu'est-ce que DEP/ASLR ?
• Comment puis-je exécuter mon application Java en tant que démon Unix ?
• Comment puis-je restreindre l'exécution de mon application Java à certains processeurs ?
• Comment puis-je exécuter mon application avec le Java Service Wrapper dans Eclipse ?
• Comment puis-je déboguer à distance mon application avec Eclipse ?
• Comment puis-je me protéger des plantages Java ?
• Quelles sont les différentes façons d'arrêter mon application Java ?
• Comment puis-je planifier des redémarrages de JVM, des arrêts, des dumps de threads ou d'autres actions avec mes applications Java ?
• Comment puis-je me protéger des figements Java ?
• Comment puis-je accéder aux partages Windows mappés depuis mon service Java ?
• Comment puis-je exécuter mon application Java en tant que service Windows ?
• Comment puis-je me protéger des interblocages dans mon application Java ?

Le Delta Pack regroupe les binaires et les bibliothèques nécessaires pour que le Wrapper s'exécute sur toutes les plates-formes prises en charge *. Il contient également les fichiers Bat Windows et le script Shell Unix utilisés pour lancer le Wrapper. L'utilisation de ces scripts facilite le lancement du Wrapper, car ils sélectionnent automatiquement les binaires appropriés pour la plate-forme actuelle. En d'autres termes, ils vous permettent de lancer le Wrapper de manière transparente, en utilisant les mêmes commandes sur les différentes plates-formes UNIX (Windows utilisant des fichiers de script bat distincts).

Avec un seul fichier de configuration, vous pourrez configurer le Wrapper pour exécuter votre application Java soit en tant qu'application console, soit en tant que service Windows/démon Unix sur les différents systèmes d'exploitation. Il est également possible d'avoir une configuration spécifique à la plate-forme lorsque le besoin s'en fait sentir.

Le Delta Pack est disponible dans toutes les éditions à partir de la version 3.2.0.

Cliquez ici pour l'article complet.

À partir de la version 3.5.33, le Wrapper indique que ses binaires sont compatibles avec la fonctionnalité Windows Data Execution Prevention (DEP), et précise qu'ils doivent être relocalisés de façon aléatoire au chargement par le système d'exploitation grâce à la fonctionnalité Address Space Layout Randomization (ASLR).

L'utilisation de ces deux fonctionnalités n'a pas d'impact notable sur les performances et permet au Wrapper de s'exécuter de manière beaucoup plus sûre. DEP marque les régions mémoire allouées par le Wrapper comme non exécutables et empêche ainsi l'exécution de shellcode qui serait injecté par un logiciel malveillant. ASLR protège contre les attaques par débordement de tampon en randomisant l'emplacement des différentes parties du programme en mémoire. Chaque fois que le Wrapper s'exécute, la pile, le tas et les bibliothèques sont déplacés vers une adresse différente en mémoire virtuelle, de sorte que les attaquants ne peuvent plus découvrir par essais successifs où se trouve leur cible.

Cliquez ici pour l'article complet.

Habituellement, les applications Java s'exécutent dans un terminal sur les systèmes Unix. Cela nécessite qu'un compte utilisateur soit connecté au système en permanence, et qu'une invite de commandes reste ouverte.

Cela présente plusieurs inconvénients, allant de la sécurité aux performances du système, jusqu'au simple risque qu'un utilisateur appuie sur la mauvaise touche dans l'invite de commandes et tue l'application Java.

Le Java Service Wrapper résout ces problèmes en permettant d'installer votre application Java en tant que démon. Il offre une détection automatique des outils de gestion de services (également appelés systèmes d'init) disponibles sur votre système d'exploitation, ou vous permet de configurer un système spécifique à utiliser lors du lancement de votre application en tant que démon. S'exécuter en tant que démon signifie que votre application s'exécutera en arrière-plan, sera lancée automatiquement au démarrage du système et s'arrêtera proprement lorsque le système s'arrêtera.

Cliquez ici pour l'article complet.

Normalement, c'est au système d'exploitation de décider quels processeurs ou cœurs de la machine seront utilisés pour exécuter une application. En fonction du nombre de threads requis par l'application à un moment donné, et des besoins des autres applications, le système d'exploitation tentera de déplacer les threads selon les besoins afin de maintenir la charge globale de chaque processeur équilibrée.

Dédier des processeurs spécifiques à votre application peut être un moyen de garantir qu'elle disposera toujours de suffisamment de ressources processeur. À l'inverse, vous pourriez explicitement laisser certains processeurs inutilisés afin de garantir des ressources suffisantes pour les autres processus s'exécutant sur la même machine. Dans ce conseil technique, nous vous montrerons comment les applications Java s'exécuteront toujours sur un sous-ensemble désigné de processeurs.

Cliquez ici pour l'article complet.

Il est possible d'exécuter le Java Service Wrapper en tant qu'outil externe pour tester votre application depuis Eclipse. Cela vous évite de changer de fenêtre chaque fois que vous souhaitez lancer votre application avec le Wrapper.

Cliquez ici pour l'article complet.

Eclipse(R) dispose d'un excellent ensemble d'outils tels que le débogueur. Un débogueur permet à un utilisateur de contrôler un programme pendant son exécution. Utiliser un débogueur pour comprendre le fonctionnement d'un programme est un bon moyen de trouver des bogues potentiels. Le débogueur peut être attaché à distance à une JVM s'exécutant dans le Wrapper et vous pouvez voir étape par étape ce qui se passe. Dans l'exemple suivant, vous verrez à quel point le débogueur est facile à configurer.

Cliquez ici pour l'article complet.

Java en tant que langage a été conçu pour qu'il soit impossible que du code développé par l'utilisateur provoque un plantage de l'application. Toute erreur devait se traduire par une exception propre qui pouvait être interceptée, puis traitée de manière appropriée.

La réalité, comme le sait tout développeur Java ou administrateur système expérimenté, est que la machine virtuelle Java (JVM) elle-même peut planter, et plante effectivement. Cela s'explique par le fait que la JVM est elle-même un programme écrit en code natif, et comme tout programme très volumineux et complexe, la JVM comporte quelques bogues.

Cliquez ici pour l'article complet.

Lorsque les utilisateurs commencent à utiliser le Java Service Wrapper, ils s'intéressent généralement à la façon d'intégrer leur application avec le Java Service Wrapper pour l'exécuter en tant que service ou pour la faire surveiller. Cependant, une fois qu'une application est configurée et intégrée à d'autres systèmes, la question de l'arrêt se pose souvent.

Dans ce conseil technique, nous avons parcouru l'API et rassemblé en un seul endroit toutes les différentes façons d'arrêter le Wrapper. Il y a probablement quelques astuces dont même les utilisateurs expérimentés du Wrapper n'ont pas connaissance.

Cliquez ici pour l'article complet.

De nombreuses applications de grande envergure ont besoin de pouvoir exécuter des tâches planifiées ou d'effectuer des actions à des moments précis ou à intervalles réguliers. Le problème est que les différentes plates-formes de systèmes d'exploitation proposent chacune leur propre façon de planifier des actions. Lorsque l'application doit pouvoir s'exécuter sur toutes ces plates-formes, il est souvent nécessaire d'implémenter cette fonctionnalité pour chaque plate-forme individuellement.

Dans ce conseil technique, nous vous présenterons les minuteries du Wrapper, qui permettent de planifier toutes sortes d'actions de manière indépendante de la plate-forme, puis de les déployer avec le reste de votre application.

Cliquez ici pour l'article complet.

Lorsqu'un système critique commence à se bloquer ou à se figer, cela peut être un cauchemar pour l'administrateur système, l'équipe de développement et tous ceux qui utilisent le système. Identifier et corriger le problème peut prendre des jours, voire des mois dans certains cas. Entre-temps, le système est en cours d'utilisation et doit rester opérationnel.

Pour de nombreuses organisations, chaque minute d'indisponibilité d'un système a non seulement un effet direct sur les ventes, mais aussi sur la réputation de l'organisation et des équipes gérant le système. Dans la plupart des cas, la détection des figements du Java Service Wrapper peut réduire le temps d'indisponibilité de plusieurs heures à quelques secondes, de sorte que les utilisateurs finaux ne se rendent souvent même pas compte qu'il y a eu un problème.

Cliquez ici pour l'article complet.

Dans les environnements Windows, il est courant que les utilisateurs mappent des lecteurs réseau et des imprimantes afin qu'ils puissent être accessibles depuis leur système local. Les services Windows ont souvent les mêmes besoins, mais Windows rend très difficile l'accès de ces services à ces partages lorsque le service est lancé au démarrage du système. Souvent, les services auront accès aux partages lorsqu'ils sont démarrés sur un système déjà en cours d'exécution, mais les partages ne seront pas accessibles après un redémarrage du système.

Le Java Service Wrapper permet de configurer et d'accéder de manière fiable aux lecteurs réseau et aux imprimantes sans qu'un utilisateur ait besoin d'être connecté.

Cliquez ici pour l'article complet.

Les applications Java s'exécutant sur des systèmes Windows ont tendance à être lancées dans une console sur un bureau en raison de l'incapacité de Java à s'exécuter en tant que service Windows. Cela présente un certain nombre d'inconvénients : des problèmes de sécurité parce qu'un utilisateur est connecté, des performances système dues au bureau indésirable, et le simple risque qu'un utilisateur appuie sur la mauvaise touche et affecte la console, pour n'en citer que quelques-uns. De nombreuses applications résolvent ces problèmes en s'exécutant en tant que service Windows, le tout sans avoir besoin d'écrire une seule ligne de code dans la plupart des cas.

Cliquez ici pour l'article complet.

La plupart des applications passent par une série de tests rigoureux avant d'être déployées ou publiées. Cependant, comme nous le savons tous, dans le monde réel, des problèmes inattendus peuvent survenir. Malheureusement, un problème courant des applications multithreadées de grande envergure est celui des interblocages. Ils peuvent être fatals et très difficiles à identifier et à corriger.

Le Java Service Wrapper inclut la capacité de surveiller automatiquement votre application à la recherche d'interblocages de manière très légère, ce qui n'entraîne presque aucun changement de performances. Lorsqu'un interblocage est détecté, le Wrapper est capable d'y répondre immédiatement de la manière que vous souhaitez. En même temps, il enregistrera également les conditions précises de l'interblocage afin qu'un développeur puisse facilement le corriger.

Cliquez ici pour l'article complet.