Mardi dernier, a eu lieu la soirée JSF 2.0 / Servlet 3.0 au Paris JUG. Comme à l'accoutumée désormais, la salle était comble, Antonio nous a même annoncé que toutes les places étaient prises 24h après l'annonce officielle ! Un conseil donc, si vous souhaitez participer à la prochaine soirée Paris JUG (soirée Google le 10 novembre), ne tardez pas une fois les inscriptions ouvertes !


JSF 2.0

La première partie de la soirée était consacrée à JSF 2.0. En réalité, derrière le titre JSF 2.0, cette présentation montrait les concepts généraux JSF d'une part, et les nouveautés JSF 2.0 d'autre part. On pourra regretter dans ce choix d'intégrer une présentation plus générale de JSF, le fait de voir les nouveautés JSF 2.0 noyées dans la masse et certaines nouveautés peu ou pas expliquées, faute de temps.
Voici les principales nouveautés de JSF 2.0 que j'ai retenu de cette présentation :

  • Possibilité de faire de la validation en utilisant la JSR 303 (Bean Validation) :
    Désormais, en positionnant le tag <f:validateBean> dans vos vues, JSF exécute la validation d'un bean donné en utilisant les annotations JSR 303 positionnées sur chaque attribut du bean. Par ailleurs, Emmanuel Bernard (spec lead de la JSR 303) est intervenu à la fin de cette présentation pour nous expliquer plus en détail l'intérêt de cette spécification : les contraintes de validation sont définies à un seul endroit, l'entité métier, et sont réutilisées par toutes les couches de l'application - présentation, métier, persistance - notamment de manière automatique par les frameworks comme JSF 2.0 ou encore Hibernate. Il nous a également indiqué que la JSR devrait très prochainement être finalisée.
     
  • Nouveau scope 'view' pour les managed beans :
    En plus des scopes classiques application, session et request, un nouveau scope fait son apparition : le scope view. Un bean de scope view sera maintenu par le conteneur tant que l'utilisateur ne change pas de page. Ce scope est donc pratique lorsque l'on souhaite faire plusieurs allers-retours client/serveur avec la même page, et que l'on souhaite conserver l'état de cette page entre chaque aller-retour.
     
  • Possibilité de déclarer des managed beans par annotation :
    Avant, la déclaration de managed-beans devait obligatoirement être faite dans le fichier faces-config.xml. Désormais, il sera possible de déclarer un managed bean par annotation en positionnant @ManagedBean sur le bean en question. Le scope du managed bean devra également être précisé (ex: @RequestScope pour un managed bean de scope request)
     
  • Développement de composants facilité avec EZComp :
    JSF 2.0 apporte la simplification du développement de composants avec EZComp. Avec EZComp, on déclare l'interface d'un composant, puis son implémentation pour un type de rendu donné, et on n'a plus qu'à importer le composant dans nos vues JSF.
    Interface :
    <composite:interface>
    <composite:attribute name="qui" required="true"/>
    </composite:interface>
    Implémentation :
    <composite:implementation>
    <span>Hello #{cc.attrs.qui}</span>
    </composite:implementation>
    Utilisation :
    <html xmlns:ez="http://java.sun.com/jsf/composite/hello">
    …
    <ez:hello qui="world" />
     
  • Gestion native d'AJAX :
    Avant JSF 2.0, pour faire de l'AJAX, il fallait passer par des librairies tierces comme RichFaces. JSF 2.0 fournit désormais le nécessaire out-of-the-box. Ainsi, avec la balise <f:ajax>, on peut facilement intégrer des comportements AJAX dans ses vues, comme la validation en temps réel d'un champ, et sans rechargement de page.
     
  • Templating : intégration de facelets dans JSF 2.0 :
    En JSF 1, il fallait faire appel à la librairie tierce facelets pour faire du templating, JSF 2.0 l'intègre désormais directement. Ainsi, pour faire du templating, il faut d'une part définir un template XHTML définissant le cadre commun de la page et la zone où est insérée le contenu spécifique de chaque vue. Puis dans chaque vue, il faut référencer le template utilisé, puis définir le contenu spécifique de la page.
     
  • Gestion avancée des ressources statiques :
    Il est désormais possible de positionner les ressources statiques soit dans /resources, soit dans /META-INF/resources au niveau des classes de l'application web, ou encore dans les JARs de l'application (de WEB-INF/lib). Cette nouveauté n'est pas sans rappeler celle de Servlet 3.0, comme on le verra plus loin. Au delà de ce mécanisme, il est également possible de versioner les ressources statiques, mais également de les internationaliser. Ainsi, pour une même image, on pourra avoir une version fr_monimage.gif et une autre en_monimage.gif. Ces ressources pourront alors être référencées dans les vues soit par tag, soit par EL.
     
  • Gestion de profils :
    Une nouveauté intéressante, car peu commune, la gestion de plusieurs profils d'utilisation : development, production et unitTest. Avec ces profils, on peut mettre du code ou du contenu conditionné par un profil d'utilisation. Ainsi, par exemple, on pourra en cas d'erreur, afficher la stacktrace dans la page en profil development, et afficher un joli message  d'erreur en profil production.
     
  • Accès aux vues par la méthode GET :
    Enfin, dernière nouveauté qui était fortement demandée par la communauté, les vues seront désormais accessibles par la méthode GET, et plus seulement par la méthode POST. Cela permettra notamment aux utilisateurs de pouvoir créer un favori sur une page donnée.

 

