Les exemples de prise en main du framework Grails ne manquent pas sur la toile. Nous allons tenter de dépasser les Getting started en déroulant la réalisation d'une application web de bout en bout :

• Conception
• Réalisation
• Mise en production
• Evolutions et maintenance

Parce qu'il est toujours plus agréable de travailler sur du concret, nous allons réaliser pas à pas une plateforme de musique libre en ligne, que nous baptisons : Projet NoThunes, en clin d'oeil à une autre célèbre plateforme de musique payante. Tout le code du projet est disponible sur GitHub. Ce projet est donc Open Source mais aussi "Open méthode" puisque je vous ferai partager toutes les étapes de conception/réalisation au travers d'une série d'article. Chaque article sera associé à un tag du dépôt GitHub, pour que tout le monde puisse savoir à quelle version on se réfère.

Bien évidemment il y a plus d'une bonne façon de faire. Ce projet est mené dans une optique d'amélioration personnelle et de partage donc n'hésitez pas à discuter les choix techniques et à fournir des solutions alternatives en commentaire.

Dans ce premier billet, nous allons :

• définir le product backlog du projet
• présenter les classes du modèle
• démarrer notre projet
• mettre en place la sécurité et les classes du modèle
• créer un menu dynamique, différencié par rôle utilisateur

Note technique

Le projet est réalisé avec Grails v1.3.3.

Product Backlog

On distingue 3 rôles utilisateurs :

• les administrateurs : par définition omnipotents sur le site pour gérer les comptes utilisateurs, les règles de sécurité, etc.
• les internautes : les visiteurs lambda de notre site.
• les membres : des internautes qui se seront enregistrés pour accéder à plus de fonctionnalités.

En sachant qu'un membre, s'il est authentifié, doit conserver l'accès à toutes les fonctionnalités des internautes, et qu'un administrateur doit aussi avoir accès aux fonctionnalités des membres.

Le product backlog est trié par business value décroissante. Je vous épargne le chiffrage agile et les fioritures de Scrum.

Présentation du modèle de données

Il s'agit d'un cas d'école donc nous simplifions à l'extrême le modèle de données à gérer. Le but n'est pas (encore ) de concurrencer les plateformes en place. On considère donc les objets :

Les attributs de chacun de ces objets sont volontairement simplistes. Cela nous donne le modèle suivant :

Démarrage du projet

Comme tous ceux qui ont déjà survolé Grails le savent, un nouveau projet démarre toujours par le lancement de la commande :

qui va générer l'arborescence initiale du projet. Comme c'est toujours plus confortable, l'étape suivante sera d'importer ce projet dans votre IDE favori. Pour travailler avec Grails le choix est limité et le support inégal : NetBeans, SpringSource Tool Suite ou IntelliJ IDEA. Au pire un bon vieux vim suffira.

Mise en place de la sécurité

Le plugin de sécurité officiel du projet Grails est depuis peu le Spring Security Core Plugin, couplé au plugin Spring Security UI pour la génération des écrans de CRUD concernant les rôles et utilisateurs. Malgré cela, je lui préfère encore pour quelques temps son prédécesseur : Acegi Plugin, dont le développement a été stoppé, mais qui est plus complet et plus simple à mettre en place. D'autre part, le côté stable du plugin Acegi, comparé au développement hyperactif des plugins Spring Security est assez confortable pour notre projet.

Je vous renvoie donc au précédent article que j'ai écrit sur le sujet. Le package de base à utiliser est : fr.xebia.nothunes.

Création des classes du modèle

Maintenant que nous avons les classes utiles pour la gestion des utilisateurs et de la sécurité, ajoutons un peu de métier dans tout ça. Pour cela on utilise la commande grails create-domain-class pour chacune des entités qu'on souhaite obtenir, puis on passe en édition dessus pour ajouter les attributs. Je trouve dommage de n'avoir pas plus poussé la ressemblance avec Ruby on Rails en autorisant l'ajout des attributs directement en paramètre de la ligne de commande.

Parmi les attributs que l'on donne à chaque classe, il y en a 2 qui sont partout et bien utiles : lastUpdated et dateCreated. Ces 2 attributs indiquent à GORM qu'il faut gérer le timestamping automatique des objets qui les possèdent.

