Spring 3.1 : ce que nous réserve la prochaine version

Dans la panoplie des conférences Devoxx 2011, les équipes de SpringSource ont présenté les nouveautés et améliorations de la future version 3.1, et nous donnent même en avant-première les perspectives à venir !

Parmi les grandes nouveautés de Spring 3.1 présentées lors de la conférence Devoxx, j'en retiens deux. La première concerne les outils d'abstraction d'environnement à travers la définition de profils, et la seconde la possibilité de mettre en place simplement un système de cache.
Dans les outils d'abstraction d'environnement,
 l'idée est de pouvoir créer dynamiquement un contexte applicatif Spring spécifique à l'environnement de l'application. En effet, certains éléments du contexte diffèrent en fonction de l'endroit où se trouve physiquement l'application (sur le poste d'un développeur, sur la plate-forme d'intégration de test de montée en charge, sur une plate-forme de Cloud...). En fonction de l'environnement cible (dev, test, prod), ce seront des ressources différentes qui seront utilisées.

L'exemple pris lors de la démonstration concerne la problématique récurrente de définition de la base de données. Dans le cas du profil de développement, c'est une base embarquée en mémoire qui sera utilisée alors que pour le profil de production, ce sera une base Oracle.

Pour mettre en place cette abstraction d'environnement, Spring propose de définir des profils. Pour définir un profil, rien de plus simple : il suffit  de lui attribuer un nom.
  • Configuration par fichier XML avec l'attribut profile
     <beans profile="production">
<bean id="dataSource" class="...">
</beans>
<beans profile="dev,integ">
<bean id="dataSource" class="...">
</beans>
  • Configuration par annotation @Profile("production")

En fonction du profil activé au chargement de l'application, c'est seulement les éléments de configuration propres à ce profil qui seront utilisés : les autres seront purement et simplement ignorés. Il est même possible d'associer et de combiner les profils afin d'en avoir plusieurs actifs en même temps (à partir du moment où ils ne rentrent pas en conflit).

L'activation de profil(s) peut se faire de trois façons différentes :

  •  En renseignant un paramètre d'initialisation dans le fichier "web.xml"
    <param-name>spring.profiles.active</param-name>
    <param-value>production</param-value>
  • En valorisant par programmation la propriété activeProfiles sur l'environnement du contexte
    context.getEnvironment().setActivesProfile("production");
  • En passant l'information directement en ligne de commande en valorisant l'argument -Dspring.profiles.active   

La gestion de l'abstraction d'environnement proposée par Spring permet donc de réduire le nombre de fichiers de configuration et/ou propriétés (plus besoin d'avoir autant de fichiers que de profils).  Cela permet aussi de supprimer la substitution dynamique des variables de configuration (qu'il était possible d'effectuer en filtrant les ressources avec Maven).
Concernant la politique de définition de cache, là aussi, ce que propose Spring me semble intéressant. Il s'agit en fait d'un système générique de définition de cache complètement transparent. Le développeur indique quels éléments ou quels objets il souhaite mettre en cache. Le système de cache de Spring est complètement pluggable : vous pouvez brancher derrière votre gestionnaire de cache préféré : ehcache, concurrentMap...
Là aussi, des annotations intuitives : @Cacheable, @CacheEvict, @CachePut. La mise en cache ou le retrait peut également intégrer des conditions qu'il est possible de mettre directement en argument de l'annotation via une expression SpringEL du type (#montant > 2000).
La définition d'un système de cache applicatif est généralement considérée comme relativement complexe à mettre en œuvre par les développeurs. C'est une des raisons pour laquelle sa mise en place intervient généralement assez tardivement dans le développement d'une application. C'est lorsque des soucis de performance commencent à apparaître que l'équipe de développement se penche sur la question de l'ajout d'un gestionnaire de cache. Avec la prochaine version de Spring, plus d'excuses. Les annotations de cache peuvent être déjà réfléchies et posées sur les classes de l'application même si la définition concrète du gestionnaire de cache n'est pas encore faite.
Avec la version actuelle de Spring, la configuration par annotations avait déjà une place importante. Avec la version 3.1, la dynamique continue et s'intensifie encore ! A la question "Qui utilise encore les fichiers XML pour configurer son contexte applicatif, très peu de mains se sont levées dans la salle !". Il semble donc que les annotations aient un très bel avenir.
Au delà des nouvelles fonctionnalités de la version 3.1, la politique de Spring pour le futur est clairement de s'ouvrir toujours plus et de faciliter l'interaction avec les outils et autres frameworks en vogue (JSF 2.x, Bean Validation, JPA, Java EE7, JCache...). Mais patience, ce sera pour les prochaines versions...
Quant à la roadmap proche, Spring 3.1 sera proposé en Release Candidate 2 (RC2) la semaine prochaine. Plus que quelques jours à attendre !

Autour du même sujet