SpringMVC 4, Rest & Test avec JSON Date Conversions (Jackson2)

springRest_logojackson2-logo-onlyjson

Le titre est déjà tout un programme ! L’objectif est d’illustrer avec plusieurs exemples les nouveautés Rest API dans Spring MVC 4 et en particulier sur le support Jackson2 dans Spring4.

Nous allons voir de quelle manière nous pouvons ignorer certains attributs de classe, puis comment filtrer certains champs dans les conversions/sérialisations Json (ou encore Xml). Les conversions (sérialisation et désérialisation) des dates seront également traitées.

Spring web MVC : Doit-on déclarer un ContextLoaderListener?

Spring_Framework

L’objectif de ce billet est tout simplement de répondre à la question indiquée dans son titre:

Doit-on déclarer, dans une application web, un ContextLoaderListener?

Ou encore, n’est-il pas suffisant de configurer uniquement la « ServletDispatcher » dans web.xml?

Pour répondre rapidement à ces deux questions je dirais:

Pour la première question: Non, mais…!
Et pour la seconde question: Oui, mais…!

Gestion globale des exceptions dans spring mvc (global exception handling in spring mvc)-Part 1

Spring_FrameworkSpringMVC

L’objet de ce billet est double :

– Meilleure gestion des exceptions/erreurs dans une application web mvc en affichant une page appropriée et un message explicite,
– Privilégier une gestion globale et transverse à toute l’appli web (tous les controlleurs) de spring mvc.

Ce dernier point nécessite d’être précisé, c’est ce que nous allons faire ci-après.

Gestion des contenus : Java Content Repository (JCR 2.0) & Spring (Part 1)

La gestion de contenus ( formulaires, documentation, procédures) est généralement désigné par le terme GED (Gestion électronique de documents) comme synonyme d’ECM (Enterprise Content Management).

JCR 2.0 est la dernière version de l’API d’entrepôt documentaire standard appelée aussi JSR 283 (anciennement appelée JSR 170).

jackrabbit est l’implémentation open source de référence utilisée par de nombreux projets (Par ex. Alfresco). La version 2.9.0, release sortie en aout 2014, est utilisée dans la démo ci-après.

La solution Jackrabbit de la fondationapacheFondation est lancée, en 2005, par l’ancienne équipe technique d’ECM Documentum (la solution propriétaire riche dans ce domaine).

La figure ci-dessous résume l’architecture de Jackrabbit répartie essentiellement en trois couches :

jcr_jackrabbit_overview

 

Dans ce billet, nous avons préféré éviter les détails de l’API JCR pour aborder le cœur du sujet, c’est à dire, montrer comment afficher/créer un nœud. En d’autres termes illustrer les opérations CRUD par la pratique.

Nombreux sont les articles qui expliquent comment configurer JCR avec spring-modules mais très peu abordent JCR 2.0 sans spring-module ni spring-extensions. C’est bien ce qu’on va réaliser.

SpringMVC et la JSR303 (validation)

Suite au billet SpringMVC pour les nuls, nous poursuivons avec l’ajout de la validation à base de la JSR303.

La JSR303 ou Bean Validation offre une API standard qui permet de valider un objet Java et de générer la liste des violations des contraintes non observées.

La gestion de la validation est indépendante de la nature de l’application.

Mais ici la démonstration est produite dans le cadre d’une application web avec SpringMVC.

En effet, dans cette démo, on configure Spring, on ajoute quelques annotations sur les propriétés (les champs), une annotation sur l’objet dans le controller et c’est tout.

Plus précisément, en cinq actes nous allons mettre en place la validation dans notre application web sans écrire du code.

Il est préférable de partir du projet de la seconde partie du billet déjà mentionné.

Il faudrait donc le compléter en suivant les cinq actes ci-après.

SpringMVC v3 pour les nuls avec une démo détaillée

L’objectif est de montrer avec détail comment prendre en main le framework SpringMVC v3.

Cet article s’adresse aux nuls avec comme seul pré-requis de connaître (un peu) le framework Spring.

SpringMVC, dans sa dernière version, offre d’énormes simplifications si on sait l’exploiter.

Il apporte une réponse élégante pour bon nombre de problématiques réelles.

Le projet web démo est basé sur maven3 et java 5+ et toujours avec « full annotations ».

Il commence par créer le projet Maven à partir d’une template.

Le pom.xml est configuré pour utiliser tomcat ou jetty embarqués.

Dans la première partie, une classe ‘Controller’ de traitement et une page jsp sont écrites afin d’afficher le fameux ‘Hello World’.

Dans la seconde partie, la fonctionnalité standard de création d’une entité métier est rajoutée.

Pour cela, on écrit un ‘Controller’ qui affiche le formulaire de saisie et un autre qui gère les données saisies et soumises.

Passons à la mise en pratique.

Débuter avec Spring MVC 3.0. Partie 1 : Configuration

