Le conteneur Spring

Les origines

Nous allons aborder les principaux composants de Spring.

Spring est un framework qui simplifie la programmation. Il est composé d’un cœur, Spring Core, qui permet une gestion simple des instances de classe en mémoire et de bibliothèques de classes qui utilisent ce cœur.

Celles-ci s’appellent des beans Spring. Le framework fournit un ensemble de beans préprogrammés qui couvrent un très large spectre de cas d’utilisation que l’on rencontre quand nous codons une application complexe.

Ils sont extensibles et faciles à utiliser.

Le cœur du framework permet de charger au démarrage un ensemble de singletons et facilite ensuite leur accès en injectant automatiquement leur référence (emplacement mémoire) dans les objets qui les utilisent.

Spring permet d’avoir un contrôle très fin sur la gestion des objets en mémoire.

Spring s’interface avec énormément de frameworks et de produits. Le principal intérêt de Spring est l’instanciation et la mise à disposition automatisée de beans. Ces objets peuvent être de deux types : des singletons, comme nous l’avons déjà évoqué, mais aussi des objets « dupliqués » nommés « prototypes ».

Contrairement à l’objet...

Les modules fondamentaux

Les beans spécialisés présentés ci-après sont généralement présents depuis la version 0.9 de Spring et ont reçu des améliorations au fil des versions. Ils sont surtout utilisés quand nous souhaitons étendre Spring. Vous les verrez surtout dans les frameworks. Quand nous utilisons les annotations nous ne voyons plus ces objets, mais ils sont utilisés en interne dans Spring.

Configuration des beans

Comme nous l’avons évoqué, la configuration des beans Spring peut être implicite ou explicite. En mode implicite, Spring reconnaît de lui-même les classes Java à ajouter à la liste des beans à partir d’un balisage sur les candidats. En mode explicite, nous indiquons à Spring le nom et l’emplacement exact des beans. Le mode explicite est plus sécurisé mais il est plus long à configurer. C’est pourquoi il est rarement utilisé. Les beans sont configurables par l’utilisation de fichiers XML, d’annotations ou directement en Java.

Possibilité de déclaration des beans

Nous pouvons donc par ce biais déclarer un arbre d’objets contenant des objets singletons et des objets prototypes. Nous verrons qu’il est aussi possible d’avoir une configuration différente pour le « run » et pour les test en ayant par exemple une configuration dédiée.

La configuration par XML présente des difficultés liées à l’utilisation de configuration au format texte. Spring doit en effet faire des conversions du texte vers le type cible. Pour indiquer un nombre, nous le mettrons dans une chaîne, qui est ensuite convertie. Pour indiquer le nom d’une variable ou d’un paramètre, nous utilisons aussi du texte. Les problèmes ne se voient alors qu’à l’exécution alors qu’en configurant en Java, les problèmes se révèlent directement lors de la phase de compilation.

Nous utiliserons donc en priorité la configuration Java. Les exemples montrent tous les types de configuration afin de les présenter.

Utilisation des beans : injection par setters et constructeurs

Le bean devient disponible pour l’application une fois que le bean est déclaré dans la configuration. Nous pouvons alors l’injecter comme membre de notre classe.

Spring ne peut injecter des dépendances que dans un bean Spring.

Le premier bean de notre application sera donc obligatoirement instancié par une factory Spring qui chargera le contexte et appliquera la configuration à ce bean. C’est le point de démarrage de Spring dans l’application.

Spring crée l’objet avec le constructeur par défaut et appelle ensuite les setters pour injecter les références des objets à injecter. Si le constructeur par défaut n’est pas disponible, Spring utilise alors un constructeur avec des arguments, ce qui permet aussi de renseigner les dépendances. Cette possibilité est utilisée pour les API externes à Spring qui ne disposent pas de constructeurs par défaut comme les pools de connexions pour lesquels nous devons passer la datasource en paramètre de constructeur.

Un constructeur qui contient en paramètre des beans permet de faire l’équivalent de l’annotation @Autowired sur des membres du bean. Il faut par contre avoir un nombre limité d’arguments dans le constructeur pour garder de la lisibilité. 

L’annotation @Autowired est mise sur la variable ou préférentiellement sur le setter de la variable. Il est possible de spécifier que la résolution peut être différée au démarrage via le paramètre required=false :

@Autowired(required=false) 

Ceci permet de préciser à Spring que le bean à mapper peut ne pas être disponible au démarrage. Par exemple, si un bean a besoin lors de son instanciation (chargement en mémoire), d’un élément qui n’est pas disponible au démarrage, il est possible de différer son instanciation au moment de sa première utilisation. Un bean peut par exemple avoir besoin...

Contrôle du cycle de vie : construction et destruction

Spring permet d’intercepter la création et la description des objets Spring.

Il n’est pas possible d’utiliser les beans injectés directement dans le constructeur car à ce moment précis, Spring n’a pas encore instancié les objets contenus dans les membres de la classe. De même, l’appel à la méthode finally n’est pas simple car elle est appelée par le garbage collector et le finally est deprecated (JEP 421). Spring donne la possibilité de marquer des méthodes pour qu’elles soient appelées à la création et à la destruction de l’objet. Il existe plusieurs mécanismes.

Voici le plus récent.

Il est aussi possible d’utiliser les aspects de la programmation orientée aspect (AOP) pour effectuer des actions lors de la création et la destruction de l’objet.

Nous utilisions avant ces annotations des méthodes paramétrées dans la configuration avec les paramètres init-method et destroy-method comme dans l’exemple suivant :

<bean id="helloWorld" 
   class="com.tutorialspoint.HelloWorld"  
   init-method="init"...

Exemple illustrant les mappings standards

Cet exemple décrit, pas à pas, la création d’un projet simple. Il est présent dans les exemples téléchargeables depuis la page Informations générales. Ce chapitre peut paraître un peu complexe aux débutants de prime abord, mais pourra être réutilisé pour expérimenter.

mvn archetype:generate -DgroupId=fr.eni.editions  
-DartifactId=mappingApp -DarchetypeArtifactId=maven-archetype-quickstart 
-DinteractiveMode=false 

<?xml version="1.0" encoding="UTF-8"?> 
<beans default-lazy-init="true"  
xmlns="http://www.springframework.org/schema/beans"  
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  
xmlns:context="http://www.springframework.org/schema/context"  
xmlns:jdbc="http://www.springframework.org/schema/jdbc" 
   xsi:schemaLocation=" 
     http://www.springframework.org/schema/beans  
http://www.springframework.org/schema/beans/spring-beans-4.1.xsd 
     http://www.springframework.org/schema/jdbc  
http://www.springframework.org/schema/jdbc/spring-jdbc-4.1.xsd 
     http://www.springframework.org/schema/context...

Le Spring Expression Language

C’est un langage d’expression très utilisé qui permet de variabiliser un paramètre qui serait fixe dans une chaîne, ce qui est plus particulièrement utile avec les paramètres des annotations.

Sa syntaxe est similaire à Jakarta Expression Langage (Unified EL) mais il offre des possibilités supplémentaires comme l’invocation de méthode sur un bean ou sur un objet hors Spring.

Il est possible d’utiliser SpEL de façon autonome via l’utilisation de quelques classes d’infrastructures d’amorçage telles que l’analyseur, mais en général l’utilisation est transparente quand nous codons avec Spring. Le SpEL est très proche des spécifications JavaBeans.

ExpressionParser parser = new SpelExpressionParser (); 
Expression exp = parser.parseExpression ( "'Bonjour à'.concat 
(' vous !')"); 
String message = (String) exp.getValue (); 

Serveurs J2EE, Java EE et Jakarta EE