Dynamisons le menu

La documentation du plugin Acegi n'en parle pas mais si vous téléchargez les sources du plugin et que vous allez voir le fichier grails-app/taglib/org/grails/plugins/springsecurity/taglib/AuthorizeTagLib.groovy vous tombez alors sur une taglib tout à fait disponible dès que vous faites usage de ce plugin dans votre projet, et qui offre les tags suivants :

• ifAllGranted
• ifNotGranted
• ifAnyGranted
• loggedInUserInfo
• isLoggedIn
• isNotLoggedIn
• loggedInUsername

Nous allons baser la différenciation des menus sur ces tags qui permettent de tester, directement dans les GSP si l'utilisateur courant possède un rôle donné ou non.

La première étape est de séparer le contenu du menu dans un fichier GSP à part. Pour l'instant notre application est telle que générée par grails. Dans le fichier grails-app/views/index.gsp se trouve la page d'accueil par défaut. Elle contient une balise <div id="nav"/> qui encapsule le menu de gauche de la page d'accueil de l'application.

Pour ajouter plus de flexibilité, on sort cette div dans un nouveau fichier qu'on va placer dans grails-app/views/menu/_nav.gsp (après avoir créé le répertoire menu bien sûr), puis on remplace dans index.gsp la présence de cette div par un tag

Si vous lancez un grails run-app et que vous allez voir la page d'accueil vous remarquerez que rien n'a changé. Le paramètre passé au tag render indique d'inclure le code du fichier GSP situé dans le répertoire menu/ et nommé _nav.gsp (le caractère est indispensable en début de nom).

Ce découpage, allié aux tags du plugin Acegi, nous conduit à un joli découpage propre :

grails-app/views/menu/_nav.gsp

grails-app/views/menu/_admin.gsp

grails-app/views/menu/_user.gsp

grails-app/views/menu/_all.gsp

Maintenant il suffira d'utiliser le tag <g:render template="menu/nav" /> directement dans le layout global pour appliquer le menu sur toute notre application, et on a maintenant un fichier GSP par section de menu avec juste ce qu'il faut de tag de sécurité pour gérer l'affichage contextuel.

Après ce découpage, j'ai travaillé un peu le layout et la css afin d'avoir toutes les pages aux couleurs du projet, c'est toujours plus agréable pour travailler. Pour éviter de surcharger cet article, si vous voulez voir le détail complet du travail de mise en forme, reportez vous au GitHub du projet.

Debriefing

Voilà un bon démarrage pour notre plateforme de musique. Le projet est lancé et nous pouvons travailler dans de bonnes conditions pour la suite. L'état du product backlog :

Notre projet est déjà livrable en production avec ces fonctionnalités.

A bientôt pour le prochain épisode :

Ressources

• Site officiel de Grails
• Dépôt GitHub du projet NoThunes
• Tag de la version décrite dans ce billet

Tout d'abord, nous ferons un point sur les problèmes posés par la gestion des bases de données, puis nous verrons comment Liquibase, outils de refactorisation, peut nous aider à les surmonter.
Nous continuerons par la description de ses caractéristiques et fonctionnalités principales et par les différents moyens de l'exécuter.
Un petit exercice pour se familiariser avec cet outil viendra conclure ce billet.

Problèmes posés par la gestion des bases de données

Lorsqu'un projet démarre, on se demande souvent si l'on doit installer une base de données par développeur ou une base commune pour tous.
Sur des projets de taille réduite, une base peut suffire et une personne est désignée pour centraliser les changements et éviter ainsi des problèmes de redondance, d'incohérence, etc. Mais dans ce cas-là, dès qu'un changement est effectué, tout le monde doit impérativement mettre à jour le modèle objet sinon il court le risque de ne plus pouvoir lancer l'application. Par ailleurs, les jeux de tests de chaque développeur peuvent "se télescoper" ce qui peut faire perdre beaucoup de temps.
Sur des projets plus importants, il est préférable d'avoir une base par développeur, ce qui cause d'autres difficultés, telles que les répercutions des changements d'un développeur à l'autre ou encore une intégration plus laborieuse.
Se pose aussi la question suivante : comment va-t-on tracer les changements successifs ? Le plus courant reste d'écrire un fichier d'update SQL mais ce n'est pas fait systématiquement pendant les développements et ça manque de structure (au sens XML) et ça pas de signification propre. Par exemple, rien ne permet rapidement de différencier dans un script, le code qui applique les changements de celui qui les rollback (à part les commentaires !); ou les actions comme "Renommer" se traduisent par un DROP COLUMN / ADD COLUMN, ce qui fait perdre le sens de l'action.
Cette dernière question amène à s'en poser d'autres :

