Revue de Presse Xebia

La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.

Actualité éditeurs / SSII

• Sortie de Wicket 1.3.1
• Sortie de Grails 1.0

Agilité

• Comment mesurer le succès d’un projet agile du point de vue client ?

Le coin de la technique

• Eclipse 3.4 M5 : le Breadcrumb Mode
• Les différents GC de la JVM
• Test Unitaire avec Spring MVC
• Websphere Webcast : Prepare for Problem Determination for WebSphere Application Server

---

Actualité éditeurs / SSII

Sortie de Wicket 1.3.1

Il y a un mois nous annoncions la sortie de Wicket 1.3.
Comme un peu de teasing ne fait pas de mal, nous profitons de la sortie version 1.3.1 pour vous annoncer une prochaine série de billets dédiée à ce Web Framework.
Quant à cette version, la principale nouveauté concerne le support transparent et out-of-the-box d’un mode cluster.

Sortie de Grails 1.0

Grails est défini comme ‘the ultimate rapid prototyping for Java’ par certains. Il s’agit d’un framework web s’inspirant de Ruby on Rails écrit en Java et de Groovy. Grails repose sur des frameworks ayant fait leurs preuves comme Spring et Hibernate.
Vous pouvez télécharger Grails à cette adresse, sa documentation est disponible ici.

Agilité

Comment mesurer le succès d’un projet agile du point de vue client ?

Vikas Hazrati revient dans InfoQ – Discussion: Measuring Success of an Agile Project from the Customer’s Perspective sur un échange ayant eu lieu sur le user group Scrum Development.
Il y offre des pistes pour définir quels éléments de mesure peuvent (devraient) être communiqués par l’équipe afin qu’un client puisse mesurer sa satisfaction (et donc le succès du projet).

Le coin de la technique

Eclipse 3.4 M5 : le Breadcrumb Mode

Le projet Eclipse vient de mettre à disposition le MileStone 5 de la version 3.4 – Projet Ganymede (Date de Sortie prévue le 25 juin). Parmi les évolutions marquantes, on peut noter le Breadcrumb Mode. Une fois activé, Eclipse ajoute sur chaque fichier ouvert une barre de navigation horizontale qui indique les différents éléments qui mènent à la sélection courante. Dans cette vidéo, on voit l’évolution de cette barre en fonction de la sélection: une classe, une méthode, une inner-classes et une méthode de l’inner-classe.

Démonstration en vidéo : Breadcrumb.wmv.

Les différents GC de la JVM

Ce post de Jon Masamitsu présente les particularités des différents algorithmes offerts par la JVM pour gérer et libérer les différentes zones mémoires d’une JVM Sun. Il dévoile également un nouveau type de ‘collector’ qui serait disponible et utilisé par défaut dans la prochaine version de Java, le ‘Garbage First’ ou G1. L’idée principale est ne plus diviser la mémoire en deux zones (Young & Tenured) mais en plusieurs régions dont le rôle majeur (Young/Tenured) serait déterminé au runtime.

Test Unitaire avec Spring MVC

Le nombre de tests unitaires d’un framework de présentation est souvent faible en comparaison des autres parties de l’application. C’est sur ce constat que le framework Spring MVC a mis l’accent sur l’outillage de ces tests unitaires.
Craig Walls et John Ferguson Smart nous présentent respectivement leurs conseils dans Unit-testing Spring MVC: It gets even awesomer et Unit testing your Spring-MVC applications. Il n’y a plus d’excuses !

Websphere Webcast : Prepare for Problem Determination for WebSphere Application Server

Yu Tang, membre du WebSphere SWAT team, nous présente Prepare for Problem Determination for WebSphere Application Server . Les points essentiels :

• La gestion d’un problème sur un serveur J2EE se décompose en trois étapes :
     – Collecte des informations de diagnostique. Cette phase est essentielle pour la correction sur le fond du problème.
     – Fix en urgence et redémarrage du serveur.
     – Correction sur le fond du problème.
• Les problèmes se regroupent en deux grandes familles :
     – Les crashs (JVM, système, etc).
     – Les blocages / dégradations de performances (avec ou sans consommation élevée de CPU).
• Les principales informations à collecter sont :
     – Les classiques logs SystemOut et SystemErr sans oublier les informations de FFDC et d’activity.log.
     – Les logs de VerboseGC : un très bon indicateur de l’état de santé de la JVM. VerboseGC mérite d’être activé en permanence car son impact sur les performances est très faible (il faut toutefois gérer la purge régulière du fichier).
     – Les javacores (aka thread dumps) : essentiels pour diagnostiquer les blocages/dégradations de performances.
     – Vmstat et netstat : compléments des javacores en cas de problème de performance.
     – Les heap dumps : essentiels pour traiter les OutOfMemoryError. Préciser la variable IBM_HEAPDUMPDIR pour diriger ces logs très volumineuses sur un système de fichiers dédié pour prévenir les problèmes file system full [1].
     – Il faut rédiger et tester régulièrement les procédures de collecte des informations de diagnostiques (notamment les heap dumps et les java cores).

Un complément pour approfondir le sujet : The Support Authority: 12 ways you can prepare for effective production troubleshooting par IBM Software Services for Websphere.

[1] Ce système de fichiers dédié (e.g. /coredumps/) sera mutualisé entre les différentes applications java voire avec d’autres applications qui peuvent générer des cores volumineux. Ce système de fichiers est destiné à devenir plein si le problème se répète rapidement et que le nombre de cores se multiplie. Son but est d’éviter de remplir les autres systèmes de fichiers.