Plusieurs Frameworks tels Struts ou Click proposent d’offrir aux développeurs une meilleure structuration de la partie présentation de leurs applications J2E. Basé sur le patron de conception MVC 2 (un contrôleur façade unique, utilisation d’un modèle pour la sélection et la construction de la vue), Spring MVC offre une alternative intéressante en profitant à la fois des avantages d’un conteneur léger, d’une grande flexibilité permettant entre autres de séparer logiquement les composants et changer plus facilement de technologies coté client sans impacter les contrôleur. Mais surtout, à partir de la version 2.5, Spring MVC utilise les annotations Java 5, ce qui simplifie l’utilisation des contrôleurs, facilite les tests unitaires et permet de masquer l’utilisation de l’API servlet.

Cette série d’articles, s’adressant à un débutant en Spring ayant déjà une expérience avec les technologies WEB de présentation (comme WebWork, JSP, JSF, Struts3, …) sachant configurer une application web,  sera présentée sous forme de brefs tutoriels afin de passer en revue les principaux comportements de Spring MVC sans entrer dans les détails complexes. Pour des explications plus poussées vous pouvez vous référer à l’excellent ouvrage « Spring Par La Pratique » (2e Édition) aux éditions Eyrolles et à la documentation officielle de Spring à savoir :

Web Spring MVC Framework
Spring MVC API

Dans le présent article il s’agira de mettre en place l’environnement permettant d’exécuter des tests et d’effectuer l’affichage d’une simple page d’accueil.

Pour suivre ce tutoriel je préconise l’utilisation d’un JDK 1.5 (ou plus), un tomcat 5.5 (ou plus), et un Eclipse 3.2.0 (ou plus).

Les bibliothèques utilisées pour les premiers tutoriels et à ajouter (au pom.xml ou directement sous forme de JAR dans le dossier WEB-INF/lib) du projet web sont :
aopalliance-1.0
commons-logging-1.1.1
servlet-api-2.4
spring-beans-3.0.4
spring-context-3.0.4
spring-context-support-3.0.4
spring-core-3.0.4
spring-web-3.0.4
spring-webmvc-3.0.4


Voici le cycle de vie des processus de Demande de Spring 3.0 MVC:

  • Le client envoie une requête Http au conteneur Web.
  • Cette requête entrante est interceptée par le DispatcherServlet (contrôleur frontal) qui tente alors de faire le mapping. En fonction des règles définies, le DispatcherServlet envois la requête au contrôleur approprié.
  • Le contrôleur traite la demande et retourne le modèle et la vue (sous forme d’une d’instance d’objet ModelAndView) au contrôleur frontal.
  • Le contrôleur résout finalement la vue, dans notre cas une page JSP (on pourrait aussi bien utiliser Velocity ou Freemarker) en consultant l’objet View Resolver (configurable depuis la servlet).
  • La vue sélectionnée est enfin rendu envoyé au client.

Configurer le contrôleur frontal (web.xml) :

Le contrôleur de façade se configure depuis le fichier web.xml, le point d’entrée est une servlet DispatcherServlet (qui implémente une HttpServlet classique). Dans ce tutoriel la configuration adoptée est la suivante :

<?xml version=« 1.0 » encoding=« UTF-8 »?>

<web-app xmlns:xsi=« http://www.w3.org/2001/XMLSchema-instance »
xmlns
=« http://java.sun.com/xml/ns/javaee » xmlns:web=« http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd »
xsi:schemaLocation
=« http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd »
id
=« WebApp_ID » version=« 2.5 »>

<display-name>SpringMVC</display-name>

<welcome-file-list>
<
welcome-file>index.html</welcome-file>
</
welcome-file-list>

<servlet>
<
servlet-name>SpringMVC</servlet-name>
<
servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
<
load-on-startup>1</load-on-startup>
</
servlet>

<!– Spring Mapping –>

<servlet-mapping> <!– index page mapping –>
<
servlet-name>SpringMVC</servlet-name>
<
url-pattern>/index.html</url-pattern>
</
servlet-mapping>

<servlet-mapping> <!– default mapping –>
<
servlet-name>SpringMVC</servlet-name>
<
url-pattern>/</url-pattern>
</
servlet-mapping>

<servlet-mapping> <!– html mapping –>
<
servlet-name>SpringMVC</servlet-name>
<
url-pattern>*.html</url-pattern>
</
servlet-mapping>

</web-app>
Les balises <servlet-mapping> définissent des patterns pour que le DispatcherServlet puisse mapper les adresses url (ici l’index, la racine et toutes les adresses finissants par .html) vers le bon contrôleur frontal.

On retrouve aussi notre servlet DispatcherServlet dont le contenu de la balise <servlet-name> sera utilisé comme préfixe pour rechercher un fichier de configuration [servlet-name]-servlet.xml (ici SpringMVC-servlet.xml) à placer dans le répertoire WEB-INF du projet, ce fichier permet de configurer les beans du contrôleur.


Configuration du fichier SpringMVC-servlet.xml :