• comment versionner les changements effectués sur une base de données ?
• comment appliquer les changements ? Entre développeurs, mais aussi lorsqu'on passe en intégration, puis en recette, etc. Pour le moment, cette étape prend du temps, que ce soit en amont si on décide de packager correctement les changements, ou en aval lorsqu'il s'agit de dérouler les scripts.

Voilà en quelques phrases les multiples difficultés rencontrées lorsqu'on souhaite refactoriser une base de données.
Regardons à présent ce qu'un outil comme Liquibase peut faire pour nous accompagner dans ce travail délicat.

Refactorisation de bases de données avec Liquibase

Liquibase est un outil qui peut s'intégrer dans un projet (Ant, Maven, etc.) ou se lancer en mode standalone directement en ligne de commande (jar).
Son objectif est de faciliter les modifications apportées à une base de données. Il est particulièrement pratique dans des projets ayant adoptés une méthodologie Agile, car les changements sont nombreux, fréquents et importants.
Le développeur enregistre dans un fichier XML (changelogs.xml), les différentes refactorisations qu'il souhaite effectuer (création d'une nouvelle table, renommage d'un champ, insertion de données, etc.). Ensuite, il suffit de lancer Liquibase en lui donnant les paramètres de connexion à la base de données et le fichier changelogs.xml. Liquibase applique ces modifications et les trace dans une table.
Les fichiers changelogs.xml sont versionnés dans le gestionnaire de sources, et sont considérés comme n'importe quelle autre ressource du projet. La base de données est alors complètement intégrée au cycle de développement.

Après cette brève présentation de Liquibase, intéressons-nous aux caractéristiques principales de cet outil.

Caractéristiques et fonctionnalités principales

Liquibase est Open Source diffusé sous licence LGPL. Ce projet Open Source est actif, la dernière version (1.8.1) est sortie en octobre 2008 et sa road map montre qu'il veut aller encore plus loin. Il supporte un grand nombre de bases de données (> 10) et propose plus de 30 refactorisations possibles. Et pour certaines, il sait même faire un roll back (Ex: renommer une colonne).
Les changements peuvent être regroupés dans un changeset, ce qui permet de conserver un sens et une cohérence aux modifications.
On peut également n'exécuter des changements que sous certaines conditions, ou selon un certain profil d'exécution (utile pour les jeux de tests par exemple).

On peut noter également que Liquibase n'est pas juste "braqué" vers la refactorisation de la base de données, il offre d'autres fonctionnalit

Les 10 commandements des logs applicatives

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 »

Simplifiez votre configuration Spring 2.5 avec les annotations

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 »

Programmation concurrente : notions fondamentales

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 »

• 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.

Les 10 commandements

1. Les logs sont un outil collaboratif issu d'un processus itératif.
2. Les logs sont une brique applicative intégrée à l'environnement d'exécution de l'application.
3. Les logs sont paramétrées en fonction des besoins.
4. Les logs doivent avoir un impact minimal sur les performances globales de l'application.
5. Les logs ne doivent pas occasionner de perte d'information.
6. Une utilisation correcte du logger est la première source d'information.
7. L'utilisation du framework de logs doit être simplifiée.
8. Une log efficace doit remplacer le debugger.
9. Le framework mis en place doit servir exclusivement à produire des logs applicatives.
10. Les logs permettent de décrire le comportement aux frontières de l'application.

Entrons dans le détail

1 - Les logs sont un outil collaboratif issu d'un processus itératif

