Introduction au framework Spring

L'idée du pattern IoC est très simple, elle consiste, lorsqu'un objet A a besoin d'un objet B, à déléguer à un objet C la mise en relation de A avec B. Bon, OK, cela ressemble à une vieille équation d'algèbre incompréhensible alors un petit exemple de code vaut mieux qu'une formule fumeuse.

Prenons l'exemple d'un code classique où une classe a besoin de sa fabrique pour gérer les accès à la base de données. Le code suivant est assez classique, sachant qu'un effort a déjà été fait pour centraliser la création des différentes fabriques au sein d'une fabrique générale.

Product
package product;
 
import factory.DAOFactory;
import product.dao.ProductDAO;
 
public class Product{
 
        private ProductDAO dao;
 
        private long id;
        private String name;
        private String description;
 
        public Product(){
                dao = (ProductDAO)DAOFactory.getFactory("ProductDAO");
        }
 
        public String getName(){return name;}
 
        //etc
}

DAOFactory
package factory;
 
import product.dao.ProductDAOImpl;
import product.dao.ClientDAOImpl;
import product.dao.CommandDAOImpl;
 
import java.util.*;
 
public class DAOFactory{
 
        private Hashtable factories;
        private static DAOFactory self = null;
 
        protected DAOFactory(){
                factories = new Hashtable();
                factories.put("ProductDAO", new ProductDAOImpl());
                factories.put("ClientDAO", new ClientDAOImpl());
                factories.put("CommandDAO", new CommandDAOImpl());
        }
 
        public static Object getFactory(String factoryName) throws NullPointerException {
                return DAOFactory.self().get(factoryName);
        }
 
        protected Object get(String factoryName) throws NullPointerException {
                return factories.get(factoryName);
        }
 
        public static synchronized DAOFactory self(){
                if(self == null){
                        self = new DAOFactory();
                }
                return self;
        }
}

Quels constats simples peut-on faire sur cette conception ?

• Le code dépend d'un appel à la classe DAOFactory.
• Les implémentations des différents DAO sont déclarées en dur dans la classe DAOFactory.

Mais alors, quels problèmes cela pose-t-il ?

• Pb1 - Comment faire du test quand les classes implémentant les DAO ne sont pas encore développées ?
• Pb2 - Comment faire pour que l'application puisse fonctionner avec des classes DAO différentes dans différents contextes (contexte serveur centralisé, contexte distribué, contexte « phase de test », contexte « production ») ?

Solution au problème 1

La solution est ici de modifier le code de la classe DAOFactory, OK. Mais comment faire pour partager ce code modifié alors que plusieurs développeurs n'ont pas les mêmes exigences en termes de création de fabriques ?

Peut-on aussi accepter d'être obligé de modifier du code qui marche lors du passage à différentes phases de test ?

Solution au problème 2

Le cas présenté est simple, mais imaginez que certaines classes DAO soient des classes distribuées, déployées au sein d'un serveur d'applications. La création de ces classes devrait se faire via une requête JNDI. OK, on peut donc modifier le code de la classe DAOFactory pour ces classes en particulier. Mais alors, comment faire du test lorsque ces classes ne sont pas encore développées ? Et d'une manière générale, ne peut-on pas trouver plus simple et moins consommateur en temps de réaliser des tests hors contexte d'un serveur d'applications et donc remplacer, lors des tests, les classes XXXDAOImpl par des classes Java classiques (des « mocked » objets, les bouchons en français dans le texte) ?

Avec SPRING, tous ces problèmes sont externalisés et gérés par le framework. Il suffit donc d'écrire le code suivant :

Product
package product;
 
import factory.DAOFactory;
import product.dao.ProductDAO;
 
public class Product{
 
        private ProductDAO dao;
 
        private long id;
        private String name;
        private String description;
 
        public void setProductDAO(ProductDAO dao){
                this.dao = dao;
        }
 
        public String getName(){return name;}
 
        //etc
}

On voit ici que notre classe Product ne dépend d'aucune fabrique et qu'elle ne fait que déclarer un « setter » pour sa propriété « dao ».

Le framework SPRING, via le fichier de configuration suivant, prend en charge la mise en relation des différents objets :

<beans>
        <bean id="productDAO" class="product.dao.ProductDAOImpl"></bean>
        <bean class="product.Product">
                <property name="productDAO">
                        <ref bean="productDAO"/>
                </property>
        </bean>
</beans>

Pour répondre aux problèmes soulevés précédemment, il suffit de gérer des fichiers de configuration spécifiques pour les tests et un fichier de configuration spécifique pour la mise en production de l'application (chacun déclarant des XXXDAOImpl adaptés au contexte).

Que les objets soient créés par un simple « new » ou via une recherche dans un annuaire JNDI, ce qui peut être le cas pour des composants EJB, n'a aucun impact sur le code applicatif.