<?xml version=« 1.0 » encoding=« UTF-8 »?>

<beans xmlns:context=« http://www.springframework.org/schema/context »
xmlns
=« http://www.springframework.org/schema/beans » xmlns:xsi=« http://www.w3.org/2001/XMLSchema-instance »
xmlns:util
=« http://www.springframework.org/schema/util » xmlns:p=« http://www.springframework.org/schema/p »
xmlns:mvc
=« http://www.springframework.org/schema/mvc »
xsi:schemaLocation
=« http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-2.5.xsd
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
http://www.springframework.org/schema/util http://www.springframework.org/schema/util/spring-util-2.5.xsd

http://www.springframework.org/schema/mvc http://www.springframework.org/schema/mvc/spring-mvc-3.0.xsd
« >

<!– Using annotations –>

<context:annotation-config />
<
context:component-scan base-package=« com.ideo.springmvc.web » />
<
bean class=« org.springframework.web.servlet.mvc.annotation.DefaultAnnotationHandlerMapping » />
<
bean class=« org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter » />
<
mvc:annotation-driven />

<!– Naming View Configuration –>

<bean id=« viewResolver1 »
class
=« org.springframework.web.servlet.view.InternalResourceViewResolver »
p:prefix
=« /jsp/ » p:suffix=« .jsp » /> <!– Prefix and suffix of the jsp models –>

<bean id=« viewResolver2 »
class
=« org.springframework.web.servlet.view.InternalResourceViewResolver »
p:prefix
=« / » p:suffix=« .jsp » />

</beans>

Après déclaration des schémas xsld, il faut définir les contextes et initialiser le contexte de l’application, voici quelques explications :

<context:annotation-config> :  Utilisation des annotations pour l’injection de dépendances (indépendante des annotations de bean).

<context:component-scan> :  Les paquetages (et implicitement récursivement les sous-packages) à parcourir et dans lesquels se trouvent les composants Spring MVC annotés

<mvc:annotation-driven> :  Avec les beans DefaultAnnotationHandlerMapping et AnnotationMethodHandlerAdapter ceci permet entre autre l’utilisation des annotations Spring 3.0 (de gérer des validateurs sur des formats comme les dates, etc…). Pour plus d’informations à ce sujet, se référer à la section 15.12 Configure Spring MVC de la documentation officielle.

Enfin les ViewResolver permettent d’indiquer des règles à appliquer par les contrôleurs afin de résoudre les vues,  par exemple le bean viewResolver1 de compléter la recherche des pages jsp coté serveur en ajoutant un préfixe /jsp/ et un suffixe .jsp (ceci n’étant bien sur pas visible coté client et permettant juste de simplifier le code à écrire dans les contrôleurs).

Le contrôleur de la page d’index (IndexController.java) :

Afin de tester la bonne configuration de l’environnement, créer un fichier IndexController.java dans le package com.ideo.springmvc.web.controller contenant le code suivant :

package com.ideo.springmvc.web.controller;
import
org.springframework.stereotype.Controller;
import
org.springframework.web.bind.annotation.RequestMapping;
import
org.apache.commons.logging.Log;
import
org.apache.commons.logging.LogFactory;

@Controller
public
class IndexController {

protected final Log logger = LogFactory.getLog(getClass());

@RequestMapping(« index »)
public
String showIndex () {
logger
.info(« Return Index View »);
return
« index »;

}

}

Le comportement des contrôleurs sera expliqué dans le prochain article..

La page d’index (index.jsp) :

Créer un fichier index.jsp dans le répertoire /webapp/jsp/, ce fichier contient le code suivant

<%@ page language=« java » contentType=« text/html; charset=UTF-8 » pageEncoding=« UTF-8 »%>
<!
DOCTYPE html PUBLIC « -//W3C//DTD HTML 4.01 Transitional//EN » « http://www.w3.org/TR/html4/loose.dtd »>

<html>

<head>
<
title>Index</title>
</
head>

<body>
<
h1>Spring MVC Index</h1>
</
body>

</html>

Lancer ensuite le serveur d’application comme pour n’importe quelle webapp et tester, le texte « Spring MVC Index » devrait s’afficher dans votre navigateur.

A suivre…

RESTer simple avec Spring et JAXB – Partie 2 : serveur REST avec Spring web

Ce billet fait suite au sujet portant sur le « Binding avec JAXB ».
Après avoir réaliser le binding du modèle métier grâce aux annotations JAXB, la partie serveur de l’application peut être réalisée.
La façon la plus simple de réaliser une communication entre applications est de passer par des standards.
Le style d’architecte REST (Representational State Transfer) utilise des standards qui ont fait la renommée du web :

  • HTTP comme protocole de communication,
  • URI comme syntaxe d’adressage des ressources,
  • XML, Json… comme syntaxe pour la représentation des données.

Framework de validation de Spring 2.5+ avec annotations Java 5 [1ère partie : Durée 20min]

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.