Les messages de logs sont destinés à tous les acteurs du projet.
Il est essentiel de garder à l'esprit, lors de de tout développement, qu'une application est vouée à être développée, puis testée, puis exploitée (et éventuellement corrigée). Les logs doivent prendre en compte ces 3 phases de la vie du projet, et permettre à tous les acteurs intervenant lors de ces différentes phases de pouvoir interagir efficacement.
C'est pourquoi chaque méthode devrait au minimum contenir des traces de niveau INFO, WARN et ERROR, chaque niveau ciblant un des acteurs intervenant sur l'application.
De plus, il est difficile de réaliser une 'bonne' log du premier coup. La pertinence de celle-ci sera renforcée par des échanges constants entre exploitation et développement (ciblage spécifique d'un problème de performance, anomalie non remontée initialement...).
Chaque correction d'anomalie devrait entrainer l'ajout de traces de niveau DEBUG, qui permettront un diagnostic plus fin en cas de nouvelle occurrence.

2 - Les logs sont une brique applicative intégrée à l'environnement d'exécution de l'application

C'est pourquoi il est essentiel de choisir un framework de logs bien intégré dans le middleware utilisé en production.
Ce framework doit pouvoir être utilisé et paramétré aisément pour obtenir des traces de l'ensemble des composants du système, que ce soit de la part de librairies embarquées tierces comme des systèmes 'contenants' (serveur d'application par exemple).
Par exemple, Jakarta Commons Logging est délicat à utiliser avec Websphere.

3 - Les logs sont paramétrées en fonction des besoins

L'écriture d'une log a un coût qu'il ne faut pas négliger. Les performances d'une application en production ne doivent pas être plombées par la génération de lignes de log inutiles. Et il est inenvisageable de demander à chaque développeur d'effacer systématiquement les logs qu'il ajoute (si ces logs ont été utiles à un moment de la vie du projet, il y a de grandes chances qu'elles puissent resservir plus tard).
Il est donc impératif de choisir un framework de logs facilement administrable autant en développement qu'en production :

Pour le développement :

• Une configuration de logs par défaut quand on fait un checkout du code (typiquement un fichier log4j.properties dans le classpath configuré au niveau WARN qui redirige vers System.out).
• La possibilité de modifier à chaud la configuration des logs lors de l'éxécution de l'application dans l'IDE (typiquement un configureAndWatch sur classpath:log4j.properties).

Pour l'exploitation :

• Une configuration par fichiers, séparée du WAR, ce qui permet de livrer / modifier l'application indépendamment de sa configuration (et vice et versa).
• Des mécanismes de reconfiguration à chaud par modification de fichier et/ou par API (JMX).

On se doit d'exploiter au maximum les différents Appenders.
Le système d'Appender fourni avec les principaux framework de log permet de gérer finement la persistence de la trace : elle peut être éphémère, par exemple dans une sortie Console, ou bien être archivée périodiquement, en utilisant un système de DailyRollingFileAppender.
Une bonne connaissance des Appenders est essentielle dans la gestion à long terme de la log, aussi bien en terme de performance (utilisation des Loggers asynchrones en utilisant JMS) qu'en terme d'espace disque (configurer correctement les FileAppenders afin que les fichiers restent exploitables).

4 - Les logs doivent avoir un impact minimal sur les performances globales de l'application

La majorité des frameworks de log disposent de méthodes conditionnelles de type log.is<Priority>Enabled(). Conditionner l'écriture de la log par ces méthodes permet d'économiser des ressources précieuses lors du runtime (construction d'une aggrégation de chaînes de caractères par exemple). La méthode log.<Priority>(String) effectue bien entendu le même test, mais après la résolution des paramètres.

Evitez :

Préférez :

5 - Les logs ne doivent pas occasionner de perte d'information

Ce commandement s'applique plus particulièrement aux logs des exceptions.
Il est primordial de qualifier le plus finement possible les exceptions tracées.
C'est pourquoi on privilégiera systématiquement les méthodes Logger#error(java.lang.Object message, java.lang.Throwable t) à Logger#error(java.lang.Object message) , afin de ne pas perdre les informations exposées par la stackTrace.
De plus, on explicitera au maximum le contexte d'exécution dans le message.

Evitez :

Préférez :

NB : le traitement des exceptions fera l'objet d'un prochain article.

6 - Une utilisation correcte du logger est la première source d'information

Chaque niveau de log a ses spécificités. Bien définir l'utilisation de chacun de ces niveaux permet de s'affranchir du risque de logger trop, ou trop peu, aux différentes étapes du cycle de vie de l'application. Utiliser des niveaux de log cohérents et pertinents donne donc un premier niveau d'information essentiel.
Voici les niveaux existants dans les différents frameworks, et leur utilisation communément admise (Log4J/Apache Commons Logging - java.util.logging) :

• TRACE / FINE : niveau d'information ultrafin.
• DEBUG / CONFIG : information détaillée pour le suivi d'exécution du programme (identification et résolution d'éventuelles anomalies).
• INFO : information essentielle sur le programme, suivi de l'exécution d'un point de vue global.
• WARN / WARNING : situation d'exécution non idéale (utilisation d'API dépréciées, ressource non critique absente...).
• ERROR / <pas d'équivalent> : situation d'erreur ou inattendue, qui n'entraine pas forcément une situation de blocage (accès à un service externe non critique et dont l'accès est re-testé périodiquement).
• FATAL / SEVERE : situation d'erreur critique, qui entraîne un blocage voire un arrêt du système (problème de connexion à la DB par exemple).

