Netapsys Blog

L'objet de ce billet, en deux parties, est de comparer l'annotation standard @Resource du package javax.annotation.Resource à celle de
spring @Autowired du package org.springframework.beans.factory.annotation.
Nous verrons les situations où nous sommes obligés de favoriser les annotations standards.

L'utilisation des annotations réduit considérablement la verbosité des fichiers de configuration de Spring.
C'est aussi le même constat pour d'autres frameworks.
En effet, le principe "convention Over configuration" participe à cette diffusion.
Certes, les "pour" et les "contre" ne manqueront pas d'arguments pour débattre.
Mais ceci n'est pas l'objet de ce billet.
L'objectif ici est de comparer ces deux types d'annotations.
Pour cela, nous nous appuyons sur un projet java simple, sans maven, que vous pouvez créer sous Eclipse en suivant les étapes décrites ci-après.
Nous écrivons d'abord un projet avec les annotations de Spring puis nous illustrons les difficultés qui nous amèneront à introduire les annotations standards.

L'objet de ce billet: Illustrer avec un exemple assez complet la mise en pratique du web service REST (JAX-RS) s'appuyant sur l'implémentation RestEasy de JBoss avec Spring 2.5.
L'exemple repose sur les briques (api) suivantes. Notez bien la version lorsqu'elle est mentionnée.

• RestEasy: L'implémentation Jboss de jax-rs (JSR 311),
  
• Spring 2.5 et les annotations,
  
• Hibernate pour la partie persistence
  
• L'api Dozer v4.0 pour les DTO (Data Transfert Objetc) ou VO((Value Object).
  
• Junit 4.4,
• HttpUnit,
  
• XMLUnit.
  

Nota:La version Dozer 4.0 a renommé complètement ses packages. Certains tutos sur le web sont donc caduques.
C'est à la fin de l'étape 5 que nous détaillons l'emploi de l'api Dozer.

Quelques repères:
REST (Representational State Transfer) développé par Roy Fielding qui est l’un des fondateurs du protocol HTTP.
JSR 311 est la spec JAX-RS: Java API for RESTful Web Service. Finalisée en mars 2008.

Les CINQ principes de REST

• P1: Tout est ressource, un identifiant unique à chaque ressource (http://localhost:8888/clients/2 pointe sur le client ayant id=2),
  
• P2: Utiliser les méthodes HTTP (HEAD/GET/POST/PUT/DELETE). Et les erreurs standards HTTP,
  
• P3: Les échanges avec plusieurs représentations ( xml,(x)html, json,..),
  
• P4: Échanges sans état (stateless),
  
• P5: Lier les ressources entre elles.
  

PRÉ-REQUIS: Java5.

En quatre actes, nous allons illustrer la puissance du framework de validation de Spring sans écrire la moindre classe de validation.
En effet, quelques annotations dans vos beans (POJO), trois lignes de configuration et une ligne de code java; et le tour est joué! Le résultat obtenu est impressionnant!
Vos objets sont validés. De plus, la validation est faite côté serveur et client.
Nous détaillerons tout cela sur un exemple intéressant un peu plus loin.
Ma découverte du framework de validation de Spring me fait dire :
Avec Spring, la vie des développeurs (et des chefs de projet) devient un fleuve tranquille de bonnes pratiques même si l'apprentissage, lui, est loin de l'être!

Sans rentrer dans le débat sur la nécessité de valider les objets et du côté client et du côté serveur, ce framework concilie et satisfait les deux avis.


La démonstration qui va être donnée contient deux projets:
- Le premier, projet web Spring MVC avec maven, détaille comment valider, côté client et serveur, nos objets avec les meilleures pratiques.
- Le second, projet java standalone, illustre un certain nombre d'annotations du framework de validation avec peu de lignes de configuration xml.
Et, le tout avec très peu de code java et en recourant aux validateurs prédéfinis de ce framework.
Le résultat est déconcertant!
Ce framework nous épargne des dizaines de lignes de code java (sans parler du temps à consacrer à les tester/déboguer!).
La démo ci-après repose et applique les deux grands principes:

• Tout est POJO,
• Séparation des préoccupations.

Passons à la pratique.....
Un seul pré requis nécessaire : connaître le framework de Spring et Spring MVC.

Les design-pattern (ou motifs de conception) réalisent le principe de ne pas réinventer la roue en capitalisant les expériences.
En effet, un design-pattern décrit à la fois :

• Les situations de conception que l'on rencontre trop souvent dans le développement de logiciels
• Les solutions types (abstraites ou de haut niveau) identifiées pour ces problèmes (formelles ou non, indépendamment des langages objets)
• Les bénéfices d'utiliser ces solutions dans le développement de logiciels.

Les design-pattern offrent donc une description complète des problèmes répétitifs et les solutions abstraites retenues en expliquant les conséquences à l'usage.
Cette description reste indépendante du langage objet et voire du métier développement de logiciels.
Néanmoins, notons que les design ne sont pas des briques logicielles.
Les design-pattern se divisent en trois groupes: les design de création, de structure et de comportement.
Dans ce billet, nous mettons en pratique le design-pattern "observer" faisant partie du dernier groupe.
L'exemple choisi est volontairement simpliste néanmoins il illustre bien une problématique réelle. L'exemple pratique s'appuie sur les classes/interfaces du package java.util
Le seul pré-requis est une petite dose d'abstraction.

Dans le cadre de mes activités, j'ai écrit des scripts Shell ayant pour but de formater des chaînes de caractères à l'intérieur du script, je vous propose de les partager avec vous tout en introduisant des fonctions afin de vous faciliter la prise en main et la réutilisation.
N'étant pas expert du script Shell, tout commentaire est le bienvenu.
Les exemples de scripts donnés ci-après sont testés sous linux et hp-ux.
Le premier exemple étant simple, il prépare le second qui traite du formatage des chaînes. Ceux qui sont pressés peuvent juste jeter un œil sur la seconde partie de ce billet.