Servlet 3.0

La deuxième partie de soirée était consacrée aux nouveautés apportées par Servlet 3.0. Aux commandes de cette présentation, Rémy Maucherat, responsable de l'implémentation des APIs Servlet & JSP chez JBoss, et membre de l'expert group de la JSR 315 alias Servlet 3.0. Autant dire qu'il maitrisait son sujet !
Au milieu de toutes les nouveautés annoncées, nous avons appris que pas mal de modifications avaient été apportées à cette JSR la semaine dernière même, ce qui est assez surprenant étant donné que la finalisation de cette JSR est très proche.
Voici la liste des nouveautés que j'ai retenu :
  • Possibilité de définir les servlets, filters, listeners par annotation :
    On peut désormais définir une servlet uniquement en positionnant une annotation @WebServlet sur la servlet en question (avec les paramètres associés, notamment les urlPatterns auxquels elle répond). Il en est de même pour les filters et listeners. Ainsi, le fichier web.xml devient optionnel.
    Enfin, il est également possible au niveau d'une servlet, de définir les contraintes de sécurité associées par annotation.
     
  • Possibilité de définir les servlets, filters, listeners par web-fragments :
    Chaque JAR d'un framework donné présent dans WEB-INF/lib peut définir sa configuration XML spécifique dans un fichier META-INF/web-fragment.xml. Ainsi, il sera désormais possible d'ajouter un framework web donné par simple drag&drop du JAR dans WEB-INF/lib, plus besoin d'ajouter de la configuration dans web.xml. Par ailleurs, cette configuration par défaut d'un framework web donné est surchargeable dans le fichier web.xml. On pourra ainsi redéfinir uniquement un init-parameter du controller du framework, le conteneur web se chargera de faire la fusion des configurations.
    Enfin, il est possible de définir l'ordre de chargement des web-fragments, soit dans le fichier web-fragment.xml même (ordre relatif de chargement de ce fragment par rapport aux autres), soit dans le fichier web.xml (ordre absolu des web-fragments chargés).
     
  • Possibilité de définir les servlets, filters, listeners par programmation :
    Au moment du chargement de l'application, il est possible désormais d'ajouter par programmation des servlets, filters et listeners à partir du ServletContext, ce qui permettra des configurations dynamiques (par opposition à la configuration statique) et contextuelles (en fonction de paramétrage d'environnement par exemple). Un exemple d'utilisation qui me vient à l'esprit : les tests unitaires. On pourra ainsi imaginer l'ajout à chaud de la servlet de Cactus lorsqu'une system property est détectée au démarrage de l'application.
     
  • Possibilité de définir des ressources statiques dans un JAR :
    Dans certains cas, on souhaite ajouter dans notre application, un framework ou un outil de monitoring/administration qui a ses propres ressources statiques associées. Aujourd'hui, il faut manuellement ajouter ces ressources à nos ressources applicatives, ce qui est dommage. Pour répondre à cette problématique, il est désormais possible dans Servlet 3.0, d'inclure dans un JAR (de WEB-INF/lib) les ressources statiques associées dans le répertoire META-INF/resources. Ces ressources statiques seront accessibles depuis le web comme si elles étaient positionnées à la racine du WAR.
     
  • Possibilité d'initialiser les bibliothèques partagées :
    Au jour d'aujourd'hui, il y a un certain flou autour de l'initialisation des bibliothèques partagées par plusieurs applications au sein d'une instance de serveur d'applications. Désormais, il sera possible au niveau de la bibliothèque partagée d'avoir un initializer implémentant l'interface ServletContainerInitializer, ayant une méthode onStartup() appelée à l'initialisation de chaque application présente dans le serveur d'applications. Le servletContext de l'application en question sera passé en paramètre. Un usage intéressant que je vois pour cette fonctionnalité est pour les portails (au sens moteur de portlets). Un portail a souvent besoin de rajouter des servlets, des listeners ou des filtres spécifiques au sein des portlets qu'il manage, ce qui est dommage lorsque l'on souhaite avoir des portlets standard Portlet 1.0 ou 2.0. Grâce à ce mécanisme, plus celui permettant de définir des servlets/filters/listeners programmatiquement, le portail pourra rajouter à chaud au démarrage du serveur,ses composants spécifiques au niveau de chaque portlet. Ainsi le web.xml de chaque portlet restera standard Portlet 1.0 ou 2.0.
     
  • Possibilité d'exécution asynchrone des servlets :
    Probablement la plus grosse fonctionnalité : la gestion d'exécution asynchrone des servlets. Cette fonction permet de répondre à deux problématiques :
    • le mécanisme de push dans les applications de chat ou les jeux en ligne
    • dans les applications très haute charge, la possibilité de libérer un thread du pool de threads du serveur d'applications pendant le temps où on attend des retours asynchrones du BackOffice du SI, pour les agréger ensuite dans la réponse web.
    Ce mécanisme est très puissant, mais apporte également son lot de complexité. A utiliser donc uniquement si on en a vraiment besoin.
     
  • Gestion des formulaires multi-parties (upload de fichiers) :
    Récupérer côté serveur (simplement) les fichiers envoyés par un client via un formulaire était un manque important, qui avait jusqu'alors été comblé par la librairie Apache Commons FileUpload, largement utilisée. Servlet 3.0 reprend quasiment à l'identique les fonctionnalités permises par cette librairie.
     
  • Possibilité de contrôler le processus d'authentication par le conteneur :
    Un constat est le fait que les mécanismes d'authentification par le conteneur sont peu utilisés car peu flexibles, peu contrôlables. Partant de ce constat, de nouvelles méthodes ont été ajoutées dans l'interface ServletRequest afin de permettre aux développeurs de contrôler le mécanisme d'authentification du conteneur :
    • authenticate(response) : lance le mécanisme d'authentification défini du conteneur 
    • login (username, password) : lance le mécanisme d'authentification du conteneur à partir des identifiants passés en paramètre (nouveau type d'authentification : LOGIN)
    • logout() : permet de forcer la déconnexion de l'utilisateur en supprimant le principal de la session
       
  • Possibilité de personnalisation de la gestion des sessions :
    Désormais, dans la balise <session-config> du fichier web.xml, il est possible de personnaliser la gestion des sessions :
    • possibilité de modifier le nom du cookie de session (par défaut JSESSIONID)
    • possibilité de choisir le mécanisme de récupération de l'id de session : URL, COOKIE, SSL
    • possibilité de redéfinir la portée du cookie de session (par défaut : locale au contexte web de l'application). Cela permet notamment d'activer le partage de sessions entre plusieurs applications au sein d'un même serveur d'applications. Cela sera particulièrement utile pour les portails (encore une fois), pour permettre d'avoir une session commune entre toutes les portlets.
     

Conclusion

En conclusion, beaucoup de nouveautés pour ces deux versions majeures d'APIs, intégrant la spécification Java EE 6. Côté JSF 2.0, on appréciera le fait que Sun ait écouté la communauté (support natif d'AJAX, support de la méthode GET), et le fait d'avoir intégré certains frameworks existants et ayant fait leurs preuves comme Facelets. Mais pour moi, le plus impressionnant est côté Servlet 3.0 : on avait pas vu pareils changements depuis au moins Servlet 2.3 (avec l'arrivée des listeners et filters), et cela fait plaisir à voir. Pour moi, les maîtres mots sont flexibilité (avec quatre moyens de définir des servlets, filters et listeners) et puissance (notamment avec la nouvelle fonctionnalité d'exécution asynchrone des servlets).
Bien sûr, tout le monde ne tirera pas forcément partie de ces nouveautés et continuera à utiliser l'API Servlet comme au bon vieux temps. Mais, je pense que tout cela apportera de nouveaux frameworks, de nouveaux outils qui tireront profit au maximum des nouveautés de Servlet 3.0, et pourquoi pas, apporteront de nouveaux usages...



Références

Slides JSF 2.0
Slides Servlet 3.0