Voici la liste des billets les plus lus sur ce blog en juillet, août et septembre :
Tout au long du cycle de vie d’une application J2EE, il est nécessaire de posséder des traces de qualité :
- durant le développement, afin de suivre l’exécution pas à pas et de détecter d’éventuelles anomalies.
- durant la recette, afin de corréler anomalies fonctionnelles et exécution du programme.
- durant l’exploitation, afin de surveiller la « bonne santé » de l’application.
Mais obtenir des traces de qualité n’est pas un exercice trivial. C’est pourquoi nous vous proposons nos 10 commandements des logs.
Lire cet article »
Spring 2.5 est sorti depuis le 19 novembre 2007 comme nous l’annoncions, il y a quelques temps, dans notre revue de presse. Vous avez comme moi sagement mis à jour vos poms Maven2 vers la dernière release de Spring (normalement et la plupart du temps compatible avec les versions 2.0.x).
Mais avez-vous vraiment profité des nouveautés de cette version en terme de configuration ?
Lire cet article »
Jouer avec les Threads n’est pas trivial. En informatique de gestion, cette difficulté est heureusement masquée par les serveurs d’application et les API spécifiques. La plupart du temps, ils permettent aux développeurs de s’abstraire de ces contraintes et de se concentrer sur le code métier, moins technique. Il arrive pourtant qu’il faille se relever les manches. Certains besoins vous ont certainement déjà poussé à faire communiquer 2 Threads.
Si le développement n’est pas facile, le debug peut devenir une calamité ! La programmation concurrente ne soulève pourtant que 3 types majeurs de problèmes. Faites le sondage autour de vous, les développeurs associent trop rapidement le mot clé synchronize au multithreading sans en comprendre véritablement le fonctionnement. Demandez-leur ensuite de vous décrire l’utilité du mot clé volatile …
Cet article revient sur les grands principes de la programmation concurrente.
Lire cet article »
Tout au long du cycle de vie d’une application J2EE, il est nécessaire de posséder des traces de qualité :
- durant le développement, afin de suivre l’exécution pas à pas et de détecter d’éventuelles anomalies.
- durant la recette, afin de corréler anomalies fonctionnelles et exécution du programme.
- durant l’exploitation, afin de surveiller la « bonne santé » de l’application.
Mais obtenir des traces de qualité n’est pas un exercice trivial. C’est pourquoi nous vous proposons nos 10 commandements des logs.
Une application J2EE possède de nombreux types de logs :
- Des logs purement techniques, ponctuelles, générées automatiquement ou à la demande comme les dumps (ThreadDump, MemoryDump…).
- Des logs provenant de l’environnement d’exécution : logs Système (journaux d’évènements serveur…), logs du serveur applicatif et logs générées par les librairies tierces utilisées par l’application.
- Les logs générées par le code développé pour l’application, que nous désignerons comme logs applicatives, sur lesquelles l’équipe projet a la main.
Nous traiterons quasi exclusivement de ces dernières dans cet article.
Lire la suite de cet article »
La MOE et l’exploitation doivent collaborer au jour le jour : la MOE réalise et livre des applications, l’exploitation est en charge de les installer et de les exploiter. Cependant, ces deux équipes, bien qu’elles travaillent dans le même but, n’ont pas les mêmes besoins ni les mêmes problématiques.
Cette divergence n’est pas dramatique tant que la collaboration se passe bien : la MOE est consciente des besoins de l’exploitation et en tient compte en simplifiant la prise en charge des applications par les équipes d’exploitation. Les choses se compliquent bien sûr quand les problèmes et les mésententes arrivent.
Un des problèmes récurrents qui fait intervenir les deux équipes est le déploiement des applications.
Lire la suite de cet article »
L’interview de Guillaume Bodet (Xebia) par Pierre-Olivier Chotard (BEA Systems) vient d’être publiée sur TV4IT.
Guillaume Bodet y partage son retour d’expérience et les meilleures pratiques en matière d’administration et de supervision des serveurs d’applications J2EE.
Cette interview avait été réalisée à l’occasion du TechTalk organisé par BEA sur les thèmes de la supervision, de l’administration et du support (Cf. notre billet du 26 juin : « Supervision, Administration et Support« ).
BEA organise le mardi 10 juillet 2007 un TechTalk sur les thèmes de la supervision, de l’administration et du support.
Un sujet plus que d’actualité puisque, comme le rappelait Luc Legardeur dans son billet « Exploitation J2EE : il y a urgence !!!!« , l’exploitation devient, avec l’augmentation en nombre et en criticité des applications J2EE, une discipline fondamentale pour les départements Production.
Elle nécessite la mise en place de bonnes pratiques de supervision J2EE impliquant tous les membres de l’organisation informatique (Etudes, équipes projets, cellule d’exploitation, …).
La performance, la stabilité des systèmes, la réactivité face aux incidents, le déploiement rapide des nouvelles applications, les exigences sécuritaires accrues mettent la résilience des infrastructures à rude épreuve.
Lire la suite de cet article »
L’exploitation devient, avec l’augmentation en nombre et en criticité des applications J2EE, une discipline fondamentale pour les départements Production. En effet, en 2007, toute déficience dans l’exploitation, aura des répercussions immédiates sur une partie des activités commerciales de l’entreprise.
L’adoption massive des technologies J2EE par les entreprises a contraint les cellules d’exploitation à adresser rapidement (et sans aucune aide particulière) plusieurs défis majeurs :
- Gérer l’augmentation sensible du nombre d’applications en exploitation.
- Rendre un service compatible avec le niveau de criticité des applications utilisées.
- Prendre en charge des cycles de déploiement et de mise à jour toujours plus rapides.
- Appréhender une complexité inhérente à l’empilement de couches logicielles nombreuses, basées sur des technologies nouvelles.
Pourtant, nous constatons tous que nous -collectivement les acteurs de l’écosystème J2EE- n’avons pas donné les moyens aux départements Production de faire leur travail.
Lire la suite de cet article »
Ce billet est le premier d’une série décrivant les principes et composants du « Java Operations Toolkit ». JOT est un projet encore embryonnaire (je le publierai bientôt sous license Open Source, et sous un autre nom, JOT étant déjà pris… Si certains parmi vous ont une idée…). Son objectif est d’offrir aux applications java un ensemble d’utilitaires, d’API et de bonne pratiques visant à en faciliter l’exploitation.
Comme son titre le suggère, ce premier billet concerne la journalisation, connue également sous son sobriquet anglo-saxon de « log ».
Depuis plusieurs années maintenant, l’utilisation d’un framework dédié pour gérer les logs s’est généralisée. Log4j a ouvert la voie, suivi par framework java.util.logging à partir du JDK 1.4, qui adopte une architecture très similaire à celle de log4j, tout en proposant une nomenclature moins intuitive (du moins pour ceux qui pensent que « DEBUG » désigne un niveau de journalisation plus évident que « FINEST »). Citons également les meta-frameworks Commons Logging et SLF4J, qui offrent une couche d’adaptation au dessus des différents frameworks pour en unifier l’usage.
L’objet ici n’est pas de comparer ces différentes solutions : elles sont toutes très proches et offrent toutes les fonctionnalités attendues d’un utilitaire de logging:
- une API simple et intuitive, style log.debug(message) ou log.info(message)
- une configuration externalisée permettant d’activer ou de désactiver certaines traces sans intervention sur les sources ou les binaires
- la possibilité de configurer des flux de sortie divers pour les messages (console, fichiers avec rotation, sockets, base de données, JMS, syslog, NTEventLog, etc.), avec une granularité très fine
- la possibilité de configurer le format des messages
On ne peut que se féliciter de l’adoption massive de ces frameworks, en particulier du plus illustre d’entre eux, log4j. Cette adoption a pourtant bien souvent un revers: disposer de ces fonctionnalités a exempté les architectes et développeurs d’une réflexion réelle sur l’usage des logs. La politique de journalisation se réduit fréquemment à cette simple directive : « Utiliser log4j », et le code est en conséquence saupoudré plus ou moins densément (selon l’humeur ou la sensibilité du développeur) d’instructions du style
Lire la suite de cet article »
Complet
Twitter