Vous le comprendrez mieux après avoir lu le chapitre sur les EJB, mais avec SPRING, il est possible de créer un code applicatif qui ne manipule que des classes Java classiques (ce que l'on appelle des POJO : Plain Old Java Objects) sans être obligé de maîtriser tous les aspects techniques des technologies que vous mettez en œuvre ; SPRING se charge de la « clue » technique.

Nous en avons parlé très brièvement dans le chapitre précédent, un utilisateur classique3 de SPRING va utiliser un fichier de configuration XML pour décrire les différents objets devant être gérés par le conteneur de SPRING.

Avec SPRING, on va gérer des JavaBeans ou Beans, cela n'a rien de vraiment contraignant, le terme JavaBeans est juste utilisé par SPRING, car SPRING utilise les « setters » pour mettre des objets en relation. Vos objets sont donc des JavaBeans !

Ceci étant dit, on va donc déclarer des « BeanFactory », des fabriques de JavaBean, dans le fichier de configuration pour expliquer à SPRING que l'on a un certain nombre d'objets à créer au cours de notre application.

<beans>
        <!-- Première fabrique-->
        <bean id="productDAO" class="product.dao.ProductDAOImpl"></bean>
        <!-- Seconde fabrique-->
        <bean class="product.Product">
                <property name="productDAO">
                        <ref bean="productDAO"/>
                </property>
        </bean>
</beans>

Les « property » dans un bean servent donc à déclarer les relations de dépendance entre beans. Dans notre exemple, on déclare donc que les objets de type « Product » ont besoin d'un objet référencé dans le fichier de configuration sous le nom « productDAO ». Lors de la création d'un « Product », SPRING affecte automatiquement sa propriété « productDAO » en utilisant la méthode setProductDAO et en lui passant, ici, un objet de type ProductDAOImpl.

III-A-1. Cycle de vie d'un Bean▲

        <bean class="product.Product" singleton="false">
                <property name="productDAO">
                        <ref bean="productDAO"/>
                </property>
        </bean>

« springfactory ».getBean(«product») ;

III-A-2. Déclaration des propriétés▲

<bean id="myDataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
        <property name="driverClassName">
                <value>com.mysql.jdbc.Driver</value>
        </property>
        <property name="url">
                <value>jdbc:mysql://localhost/spring</value>
        </property>
        <property name="username">
                <value>sample</value>
        </property>
        <property name="password">
                <value>sample</value>
        </property>
</bean>
<bean id="mySessionFactory" class="org.springframework.orm.hibernate.LocalSessionFactoryBean">
        <property name="mappingRessources">
                <list>
                        <value>sample.hbm.xml</value>
                </list>
        </property>
</bean>

L'accès et la lecture du fichier de configuration correspondent à l'initialisation du « container » SPRING. En fonction du contexte d'utilisation de SPRING, plusieurs moyens sont mis à votre disposition pour charger le fichier de configuration de vos beans et ainsi initialiser vos singletons (vous vous souvenez bien sûr de nos fameux singletons initialisés dès le chargement du framework !).

III-B-1. Cas d'une application type client « Swing »▲

ClassPathResource res = new ClassPathResource("applicationContext.xml");
 
// Notre fabrique SPRING permettant l'accès aux beans déclarés
 
XmlBeanFactory factory = new XmlBeanFactory(res);

III-B-2. Cas d'une application web (war)▲

<context-param>
        <param-name>contextConfigLocation</param-name>
        <param-value>/WEB-INF/daoContext.xml /WEB-INF/applicationContext.xml</param-value>
</context-param>
 
<listener>
        <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>
 
<!-- Ou utilisation de la servlet ContextLoaderServlet-->
<servlet>
        <servlet-name>context</servlet-name>
        <servlet-class>org.springframework.web.context.ContextLoaderServlet</servlet-class>
        <load-on-startup>1</load-on-startup>
</servlet>

III-B-3. Cas d'un EJB (« ejbjar »)▲

public class MyComponentEJB extends AbstractStatelessSessionBean implements IMycomponent{
 
}

public void setSessionContext(SessionContext sessionContext){
        super.setSessionContext(sessionContext);
        setBeanFactoryLocator(ContextSingletonBeanFactoryLocator.getInstance());
}

Comme nous l'avons présenté précédemment, les beans déclarés « singleton » sont créés dès le chargement du fichier de configuration. Ensuite, votre besoin peut être de récupérer un premier bean, comme on crée un premier objet dans un programme principal Java classique.

Pour cela, SPRING offre une API permettant de manipuler le fichier de configuration et en particulier de récupérer un objet, singleton ou prototype. Dans le cas de la récupération d'un singleton, SPRING retourne toujours la même instance, celle créée au départ et dans le cas d'un prototype, SPRING se charge du « new » de la nouvelle instance que vous demandez et se charge bien sûr de mettre cette nouvelle instance en relation avec les autres objets dont elle a besoin via le bon vieux principe de l'inversion de contrôle gérée par SPRING.

ClassPathResource res = new ClassPathResource("applicationContext.xml");
// La fabrique SPRING est chargée, les singletons sont créés
XmlBeanFactory factory = new XmlBeanFactory(res);
 
// On utilise la méthode getBean en passant le nom du bean pour créer
// ou récupérer un bean déclaré dans le fichier de configuration
IVehiculeServices vservices = (IVehiculeServices)factory.getbean("myVehiculeServices");

Si vous avez bien lu le fichier de configuration précédent, vous aurez constaté la définition d'une propriété « transactionManager ».

Cette propriété permet à notre « TransactionInterceptor » de savoir quel objet gère effectivement les transactions. SPRING offre plusieurs gestionnaires de transaction adaptés en fonction des besoins et donc du contexte d'utilisation de SPRING :

• vous utilisez simplement SPRING avec un driver JDBC et un gestionnaire de DataSource comme celui offert par jakarta-commons, utilisez DataSourceTransactionManager ;
• vous utilisez SPRING avec le framework de persistance Hibernate, utilisez HibernateTransactionManager ;
• vous utilisez SPRING dans le contexte d'un serveur d'applications J2EE et/ou vous utilisez JTA, utilisez JtaTransactionManager.

Exemple avec Hibernate et MySQL

<bean id="mySessionFactory" class="org.springframework.orm.hibernate.LocalSessionFactoryBean">
        <property name="mappingResources">
                <list>
                        <value>sample.hbm.xml</value>
                </list>
        </property>
        <property name="hibernateProperties">
                <props>
                        <prop key="hibernate.dialect">net.sf.hibernate.dialect.MySQLDialect</prop>
                        <prop key="hibernate.show_sql">true</prop>
                </props>
        </property>
        <property name="dataSource"><ref bean="myDataSource"/></property>
</bean>
<bean id="myTransactionManager" class="org.springframework.orm.hibernate.HibernateTransactionManager">
        <property name="sessionFactory"><ref bean="mySessionFactory"/></property>
</bean>

Supposons donc que vous ayez un EJB session stateless qui implémente l'interface IProductServices et un contrôleur qui possède une propriété myProductServices qui s'attend à recevoir un IProductServices.

La configuration suivante permet de déclarer un proxy sur votre EJB sans que votre contrôleur n'en sache rien !! Je veux dire que votre contrôleur ne sait même pas qu'il fait appel à un EJB.

<bean id="myProductServices" 
                class="org.springframework.ejb.access.LocalStatelessSessionProxyFactoryBean">
        <property name="jndiName"><value>myProductServices</value></property>
        <property name="businessInterface"><value>IProductServices</value></property>
</bean>
<bean id="myController" class="myController">
        <property name="myProductServices"><ref bean="myProductServices"/></property>
</bean>

On voit ici la puissance de l'IoC ! Non ? Vous ne voyez rien !?

Mais si regardez, imaginez que vous soyez en cours de développement du contrôleur et que la personne qui doit développer l'EJB n'a pas encore finalisé son code. Pour faire vos tests unitaires, vous avez besoin d'un « bouchon » sur l'EJB, une classe qui va simuler cet EJB (les Anglais parlent de mocked objects). Il vous suffit alors de créer une classe Java classique type MockProductServices qui implémente l'interface IProductServices et de déclarer cette classe à la place de LocalStatelessSessionProxyFactoryBean (et sans les deux propriétés). Pour votre contrôleur, rien ne change !

Lorsque vous en serez à la phase d'intégration de votre processus de développement, tous les « mocked objects » seront remplacés par les « vrais » objets et tout ceci sans aucune modification du code, la très grande classe non ?

Ben, pour les EJB remote c'est pareil. Le seul truc auquel il faut faire « attention » ce sont les exceptions définies dans l'interface remote de votre EJB. Vous avez ici plusieurs possibilités :

• vous ne déclarez aucune exception dans l'interface métier de votre EJB et vous utilisez cette interface dans le fichier de configuration de SPRING ;
• vous déclarez des remote exceptions dans l'interface métier de votre EJB et vous utilisez cette interface dans le fichier de configuration de SPRING ;
• vous déclarez des remote exceptions dans l'interface métier de votre EJB et vous créez une seconde interface métier côté « client » sans les remotes exceptions et vous utilisez cette interface dans le fichier de configuration de SPRING. Dans ce cas, c'est le proxy SPRING qui se charge d'intercepter les exceptions remote et de les transformer en « RuntimeException ».