7 - L'utilisation du framework de logs doit être simplifiée

L'ajout de log doit être le moins contraignant possible pour les développeurs. De plus, dans le cadre d'une équipe de développement, il n'est pas toujours facile pour un développeur de savoir quelles sont les informations pertinentes à tracer, s'il n'est pas l'auteur de la classe suivie. Il faut donc faciliter la création de logs de qualité...

• ... en rendant ses classes explicites.
  En surchargeant la méthode Object#toString(), afin qu'elle renvoie les informations principales d'une classe, on peut facilement tracer les informations en entrée ou sortie de méthode, et expliciter le contexte applicatif de l'exécution. Attention, les méthodes toString() ne doivent jamais lancer d'exception.

Evitez :

Préférez :

• ... en définissant, documentant et partageant la hiérarchie de logger
  L'utilisation la plus répandue de la hiérarchie de Logger consitste à déclarer un logger par classe.

Cependant, il est souvent interessant de réfléchir à une hiérarchie plus poussée, par domaines technico-fonctionnels par exemple.
Il est parfois même utile de déclarer plusieurs Loggers par classe (un logger pour le suivi de l'exécution générale, un logger particulier pour surveiller une fonction critique)
Afin d'avoir des logs cohérentes, il est nécessaire de définir et de documenter la hiérarchie des Loggers au plus tôt de la vie du projet, et de la communiquer à l'ensemble des équipes, afin d'unifier les méthodes de logging.

8 - Une log efficace doit remplacer le debugger

Il existe un grand nombre de circonstances qui rendent impossible l'utilisation d'un debugger, dont la plus évidente, la nécessité de debugger un système en production. Mais on pourrait aussi citer les traitements multi-threadés, etc
Dans ces cas particuliers, l'utilisation de la log doit se substituer au débuggeur, et répondre aux mêmes besoins : "exécution" pas à pas des algorithmes, inspection des valeurs d'entrée et de sortie des points de passage clefs, parcours des différentes couches de l'application, surveillance des entrées / sorties du système.
La mise à disposition d'un tel outil est vitale pour les développeurs, car trop souvent, les équipes de développements sont dans l'obligation d'attendre plusieurs occurrences d'un même bug en production avant d'être aptes à déterminer ses conditions précises d'occurrence.

9 - Le framework mis en place doit servir exclusivement à produire des logs applicatives

Les logs sont et doivent être un outil technique. Utiliser le framework de log pour générer des traces 'fonctionnelles' (audit, génération de traces métier, constitution de fichiers métier) présente un risque majeur de perte de données. En effet, le risque d'effacement des logs est réel : la configuration des différents Appenders provoquent souvent un effacement périodique des logs, le comportement global des logs peut être totalement modifié dans le cadre d'une intervention de type 'troubleshooting' (limitation des traces à un sous-ensemble de classes très restreint)...
En revanche, il est possible d'utiliser les fonctionnalités offertes par le framework de logs (RollingFileAppender, etc) mais il faut que cette utilisation soit dissociée du fonctionnement et de la configuration des logs applicatives.

10 - Les logs permettent de décrire le comportement aux frontières de l'application

L'un des enjeux majeurs des Systèmes d'Information actuels est l'intégration des différentes composantes de ce SI.
Il est très souvent ardu de suivre intégralement la chorégraphie entre les différents composants, aboutissant à la réponse 'finale' du système.
D'où la nécessité de tracer le plus finement chaque appel entrant ou sortant du système, en utilisant :

• l'heure de cet appel
• le système appelant / appelé (par HTTP, JMS, SOAP...)
• une description concise de l'interaction sollicitée
• éventuellement, au niveau le plus fin (TRACE), le message émis / reçu

Certaines librairies Open Source, comme commons-http-client (HTTP) et CXF (SOAP) offrent ces fonctionnalités de manière native.

En conclusion

L'application de ces 10 commandements nous pousse de manière assez naturelle à l'utilisation de Log4J, qui répond à l'ensemble des besoins listés ci dessus.
Le choix de Commons Logging ou de java.util.logging, si il est loin d'être proscrit, demande une plus grande vigilance (voir les articles 'Critiques' cités en références).

Quoi qu'il en soit, il est primordial d'avoir en tête ces bonnes pratiques dès le démarrage d'un projet. En effet, au même titre que les tests unitaires ou que la documentation interne du code, les logs ne peuvent être repoussées à 'plus tard' : plus le temps passe, plus la complexité et le volume de code à 'tracer' augmentent.
Ceux qui ont expérimenté "l'intervention pompier" sur une application peu ou mal loggée savent qu'il est quasiment impossible d'otenir des logs globales et/ou pertinentes a posteriori (d'autant qu'il est difficile de 'budgeter' une telle opération, dont la valeur métier est nulle).

Références

Les frameworks de logs les plus connus

• Simple Logging Facade for Java (SLF4J) : A simple facade for various logging APIs allowing to the end-user to plug in the desired implementation at deployment time.
• Log4J : Site officiel du framework Log4J
• Java Commons Logging : Site officiel du framework Commons Logging
• java.util.logging : API de java.util.logging

Critiques

• Rod Waldhoff's Weblog - Commons Logging was my fault : une critique de Commons Logging par son auteur
• Tomcat Docs - Logging : The default implemenatation of java.util.logging provided in the JDK is too limited to be useful. ...

Urbanisation pour les nuls

Le XKE (Xebia Knowledge Exchange) de mars a été l'occasion de présenter la démarche d'urbanisation. L'exemple présenté ne suivait pas le déroulement type : une démarche d'urbanisation est adaptée suivant les projets et organisations auxquels elle est appliquée.
Le but de ce billet est de dérouler cette démarche de manière simplifiée. Cela nous donnera l'occasion de définir le vocabulaire employé, et de faire un constat sur cette démarche.
Nous déroulerons l'exemple avec une approche TOP-DOWN, c'est-à-dire que l'analyse commence par la définition de la stratégie pour descendre ensuite au travers des différentes strates du SI. Pour l'exemple, nous prendrons le cas d'une agence de voyages qui achète et vend des voyages.

Lire cet article »

Les 10 commandements des tests unitaires

Les tests unitaires ne sont pas qu'une bonne pratique des méthodes agiles, ils sont un véritable pré-requis à la mise en place d'un développement itératif.
Le refactoring et la modification d'une base de code existante, bien que facilités par les environnements de développement actuels, comportent un évident risque de régression, en partie couvert par les tests unitaires.

Vous trouverez dans ce billet nos 10 commandements des tests unitaires.

Lire cet article »

SpringSource Application Platform : la brèche dans Java EE

L'annonce de SpringSource a des allures de schisme. Après des années à critiquer la complexité et le monolithisme de Java Enterprise Edition (Java EE), les équipes de Rod Johnson ont franchi le Rubicon et proposent un serveur d'applications Java qui ne reposera pas sur la monolithique spécification Java EE.
SpringSource Application Platform se limite à quelques fragments de cette spécification (principalement Servlet et JPA) assemblés dans un conteneur OSGI augmenté de quelques particularités Spring. Les applications web ne seront plus assemblées sous forme de WAR avec un fichier web.xml mais sous forme de plusieurs bundles OSGI avec des fichiers de configuration Spring.

Lire cet article »