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 pours et les contres 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 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.

L'objet de ce billet est de montrer comment planifier une tâche java avec Quartz et Spring et ce en n'ajoutant que quelques lignes de configuration xml.
Ce "QuickStart" introduisant Spring2.5+ et Quartz 1.6.5+ vous permet d'être opérationnel en 30 minutes.
Quartz est un ordonnanceur (scheduler) qui permet de planifier des tâches batch java (Job) à des intervalles spécifiés. Par exemple, réaliser des traitements lourds (génération de rapports, de statistiques) à des heures où les ressources du serveur sont suffisamment disponibles.
Quartz s’intègre assez facilement dans Spring (sauf peut être en mode Cluster, qui ne sera pas traité ici, pour lequel l'apprentissage est important!).
Afin de faciliter la mise en place de notre exemple, nous avons privilégié le mode RAMJobStore (les Jobs Quartz sont chargés en mémoire sans les persister).
Notre exemple est un projet web mais sachez qu'il est encore plus simple de prendre un projet java. Néanmoins le type de projet web est très instructif.
Nous terminerons ce billet en testant le Job exemple avec une classe JUnit4 avec Spring.
Tous les détails de configuration des dépendances Maven, de Spring et celles de Quartz dans Spring seront donnés.
Nous mentionnons, surtout à l'intérieur des codes, les explications utiles pour comprendre l'api Quartz et toutes les indications nécessaires afin d'éviter les quelques pièges de la configuration Spring-Quartz.
Un seul pré-requis nécessaire: connaître le framework Spring. La connaissance de Quartz peut s'acquérir de manière incrémentale.

Le titre de ce billet montre bien l'étendue des thèmes variés qui seront traités. Il a pour objectif d'illustrer, à l'aide d'un exemple assez complet et proche des cas réels, la mise en place des tests, en mode transactionnel, pour les différentes couches applicatives. Ainsi les vraies difficultés rencontrées par les développeurs seront évoquées.
Le billet traite JUnit4 enrichi avec les annotations de Spring 2.5+ et ses lanceurs pour exécuter facilement les tests. Des illustrations en mode transactionnel vous sont proposées à la fin de ce billet.
Le framework JUnit est l'oeuvre conjointe de Kent Beck (créateur de XP) et Erich Gamma (auteur des Design Patterns).
Avec la version 4, JUnit tente de rattraper son retard sur Testng tout en gardant la compatibilité avec JUnit3x ainsi qu'une parfaite intégration aux éditeurs Eclipse, Netbeans, ...
Avec les lanceurs de spring, les tests deviennent plus attrayants. Spring encourage ainsi à adopter l'approche TDD "Test Driven Design" ou "Test-First Developpment".
Notez que le jdk5+ est nécessaire pour certaines parties de code Java. Les commentaires dans le code java le mentionnent au bon endroit.