Netapsys Blog

AGILE & MORE EFFICIENT : Test JUnit, EasyMock & Spring

Abderrazek CHINE — Wed, 24 Mar 2010 08:11:00 +0100

Ce billet aborde l'aspect purement technique de mise en oeuvre de l'agilité dans le développement d'applications robustes.
Il s'inscrit dans la continuité du séminaire de Netapsys sur le thème "Agile & more efficient".
Il présente les tests JUnit 4.x et EasyMock sous Spring afin de concrétiser "être agile".
EasyMock permet de simuler l'accès aux fonctionnalités des couches applicatives, par exemple la couche DAO.
Un des piliers de l'agilité est TDD (Test Driven Development).
Le TDD est une approche évolutive de réalisation de projets basés sur les tests avant même de produire du code effectif.
TDD combine le TFD (Test First development) et le refactoring afin d'arriver à affiner / définir les spécifications.
Easymock et JUnit constituent donc les briques afin de réaliser le TDD via les tests unitaires et d'intégration.
En fait, les tests unitaires sont faciles à mettre en place mais les tests d'intégration restent encore difficiles.
Et le coût de réaliser les tests d'intégration est pesant.
Et EasyMock permet la mise en place des tests sans pour autant avoir développé une ligne de code d'implémentation des couches applicatives. Tous ces aspects vont être explicités ci-dessous.

Nous démarrons avec un projet exemple simple qui permet de comprendre les notions importantes dans EasyMock.
1- Le projet exemple:

Comme notre objectif est de faire du TDD, nous allons écrire uniquement les interfaces puis enchaîner avec les tests sur des classes simulées (moquées) par EasyMock.

/***interface couche dao**/
public IContactDao{
  	void save(Contact contact) ;
}

Et celle de service:

/***interface couche service*****/
public IService{
  	void save(Contact contact) ;
      void setContactDao(IDao dao);
}

Et l'entité Contact est un POJO simple:

package fr.netapsys.easymock.entites;
 
import java.io.Serializable;
 
import fr.netapsys.easymock.common.BaseObject;
 
public class Contact implements Serializable {
	private static final long serialVersionUID = -1511337412528984583L;
	private int id;
	private String nom;
	private String prenom;
	private String mail;
	public Contact() {
		super();
	}	
 
	//Setters/getters omis		
}

Donc nous avons en place les briques techniques qui vont servir à pratiquer le TDD et favoriser les échanges avec le client.
Écrivons les tests avant de commencer les développement pur et dur des couches dao, service et web(back & front).
La classe de test est simple néanmoins consistante afin d'illustrer réellement l'apport des test mock.

2- Classe JUnit4 test

package fr.netapsys.easymock.tests;
 
import org.apache.log4j.Logger;
import org.junit.Assert;
import org.junit.Before;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.springframework.test.context.ContextConfiguration;
import org.springframework.test.context.junit4.SpringJUnit4ClassRunner;
import fr.netapsys.easymock.entites.Contact;
import fr.netapsys.easymock.interfaces.*;
//**** notez cet import *****
import static org.easymock.EasyMock.*;
 
@RunWith (SpringJUnit4ClassRunner.class)
@ContextConfiguration (locations = { "classpath:spring.xml" }) 
public class TestEasyMock {
	private final Logger logger=Logger.getLogger(getClass());
	private IContactDao contactDao;
	private IContactService contactService;
	@Before public void setUp() {
		contactDao=createMock(IContactDao.class);
		contactService= createMock(IContactService.class);
	}
	@SuppressWarnings("nls")
	@Test public void testSave() {
			Contact contact=new Contact();
			//************** createMock, expect, replay, call & verify		
			expect(contactDao.save(contact)).andReturn(saveContactInDao(contact));			
			replay(contactDao);
			contactDao.save(contact);
			verify(contactDao);			
			//appel au service
			expect(contactService.save(contact)).andReturn(saveContactInService(contact));
			replay(contactService);
			Contact c=contactService.save(contact);
			logger.info(">>>>Contact retrieved by service :"+contact.toString());
			verify(contactService);
			Assert.assertTrue(  c.getNom().equals(contact.getNom()) && c.getId()==1 && c.getMail().equals("mail@mail.fr"));
	}
	@SuppressWarnings("nls")
	private Contact saveContactInDao(Contact contact) {
		Contact contact2Return=contact;
		contact.setNom("Easymock");
		contact.setPrenom("test");
		//setter id 
		contact2Return.setId(1);
		return contact2Return;
	}	
	@SuppressWarnings("nls")
	private Contact saveContactInService(Contact contact) {
		Contact contact2Return=contact;//contactDao.save(contact);
		contact2Return.setMail("mail@mail.fr");		
		return contact2Return;
	}
}

NB. Le fichier spring.xml est pour l'instant vide. Il ne contient que les déclarations des namespaces.
La seconde partie de ce billet revient sur ce fichier de configuration pour aller plus loin dans l'utilisation de l'api easymock combiné avec spring.

3- Exécutions des tests

La première capture illustre que le test JUnit répond bien:

Avec une sortie sur la console qui ressemble à:

[INFO  (TestEasyMock.java) >>>>Contact retrieved by service :fr.netapsys.easymock.entites.Contact@17050f5[
  id=1
  nom=Easymock
  prenom=test
  mail=mail@mail.fr
]]}

Easymock est utilisé par spring et le projet apache strutstestcase. Néanmoins, à mon avis, il est plus ou moins intuitif à pratiquer.
Son concurrent MOCKITO séduit par la simplicité d'emploi.
EasyMock se comporte comme un "recorder" et par conséquent nécessite généralement les étapes suivantes:

createMock, ( C'est ce que a été fait dans la méthode annotée par @Before )
expect, (C'est ce qui a été fait dans le corps de la méthode testSave)
replay, (idem)
call, (idem)
verify. (idem. A noter que cet appel peut générer une exception incompréhensible si l'ordre des étapes n'est pas respecté)

La prochaine fois, nous introduirons l'auto-injection Spring des beans de la couche service en simulant (en moquant) uniquement la couche DAO.

Spring annotations vs standards annotations: Que choisir entre @Autowired et @Resource?

Abderrazek CHINE — Sun, 07 Mar 2010 19:32:00 +0100

L'objet de ce billet, en deux parties, est de comparer l'annotation standard @Resource du package javax.annotation.Resource à celle de
spring @Autowired du package org.springframework.beans.factory.annotation.
Nous verrons les situations où nous sommes obligés de favoriser les annotations standards.

L'utilisation des annotations réduit considérablement la verbosité des fichiers de configuration de Spring.
C'est aussi le même constat pour d'autres frameworks.
En effet, le principe "convention Over configuration" participe à cette diffusion.
Certes, les "pour" et les "contre" ne manqueront pas d'arguments pour débattre.
Mais ceci n'est pas l'objet de ce billet.
L'objectif ici est de comparer ces deux types d'annotations.
Pour cela, nous nous appuyons sur un projet java simple, sans maven, que vous pouvez créer sous Eclipse en suivant les étapes décrites ci-après.
Nous écrivons d'abord un projet avec les annotations de Spring puis nous illustrons les difficultés qui nous amèneront à introduire les annotations standards.

PREMIERE PARTIE: Annotations Spring @Autowired, @Service & cie
Dans cette première partie, le projet java exemple ci-après n'utilise que les annotations de Spring.

Pré-requis:
Le projet java standard doit avoir les librairies nécessaires suivantes : spring-2.5.6.jar, spring-test-2.5.6.jar et Junit 4.4.jar ( apache-commons-**.jar).
Notez qu'il faudrait observer ces versions pour contourner un bug connu. Aussi, ne laissez pas eclipse choisir pour vous la librairie JUnit4 à ajouter dans le classpath du projet.

Configuration de Spring
Un fichier de Spring très léger nommé "spring-context.xml" qui contient ces deux lignes:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xmlns:p="http://www.springframework.org/schema/p" xmlns:context="http://www.springframework.org/schema/context"
 xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
 http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-2.5.xsd" 
 default-autowire="byName">
<context:component-scan base-package="fr.netapsys.exemple.dao"/>	
<context:component-scan base-package="fr.netapsys.exemple.service"/>	
</beans>

Les classes java du projet sont ordinaires bien que les différentes couches sont bien séparées.

Couche entités

//la classe Entreprise 
package fr.netapsys.exemple.entites;
public class Entreprise implements Serializable{
	 private int id;
	 private boolean etat;
	 public void setEtat(boolean etat){
		this.etat=etat;		
	 } 
	 public boolean isEtat(){ return etat;}
	//autres setters/getters ......omis
	public String toString(){
		return "Entreprise (id="+id+" etat="+etat+")";
	}
}

Couche DAO
L'interface:

package fr.netapsys.exemple.dao;
public interface IEntrepriseDao{
	boolean createEntreprise(Entreprise e);
}

Notez l'annotation @Repository pour indiquer à Spring que cette classe appartient à la couche DAO.

Et l'implémentation donne:

package fr.netapsys.exemple.dao;
@Repository("entrepriseDao")
public class EntrepriseDao implements IEntrepriseDao{
 
	 public boolean createEntreprise(Entreprise entrep){
	 //do something...
            System.out.println("creating in dao ");
             return true;
	 }
}

Couche service
L'interface:

package fr.netapsys.exemple.service;
public interface IEntrepriseService{
	boolean createEntrerpise(Entrerpise entrep);
}

L'implémentation:

package fr.netapsys.exemple.service;
@Service("entrepriseService")
public class EntrepriseService{
 
	private IEntrepriseDao entrepriseDao;
	@Autowired
	public setEntrepriseDao()
	 public boolean createEntreprise(Entreprise entrep){
	  return entrepriseDao.createEntreprise(entreprise);
	 }
}

Notez l'annotation @Autowired sur le setter de l'attribut entrepriseDao.

Ajoutons une classe de JUnit 4.4 nommée TestAnnotations.java qui contient ceci:

package fr.netapsys.exemple.tests;
/*****imports omis*****/
@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations = {"classpath:spring-context.xml"}) 
 
public class TestAnnotationsSpring {
 
	private IEntrepriseService service;
	@Autowired
	public void setEntrepriseService(IEntrepriseService entrep){
		this.service=entrep;
	}
	@Test public void test1(){
		Entreprise entrep=new Entreprise();
		entrep.setId(1);
		boolean retour=service.createEntreprise(entrep);
		Assert.assertTrue(retour);
	} 
}

Observez l'annotation @RunWith de JUnit4 et celle de @ContextConfiguration de Spring.
Elles permettent d'exécuter ce test JUnit en laissant à Spring le soin de charger son contexte à partir des fichiers mentionnés dans locations.

L'exécution de ce test dans eclipse, clic-droit, run as Junit Test, donne le résultat :

OK, tout cela fonctionne bien.

Mais si on rajoute une nouvelle classe de service, nommée EntrepriseServiceImpl2 dans la trace ci-dessous, qui implémente l'interface IEntrepriseService, notre test JUnit cesse de fonctionner!!!!
Et on obtient une "BeanCreationException" dont la trace est donnée ci-dessous:

''Autowiring of methods failed; nested exception is org.springframework.beans.factory.BeanCreationException: Could not autowire method: public void fr.netapsys.exemples.tests.TestAnnotationsSpring.setEntrepriseService(fr.netapsys.exemple.service.IEntrepriseService); nested exception is org.springframework.beans.factory.NoSuchBeanDefinitionException: No unique bean of type

  fr.netapsys.exemple.service.IEntrepriseService  is defined: expected single matching bean but found 2:
 entrepriseService, entrepriseServiceImpl2

at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor.postProcessPropertyValues ............ ......... Caused by: org.springframework.beans.factory.NoSuchBeanDefinitionException: No unique bean of type fr.netapsys.exemple.service.IEntrep... is defined:

   expected single matching bean but found 2: entrepriseService, entrepriseServiceImpl2

''

Pourquoi donc? Et comment contourner cela?
La seconde partie de ce billet donne avec détails la réponse à ces deux questions.

Le développement logiciel, la confiance, l'arrogance et l'humilité

Abderrazek CHINE — Thu, 04 Mar 2010 20:11:00 +0100

A la lecture de cet article en anglais, je me suis dit qu'il serait bon de partager l'essentiel avec vous.
Ce n'est pas une traduction mais plutôt une adaptation libre.
De plus, l'intérêt sur la vie des développeurs (nous le sommes tous) est bien évident.

Albert Einstein disait "The more I learn, the more I realize I don’t know" ce qui peut se traduire "Plus ta connaissance est grande, plus ton ignorance l'est aussi".
C'est justement ça la beauté de la science avec un grand S. "I have told you that you have to have a big intent to become a man of Science".

Allons donc à l'essentiel en quelques lignes.

Dans le monde de l'entreprise de développement logiciel, l'arrogant peut être défini comme étant celui (développeur, CP ou autre) qui n'écoute jamais autrui.
Et pourquoi le faire puisqu'il sait tout!
Il peut nous faire douter sur notre capacité à prendre des initiatives et/ou à réussir notre entreprise.
En somme, mettre à mal notre confiance.
L'auteur de l'article, cité ci-dessus, soutient que beaucoup d'échecs sont dus à l'arrogance. En effet, l'arrogant finit par avoir des difficultés de communication avec l'équipe.

Pourquoi un développeur peut-il devenir arrogant?

Je ne sais pas!
Mais l'auteur avance une explication pas mal:
L'arrogance est un masque qui cache un vide intérieur d'un grand ego. En réalité, l'arrogant est un esclave de son amour propre et pour lui c'est la seule façon de dissimuler son insécurité et sa frustration.

L'idée, assez répandue, que vous devez être arrogants dans un monde d'arrogance pour réussir ou/et survivre n'est pas constructive
Si vous vous chargez d'arrogance, sachez que la seule chose qui change c'est le nombre total des arrogants sur terre!

Et si je suis arrogant, que dois je faire?

Si vous vous sentez un peu arrogant, la devise de l'auteur est:
''Traitez les autres comme vous voudriez être traités vous-même. Pensez que vous êtes un mortel juste humain, ordinaire.
Sachez qu'il y a quelque part un meilleur professionnel que vous''.
J'ajouterai, observez autour de vous, il y' a beaucoup de gens humbles.

Confiance vs arrogance

La confiance n'est pas l'arrogance. La différence c'est l'excès sur l'étendue de son périmètre de connaissance.
La confiance rassure! L'arrogance anéantit la confiance des autres!

En quoi tout cela concerne le développement logiciel qui est notre métier?

L'humilité est la caractéristique d'une personne sans prétention excessive. L'humble est celui qui ne se conforte pas dans l'idée qu'il est le meilleur ou le plus important.

Les humbles sont agréables et il est facile d'échanger avec eux. Puisqu'ils ne font pas de leur supériorité un principe
Ils ne jugent, qu'après avoir écouté et estimé les idées des autres, au profit d'une (meilleure) solution.
Cela peut se faire au détriment de leurs propres choix.
Être humble facilite une amélioration collective de la productivité. Chacun sentira apporter sa pierre à l'édifice.
C'est aussi être ouvert à la communication et veiller au respect mutuel. Bref, c'est diffuser de la confiance autour de soi.

Chacun peut écrire du code de mauvaise qualité, mais l'humble doit l'admettre et tirer des bénéfices sans, pour autant, considérer cela comme une agression ou même un échec personnel.

Enfin, ce petit programme java peut récapituler l'essentiel:

for( Personne developpeur: equipe){
      arrogant -=developpeur;
}

for( Personne developpeur: equipe){
    humble+=developpeur;
}

JAX-RS web service REST avec Spring (implémentation RestEasy)

Abderrazek CHINE — Sat, 30 Jan 2010 19:54:00 +0100

L'objet de ce billet: Illustrer avec un exemple assez complet la mise en pratique du web service REST (JAX-RS) s'appuyant sur l'implémentation RestEasy de JBoss avec Spring 2.5.
L'exemple repose sur les briques (api) suivantes. Notez bien la version lorsqu'elle est mentionnée.

RestEasy: L'implémentation Jboss de jax-rs (JSR 311),
Spring 2.5 et les annotations,
Hibernate pour la partie persistence
L'api Dozer v4.0 pour les DTO (Data Transfert Objetc) ou VO((Value Object).
Junit 4.4,
HttpUnit,
XMLUnit.

Nota:La version Dozer 4.0 a renommé complètement ses packages. Certains tutos sur le web sont donc caduques.
C'est à la fin de l'étape 5 que nous détaillons l'emploi de l'api Dozer.

Quelques repères:
REST (Representational State Transfer) développé par Roy Fielding qui est l’un des fondateurs du protocol HTTP.
JSR 311 est la spec JAX-RS: Java API for RESTful Web Service. Finalisée en mars 2008.

Les CINQ principes de REST

P1: Tout est ressource, un identifiant unique à chaque ressource (http://localhost:8888/clients/2 pointe sur le client ayant id=2),
P2: Utiliser les méthodes HTTP (HEAD/GET/POST/PUT/DELETE). Et les erreurs standards HTTP,
P3: Les échanges avec plusieurs représentations ( xml,(x)html, json,..),
P4: Échanges sans état (stateless),
P5: Lier les ressources entre elles.

PRÉ-REQUIS: Java5.

Mise en pratique

L'exemple ci-après a pour but d'aller plus loin que l'éternel "HelloWorld".
Car je trouve que le fameux "Helloworld" ne permet pas de d'aborder les notions intéressantes.

Voici donc les étapes de mise en œuvre d'un exemple assez complet. Celui-ci répond aux cas d'utilisation suivants:

- Rechercher dans la base (mysql ) un ou plusieurs contacts,

- Créer un nouveau contact,

- Mettre à jour un contact existant.

Les méthodes HTTP GET et POST seront illustrées.

LES ETAPES DU PROJETWEB SOUS MAVEN2

Etape 1: pom.xml du projet maven

Etape 2: web.xml

Etape 3: Configurer fichier de Spring

Etape 4: Classe entités (POJO) Contact.java

Etape 5: Classe DTO (Data Transfert Object) ContactDto.java.

Etape 6: Classe java ContactResource (le webservice)

Etape 7: Classe de test JUnit 4.4 & XMLUnit

Etape 8: Conclusion

PS. La suite suppose l'existence d'une base mysql avec une table nommée contact avec les champs indiqués dans le POJO Contact.java

Détaillons ensemble ces étapes:

Etape 1: Configurer pom.xml

<dependencies>
	<!--  DOZER  DTO Data Transfert Object -->
	<dependency>
			<groupId>net.sf.dozer</groupId>
			<artifactId>dozer</artifactId>
			<version>4.0</version>
				<exclusions>
					<exclusion>
						<groupId>commons-collections</groupId>
						<artifactId>commons-collections</artifactId>
					</exclusion>
				</exclusions>
	</dependency>
    <!--  resteasy webservice dep -->
    <dependency>
		<groupId>org.jboss.resteasy</groupId>
		<artifactId>resteasy-jaxrs</artifactId>
		<version>1.2.GA</version>
	</dependency>
	<!--  JAXB manipuler xml   -->
	<dependency>
	<groupId>org.jboss.resteasy</groupId>
	<artifactId>resteasy-jaxb-provider</artifactId>
	<version>1.2.GA</version>
   </dependency>
	<!-- spring resteasy -->
	<dependency>
	  <groupId>org.jboss.resteasy</groupId>
	  <artifactId>resteasy-spring</artifactId>
	  <version>1.2.GA</version>
	</dependency>
	<!--  SPRING -->
	<dependency>
		<groupId>org.springframework</groupId>
		<artifactId>spring-web</artifactId>
		<version>2.5.5</version>
 
	</dependency>
	<dependency>
			<groupId>org.springframework</groupId>
			<artifactId>spring-beans</artifactId>
			<version>2.5.5</version>
	</dependency>
	<dependency>
		<groupId>org.springframework</groupId>
		<artifactId>spring-jdbc</artifactId>
		<version>2.5.5</version>
	</dependency>		
	<dependency>
		<groupId>org.springframework</groupId>
		<artifactId>spring-orm</artifactId>
		<version>2.5.5</version>
	</dependency>		
	<dependency>
		<groupId>org.springframework</groupId>
		<artifactId>spring-tx</artifactId>
		<version>2.5.5</version>
	</dependency>	
	<!--  hibernate -->
	<dependency>
			<groupId>org.hibernate</groupId>
			<artifactId>hibernate</artifactId>
			<version>3.2.6.ga</version>
	</dependency>
	<dependency>
			<groupId>asm</groupId>
			<artifactId>asm</artifactId>
			<version>3.0</version>
	</dependency>
 
	<dependency>
			<groupId>org.hibernate</groupId>
			<artifactId>hibernate-annotations</artifactId>
			<version>3.3.1.GA</version>
	</dependency>
	<dependency>
			<groupId>org.hibernate</groupId>
			<artifactId>hibernate-entitymanager</artifactId>
			<version>3.3.1.ga</version>
	</dependency>
	<dependency>
			<groupId>cglib</groupId>
			<artifactId>cglib-nodep</artifactId>
			<version>2.1_3</version>
	</dependency>
	<!--  connector mysql -->    
		<dependency>
			<groupId>mysql</groupId>
			<artifactId>mysql-connector-java</artifactId>
			<version>5.1.6</version>
	     </dependency>
	<!-- LOG4J -->
	<dependency>
		<groupId>log4j</groupId>
		<artifactId>log4j</artifactId>
		<version>1.2.15</version>
	</dependency>
 
         <!-- NOTA dependences commons de jakarta OMIS -->
 
	<!--  test et spring-test -->			
	<dependency>
		      <groupId>org.springframework</groupId>
		      <artifactId>spring-test</artifactId>
		      <version>2.5.4</version>
		      <scope>test</scope>
	</dependency>   
	<dependency>
           <groupId>httpunit</groupId>
          <artifactId>httpunit</artifactId>
           <version>1.6.2</version>
           <scope>test</scope>
       </dependency>
	<dependency>
          <groupId>junit</groupId>
         <artifactId>junit</artifactId>
         <version>4.4</version>
        <scope>test</scope>
      </dependency>
     <dependency>
    	<groupId>xmlunit</groupId>
    	<artifactId>xmlunit</artifactId>
    	<version>1.2</version>
     </dependency>
  </dependencies>

Tout est commenté.
je signale juste que j'ai choisi la version 4.4 de Junit avec Spring 2.5 pour contourner un bug de JUnit4.5 avec Spring 2.5.

Etape 2 :Le fichier web.xml de l'application web:

<web-app>
           <!-- Premiere option: Configurer les classes resources-->
		<context-param>
	        <param-name>resteasy.resources</param-name>
	        <param-value>fr.netapsys.rest.webservice.rs.ContactResource</param-value>
	    </context-param>
            <!-- PREFIX pour les appels de web service rest -->
		<context-param>
			<param-name>resteasy.servlet.mapping.prefix</param-name>
			<param-value>/rest</param-value>
		</context-param>
	   <!--  LISTENERS  ATTENTION L'ORDRE DES LISTENERS EST IMPORTANT-->
		<listener>
	  	 <listener-class>
	  			org.jboss.resteasy.plugins.server.servlet.ResteasyBootstrap
	  	 </listener-class>
		</listener>
	    <!-- Spring listener -->
		<listener>
	  	 <listener-class>
	       org.jboss.resteasy.plugins.spring.SpringContextLoaderListener
	     </listener-class>
	    </listener>		
	    <!--Servlet RESTeasy -->
		<servlet>
				<servlet-name>Resteasy</servlet-name>
				<servlet-class>org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher</servlet-class>
	 	</servlet>			
		<!-- Les urls debutant par /rest/ seront traitees par la servlet RESTeasy-->
		<servlet-mapping>
				<servlet-name>Resteasy</servlet-name>
				<url-pattern>/rest/*</url-pattern>
		</servlet-mapping>		
 </web-app>

Les lignes sont commentées clairement.

Etape 3: Configurer le fichier de spring nommé applicationContext.xml. Il importe deux autres : spring.xml et dozer_spring.xml:

<!-- file applicationContext.xml sous WEB-INF.xml -->
	<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans" 
                xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
		xmlns:p="http://www.springframework.org/schema/p" 
                xmlns:context="http://www.springframework.org/schema/context"
		xsi:schemaLocation="http://www.springframework.org/schema/beans 
                http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
		http://www.springframework.org/schema/context 
                http://www.springframework.org/schema/context/spring-context-2.5.xsd" 
                default-autowire="byName">
  <import resource="classpath:spring.xml"/>
  <import resource="classpath:dozer_spring.xml"/>
</beans>

Le fichier spring.xml localisé sous src/main/resources/ et il doit contenir:

<!-- ENTETE OMIS -->
	<!--   packages autowiring -->
 	<context:component-scan base-package="fr.netapsys.rest"/>
	<context:property-placeholder location="classpath:rest.properties" />
	<bean id="dataSource"
		class="org.springframework.jdbc.datasource.DriverManagerDataSource"
		p:driverClassName="${datasource.driver}" p:url="${datasource.url}"
		p:username="${datasource.username}" p:password="${datasource.password}" />
	<tx:annotation-driven transaction-manager="transactionManager" />
	<bean id="transactionManager"
		class="org.springframework.orm.hibernate3.HibernateTransactionManager">
		<property name="sessionFactory">
			<ref bean="sessionFactory" />
		</property>
	</bean>
	<bean id="sessionFactory"
		class="org.springframework.orm.hibernate3.annotation.AnnotationSessionFactoryBean">
		<property name="dataSource">
			<ref bean="dataSource" />
		</property>
		<property name="hibernateProperties">
			<props>
				<prop key="hibernate.dialect">${hibernate.dialect}</prop>
				<prop key="hibernate.hbm2ddl.auto">${hibernate.hbm2ddl.auto}</prop>
				<prop key="hibernate.jdbc.batch.size">${hibernate.jdbc.batch.size}</prop>
				<prop key="hibernate.show.sql">${hibernate.show.sql}</prop>
 
			</props>
		</property>
		<property name="mappingResources">
      	<list>
        <value>Contact.hbm.xml</value>
      	</list>
    </property>	
		<property name="annotatedClasses">
			<list>
				<value>fr.netapsys.rest.entites.Contact</value>
			</list>
		</property>
	</bean>
	<bean id="hibernateTemplate" class="org.springframework.orm.hibernate3.HibernateTemplate">
		<property name="sessionFactory">
			<ref bean="sessionFactory" />
		</property>
	</bean>
	<bean id="hibernateDao"
		class="org.springframework.orm.hibernate3.support.HibernateDaoSupport"
		abstract="true">
		<property name="sessionFactory">
			<ref bean="sessionFactory" />
		</property>
	</bean>
</beans>


Pour rappel, les variables ${} sont à déclarer dans le fichier jdbc.properties qui n'est pas détaillé ici.

Enfin voici le contenu de dozer_spring.xml localisé sous src/main/resources:

<!-- entete omis-->
 
	<bean id="dozerBeanMapper"
		class="net.sf.dozer.util.mapping.DozerBeanMapper">
		<!-- OPTIONNEL car les noms des attributs sont identiq -->
            <!--
                <property name="mappingFiles">

			<list>
				<value>dozerBeanMapping.xml</value>
			</list>
		</property>
            -->
	</bean>
</beans>

Pour être complet, nous reviendrons sur le fichier de configuration de Dozer nommé dozerBeanMapping.xml a la fin de l'étape5.

Etape 4: Classe entités (POJO) Contact.java

package fr.netapsys.rest.entites;
import java.util.Date;
import fr.netapsys.rest.common.BaseObject;
public class Contact extends BaseObject  {
	private static final long serialVersionUID = 1L;
	private int id;
	private String nom;
	private String prenom;
	private String mail;
	private Date date;
 
	public Contact() {
	}	
	//setters/getters omis...
}

A signaler que la classe BaseObject du package commons d'Apache permet de définir toString comme suit:

package fr.netapsys.rest.common;
import org.apache.commons.lang.builder.*;
import java.io.Serializable;
public class BaseObject implements Serializable {
	private static final long serialVersionUID = 1L;
	public String toString() {
		return ToStringBuilder.reflectionToString(this,
				ToStringStyle.MULTI_LINE_STYLE);
	}
}

Etape 5: Classe DTO ContactDto.java

package fr.netapsys.rest.dto;
import java.util.Date;
import javax.xml.bind.annotation.*;
import fr.netapsys.rest.common.BaseObject;
@XmlRootElement(name="contact")
@XmlAccessorType(XmlAccessType.FIELD)
@XmlType(propOrder = { "id", "nom","prenom","mail","date",})
public class ContactDto extends BaseObject {
	private static final long serialVersionUID = 1L;
	@XmlElement(name = "identifant", required = true) private int id;
	@XmlElement(name = "nom", required = true) private String nom;
	@XmlElement(name = "prenom", required = false) private String prenom;
	@XmlElement(name = "email", required = false) private String mail;
	@XmlElement(name = "date", required = false) private Date date;
	//getters / setters omis...			
}

Comme vous le constatez c'est dans cette classe DTO que les annotations JAXB sont introduites.

Dozer pour faire du mapping de BEANS
Nous allons comme promis revenir à l'explication de l'api Dozer et de son fichier de config dozerBeanMapping.xml.
L'api Dozer permet de s'affranchir de la tâche fastidieuse de recopier les valeurs des variables (attributs) d'un bean vers un autre.
Ceux ayant travaillé avec des frameworks MVC ont été amené à écrire plusieurs lignes de code rien que pour recopier les variables d'une entité de persistence vers des bean de la couche de présentation.
C'est bien évidemment fastidieux, répétitif et complètement inutile sans parler du temps perdu consacré à corriger les bugs.
Pour faire simple, deux lignes de code avec l'api Dozer:

DozerBeanMapper dozerBeanMapper=new DozerBeanMapper (); 
 
TargetObject targetObj = (TargetObject) dozerBeanMapper.map(SourceObject,TargetObject.class);

Ce qui établit le mapping bidirectionnel entre la classe TargetObject et la classe source SourceObject.
Si nous l'appliquons à notre cas, ceci donne (voir étape 6 à deux endroits):

ContactDto dto=(ContactDto) dozerBeanMapper.map(contact,ContactDto.class);
//ou encore
Contact contact = (Contact) dozerBeanMapper.map(contactDto,Contact.class);

Le fichier de config de Dozer, dans notre exemple, est vide et il n'est donc pas nécessaire de le déclarer.
Il doit, lorsque ces attributs ne portent pas les mêmes noms, contenir les noms de classes concernées par le mapping et les correspondances entre les attributs.
Auquel cas, le fichier doit ressembler à l'extrait suivant:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE mappings PUBLIC "-//DOZER//DTD MAPPINGS//EN"
   "http://dozer.sourceforge.net/dtd/dozerbeanmapping.dtd">
<mappings>
	<mapping>
               <class-a>fr.netapsys.rest.entites.Contact</class-a>
		<class-b>fr.netapsys.rest.dto.ContactDto</class-b>
	</mapping>
          <field>
		      <a>NOM_ATTRIBUT_a</a>
		      <b>NOM_ATTRIBUT_b</b>
	 </field>	
          .....
</mappings>

Etape 6: Classe java ContactResource (classe du web service Rest)

package fr.netapsys.rest.webservice.rs;
import java.net.URI;
import java.util.List;
import javax.ws.rs.*;
import net.sf.dozer.util.mapping.DozerBeanMapper;
import org.apache.log4j.Logger;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Component;
import fr.netapsys.rest.dto.*;
import fr.netapsys.rest.entites.Contact;
import fr.netapsys.rest.interfaces.IContactService;
import fr.netapsys.rest.webservice.rs.utils.UtilsMapper;
@Component
@Path("/contacts")
public class ContactResource {
	private Logger logger = Logger.getLogger(fr.netapsys.rest.webservice.rs.ContactResource.class);	
	IContactService contactService;
	@Autowired
	public void setContactService(IContactService contactService) {
		this.contactService = contactService;
	}
	private DozerBeanMapper dozerBeanMapper;
	@Autowired
	public void setDozerBeanMapper(DozerBeanMapper dozerBeanMapper) {
		this.dozerBeanMapper = dozerBeanMapper;
	}
	@GET
	@Path("/{id}")
	@Produces (MediaType.APPLICATION_XML)
	public  ContactDto getContactById(@PathParam("id") int id)  {
		logger.debug("Call getById with id : " + id);
		Contact contact = contactService.find(id);
		return (ContactDto) dozerBeanMapper.map(contact,ContactDto.class);
	}
 
	@POST
	@Path("/create/")
	@Produces(MediaType.APPLICATION_XML)
	@Consumes(MediaType.APPLICATION_XML)
	public Response post4CreateNewContact(final ContactDto contactDto,@Context UriInfo uriInfo) {
		Contact contact = (Contact) dozerBeanMapper.map(contactDto,Contact.class);
		contactService.save(contact);
		contactDto.setId(contact.getId());		
		// Building URI: recuperer le path courant
		UriBuilder uriBuilder = uriInfo.getAbsolutePathBuilder();
		//Cree l uri pour acceder à la new resource contactDto 
		URI uri = uriBuilder.path( String.valueOf(contactDto.getId())).build();
		//retourne la reponse avec la new resource contactDto
		return Response.created(uri).entity(contactDto).build();
	}
}

La ligne Contact contact = (Contact) dozerBeanMapper.map(contactDto,Contact.class); établit le mapping bidirectionnel via l'api dozer entre la classe de persistence Contact et la le pojo ContactDto qui est exposé à la couche de présentation.
NOTE: Les classes des couches Service et Dao: ContactDao et ContactService.java sont bien ordinaires et ne sont pas détaillées ici.

Etape 7: Classe de test JUnit & XMLUnit

L'exécution de ces tests nécessitent deux pré requis:

 # D'avoir une instance de la base MYSQL  démarrée. On suppose que la table CONTACT contient au moins une ligne. Utiliser l'identifiant de cette ligne pour la méthode testContactGetresource.
#  D'exécuter, via une console dos la commande mvn jetty:run afin de lancer le serveur web, puis dans l'environnement Eclipse exécute le test JUnit.

Bien évidemment, on peut rendre ces tests d'intégration automatisés. Dans un prochain billet je détaillerai les étapes de configuration.

Le code de la classe Junit est comme suit:

public class TestContactResourceTest extends XMLTestCase{
	final static String URL_BASE="http://localhost:8888/restspring/rest/";
	@Test
	public void testContactGetResource() throws HttpException, IOException, SAXException{
		final String id="1";
		GetMethod method = new GetMethod(URL_BASE + "contacts/"+id+"/");
		method.setRequestHeader("Accept", MediaType.APPLICATION_XML);
		HttpClient client = new HttpClient();
		int status=client.executeMethod(method);
		assertEquals(200, status);
		String str = method.getResponseBodyAsString();
		method.releaseConnection();
		final String responseExpected="<?xml version=\"1.0\" encoding=\"UTF-8\" standalone=\"yes\"?>"+
		"<contact><identifant>"+ id +
		"</identifant><nom>ach</nom><prenom>ab</prenom><email>a.chine@netapsys.fr</email><date>2009-10-18T00:00:00Z</date></contact>";
		assertXMLEqual(str,responseExpected );
	}
        // Utilisation de la methode POSt pour créer un contact
	 @Test 
	 public void testCreateContact() throws HttpException, IOException{
 
		final String request2Post="<contact><identifant/><nom>TEST130110</nom><prenom>ab</prenom><email>a.chine@netapsys.fr</email><date>2010-01-13T00:00:00Z</date></contact>";
 
		PostMethod method = new PostMethod(URL_BASE + "contacts/create/");
		method.setRequestEntity(
				new StringRequestEntity(request2Post,"application/xml", null));
				HttpClient client = new HttpClient();
				int status = client.executeMethod(method);
				method.releaseConnection();
				assertEquals(HttpStatus.SC_CREATED, status);
	}
}

Notez que la classe de test étend XMLTestCase afin de pouvoir de profiter de l'api XmlUnit et tester les retours XML des appels aux webservice ContactResource.
Notez que vous pouvez lancer, sous la console dos, la commande mvn jetty:run; puis, dans le navigateur Firefox ou IE, saisir l'url suivante:
http://localhost:8888/restspring/rest/contacts/9
Et vous obtiendrez la sortie xml ci-après:

<contact>
<identifant>9</identifant>
<nom>ach</nom>
<prenom>ab</prenom>
<email>a.chine@netapsys.fr</email>
<date>2009-10-18T00:00:00Z</date>
</contact>

Etape 8: Conclusion

Ce billet montre la facilité de création des webservices REST avec l'implémentation opensource RestEasy de Jboss combiné avec Spring.
La classe de test, qui s'appuie sur l'api HttpClient, prouve tout l'intérêt de pratiquer les tests d'intégration qui peuvent être facilement automatisés en les insérant dans un "goal maven".
Enfin, signalons que certaines étapes ne sont pas suffisamment explicitées néanmoins je pourrais y revenir avec plus de détails si vous le demandez.

Résolutions pour la nouvelle année

Abderrazek CHINE — Fri, 15 Jan 2010 15:15:00 +0100

Le jour de mon anniversaire (oui Bénédicte, je l'avais oublié mais je te rassure : ça dure depuis un moment...). Il est 15:15, je me suis appliqué à écrire mes quinze moins quatre résolutions suite à la lecture de la lettre du père noël sur le blog .
Après réflexion, j'ai décidé de les partager avec vous.
Avec ces onze là, on est qualifié au mondial en Afrique du sud :).

Onze ça fait trop, impossible à tenir!
Aïe, ce n'est pas équitable ! Il y en a plus pour les développeurs que pour les CP ! Injuste !
Oui. c'est vrai ! Mais ça ne date pas d'aujourd'hui.

Voici ces résolutions (recommandations) réparties en trois groupes.

A la lecture des trois groupes ci-après, on devinera facilement à qui elles sont destinées. Un indice, le second groupe est commun à nous tous.

Premier groupe de résolutions:

Pour ton développement, utilise du code déjà éprouvé en prod, mieux vaudra.
Utiliser des frameworks largement diffusés, moins de bugs tu récolteras.
Pour ton développement, les tests unitaires en place tu mettras.
Pour les webservices, les tests d'intégration tu automatiseras.
Avant de commiter/livrer, les tests unitaires tu valideras.
Avant de livrer au client, sur son serveur cible tu testeras.
Tes choix techniques, avec le CP tu valideras.

Second groupe:

Utiliser les bonnes pratiques de design pattern, ton livrable mieux se portera.
Les tests sous Selenium ou/et Jmeter, tu penseras.
Du retard, très vite une alerte tu lèveras.

Troisième groupe :

Quinze jours avant la livraison, le client tu aviseras.
Trois jours avant la livraison, un rappel tu feras.
Mon CP les specs, en français explicite tu écriras.

Happy new year.

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

Abderrazek CHINE — Fri, 06 Nov 2009 21:46:00 +0100

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.

Avertissement: Dépendances/classpath: le jar spring-modules-0.9.jar de Spring validation doit être dans le classpath car il n' est pas inclus dans les spring_xxxx.jar.
Pour un projet maven, ajouter dans le pom.xml la ligne:

<dependency>
      <groupId>org.springframework</groupId>
      <artifactId>spring-modules</artifactId>
      <version>0.9</version>
    </dependency>

Le framework de validation de Spring se décline en quatre actes qui vont être détaillés par la suite:

ACTE 1:

  - Ecrire vos beans (POJO) entités.

Puis, pour leurs attributs à valider, ajouter les annotations appropriées tels @NotBlank, @Length, @Email, @Range, @InThePast, @InTheFuture,....

ACTE 2:

  - Déclarer un des validators prédéfinis de Spring
 dans son fichier de config comme suit:

<!-- Enable annotation-based validation
        using Bean Validation Framework -->
   <bean id="configurationLoader"  
    class=
     "o.springmodules.validation.bean.
       conf.loader.annotation.
      AnnotationBeanValidationConfigurationLoader"/>
   <bean id="validator" class=
      "o.springmodules.validation.bean
      .BeanValidator" 
      p:configurationLoader-ref="configurationLoader"/>

Notez que l'utilisation du namespace p: va rendre la configuration xml plus concise comme nous le verrons par la suite.

ACTE 3:

  
  - Dans le Controller du spring MVC, déclarer

le Validator annoté avec @Autowired comme suit:

//*** validator de spring validation	
  private Validator validator;
  @Autowired
  public setValidator(Validator validator){
    this.validator=validator;
  }

Pour le projet java Standalone, nous donnerons toutes les précisions utiles au moment de présenter l'exemple.

ACTE 4:

  - Ajouter dans cette même classe une seule ligne de code:

validator.validate(YOUR_BEAN_POJO, ..)

Et voilà !

Pour le peu d'effort déployé nous avons obtenu ceci :

Et cela :

Ok, tout ça est bien! Mais comment cela fonctionne t-il ?

Avant de répondre, construisons ensemble un exemple de projet Spring MVC simple et détaillons chacun des 4 actes.

  Projet démo Web Spring MVC

Pour ce projet web exemple en Spring MVC nommé spring-mvc, nous aurons à manipuler :

Le(s) classe(s) POJOs : Personne.java et Client.java
Le fichier de configuration du contexte web de Spring : spring-mvc-servlet.xml
La classe du controller de Spring nommée ClientControllerSpringMVC.java
Le fichier « properties » nommé : messages.properties

ACTE1:

Ecrire les POJOs:

public class Personne implements Serializable {
	String nom;
	String prenom;
	// + setters/getters omis
}

public class Client extends Personne{
	long cliId;
	@NotBlank 
	@Length( max = 15) 
	private String cliNom;
        //***aucune regle de validation sur prenom
	private String cliPrenom;
	@NotBlank @Length(min=4) @Email
	private String cliEmail;
       //+setters / getters omis
	public String toString(){
		return "Id="+getCliId()+ " nom="+getNom()+
                      " prenom="+getPrenom();
	}
}

ACTE2:

Le fichier spring-mvc-servlet.xml contient ces lignes:

<?xml version="1.0" encoding="UTF-8"?>
<beans 
        xmlns=
"http://www.springframework.org/schema/beans" xmlns:xsi=
"http://www.w3.org/2001/XMLSchema-instance"
	xmlns:p=
"http://www.springframework.org/schema/p" xmlns:context=
"http://www.springframework.org/schema/context"
	xsi:schemaLocation=
 "http://www.springframework.org/schema/beans 
 http://www.springframework.org/schema/
  beans/spring-beans-2.5.xsd
 http://www.springframework.org/schema/context
 http://www.springframework.org/schema/
   context/spring-context-2.5.xsd"
 default-autowire="byName">
   <bean id="configurationLoader"  
    class=
     "o.springmodules.validation.bean.conf.
     loader.annotation.
    AnnotationBeanValidationConfigurationLoader"/> 
   <bean id="validator" class=
    "org.springmodules.validation.bean.BeanValidator" 
    p:configurationLoader-ref="configurationLoader"/> 
 
    <!-- Load messages --> 
   <bean id="messageSource"  
      class=
       "o.s.context.support.ResourceBundleMessageSource"
	   p:basenames="messages"/> 
   <bean class=
       "o.s.web.servlet.view.
        InternalResourceViewResolver"
	   p:prefix="/WEB-INF/jsp/" p:suffix=".jsp"/>

Notez que certaines écritures des packages connus sont abrégées: par exemple, o.s pour désigner org.springframework.

ACTES 3 et 4Le controller et le fichier properties:

- La validation dans le controller:

Dans le controller, ajouter la déclaration du validator, par exemple, dans la méthode createClient comme suit :

//*** Controller de spring MVC avec les annotations	
@Controller("clientControllerSpring")
public class ClientControllerSpringMVC {
	final Logger logger=Logger.getLogger(getClass().getName());
 
 
==>	private Validator validator;  
	@Autowired         
	public void setValidator(Validator validator) {  
		this.validator = validator;  
	}  
 
	@RequestMapping(value = "/createClient.html", 
                                        method = RequestMethod.GET)  
	public ModelMap get() {     
		return new ModelMap("client", new Client());  
	}  
	@RequestMapping(value="/createClient.html",
                                       method = RequestMethod.POST)
	public String createClient(	@ModelAttribute("client") Client client,
                                      	BindingResult result,	ModelMap model) {
 
==>		validator.validate(client, result);
==>		if(result.hasErrors()){
			logger.warn("Erreurs sur le client "+result.toString());
			return null;
		}
			//Traitement métier;
 
		return Constants.SUCCESS;
	}
}

Les trois passages intéressants à observer sont précédés de la flèche "==>".

Enfin, compléter le fichier « messages.properties » sur l’exemple qui suit :

Client.cliNom[not.blank]=Merci de saisir votre nom.  
Client.cliNom[length]=Merci de saisir moins de {2} caracteres.

Pour finir, lancer la commande:

mvn jetty:run

Avec le navigateur saisir le lien:
http://localhost:8080/spring-mvc/createClient.html
Vous obtenez alors les formulaires des captures présentées précédemment.
Il ne vous reste qu'à tester les différentes possibilités de saisie dans les 2 champs "nom" et "email".

Conclusion :
Cette première partie a révélé la puissance de ce framework (add-on) de Spring intégré dans un projet Web MVC.
Seules les annotations @NotBlank, @Length et @Email ont été évoquées.
Nous poursuivons, dans la seconde partie de ce billet, la démonstration sur un projet Java standard.
D’autres annotations de validation vont être présentées : @InThePast, @Size, @Range,…

Nous montrons également comment créer notre propre classe de validation qui permet d’étendre les fonctionnalités de validation existantes.
D’un point de vue économique et de gestion de projet, l’effort et le temps gagnés avec ce framework sont manifestement énormes.

Pratiquer le design-pattern Strategy en 15 min

Abderrazek CHINE — Mon, 12 Oct 2009 18:30:00 +0200

Dans ce billet, nous poursuivons les notions de design-pattern (motifs de conception).
Après le design-pattern Observer, étudions un autre motif de conception Strategy qui appartient aussi au groupe de comportement.
Ce motif de conception permet de définir plusieurs algorithmes interchangeables dynamiquement.

Encore un motif de conception qui répond à la question : Comment faire simple quand on peut faire compliqué ?
En fait, cela reste simple si on n'oublie pas de le pratiquer tôt. Sinon, ce sont les développements, les tests et les évolutions qui deviennent compliqués.
Mais, la revue de code permet aussi d'éviter de rendre les développements plus compliqués et de tirer profit de la mise en place de ces design.

D'un point de vue théorique, il est facile de l'appréhender. Néanmoins, la mise en pratique (avec le langage Java) de ce design reste un peu moins évidente.

Beaucoup d'entre nous l'ont déjà pratiqué sans, forcément, le savoir.
Un exemple de l'API Java est la méthode Collections.sort ayant deux arguments dont le second est l'algorithme de comparaison pour effectuer le tri.
Ainsi, cette méthode est fournie avec une implémentation par défaut qui convient à bon nombre de types de données avec la possibilité de redéfinir dynamiquement de nouveaux algorithmes de tri.

Notons enfin que dans l'exemple d'illustration ci-après, nous allons comparer deux entreprises déclarées dans des répertoires différents
Et par conséquent, les codes de référence et libellés sont variés et distincts d'un répertoire à un autre.
La comparaison est basée sur un score de pertinence qui est une moyenne de(s) différente(s) note(s) calculée(s).

Un seul pré-requis pour ce billet : connaître la notion de composition en programmation objet.

Situation/problème:
Un objet doit définir plusieurs algorithmes interchangeables dynamiquement. Ces algorithmes bien qu'ils répondent à la même interface peuvent évoluer indépendamment.

Solution:
Le design Strategy répond à cette problématique par l'introduction de la composition dans la classe essentielle qui doit contenir l'algorithme.

Avantages:
Mise en place de bonne pratique,
Code extensible avec aisance d'inter changer les algorithmes,
Code facile à maintenir en cas d'évolution/changement.

Mise en pratique:
Notre exemple pratique, tiré d'une situation réelle, a pour but de comparer deux entreprises déclarées dans deux répertoires distincts
Par exemple, le premier est le répertoire FINESS et le second est SIRENE de l'INSEE.
Les déclarations peuvent complètement différer d'un répertoire à un autre sur :
Les formats des données,
Les codes de référence d'adresse ou de géolocalisation,
Bien d'autres indicateurs.

Exemple:
Pour fixer les idées prenons cet exemple:
La première entreprise a pour enseigne: SARL AMBULANCE TAXI PARIS dans le premier répertoire disons par exemple le répertoire de l'INSEE. et la seconde (qui peut être la même) est enregistrée encore dans un second répertoire qui gère spécialement le métier des ambulances médicales: SARL TRANSPORT AMBULANCE PARIS
En résumé, la comparaison de ces deux entités va reposer sur un algorithme qui est interchangeable dynamiquement:

Le premier algorithme, celui par défaut, qui compare l'égalité des enseignes (chaînes de caractères). Rarement utile. D'où le second
Le second qui parcourt les mots qui composent chacune des enseignes afin de les comparer et puis établir des scores.

On a simplifié le problème en ne s'intéressant qu'à la notion de l'enseigne comme suit:
On affecte la note total de 100 lorsque les deux enseignes sont identiques (cad les deux chaînes de caractères sont identiques).
Sinon, on affecte une note liée à la comparaison de chaque mot qui compose ces enseignes
Les détails de cette comparaison n'est pas utile pour la compréhension du billet.

Les quatre classes sont de simples POJO utilisées pour la suite.
/****Classe EtabCommune***/

public class EtabCommune  implements  Serializable{
 
	private static final long serialVersionUID = 1L;
	private String nom;
	public String getNom() {
		return nom;
	}
	public void setNom(String nom) {
		this.nom = nom;
	}	
	public String toString(){
		return 	"Nom:"+getNom();
	}
}

/****EtabFiness****/

public class EtabFiness extends EtabCommune  {
	private int codeCategorie;
	public int getCodeCategorie() {
		return codeCategorie;
	}
	public void setCodeCategorie(int codeCategorie) {
		this.codeCategorie = codeCategorie;
	}
	public String toString(){
		return "Finess:"+super.toString()+"\tCodeCategorie="+getCodeCategorie();
	}	
}

/********EtabSirene************/

public class EtabSirene extends EtabCommune implements Serializable {
 
	private static final long serialVersionUID = 1L;
	int type;
	public int getType() {
		return type;
	}
	public void setType(int type) {
		this.type = type;
	}
	public String toString(){
		return "Sirene:"+super.toString()+"\tType="+type;
	}
}

/******NotesComparaison************/

public class NotesComparaison  implements Serializable{
	private static final long serialVersionUID = 1L;
	double noteEnseigne;
	public double getNoteEnseigne() {
		return noteEnseigne;
	}
	public void setNoteEnseigne(double noteEnseigne) {
		this.noteEnseigne = noteEnseigne;
	}
	public String toString()
	{ 
		return "noteEnseigne="+noteEnseigne;//+autres composantes de la note
	}
}

Voici les algorithmes de comparaison avec implémentation par défaut (dans la class AbstractAlgorithme) et une seconde (pour démo).
Le client, un peu plus loin, va illustrer l'emploi des deux implémentations.

/*****Algorithme (interface,classe abstraite, implémentation )*****/
/**** IAlgorithme ***/

public interface IAlgorithme {
	public double calculateNoteEnseigne(String nomFiness,String nomSirene) ;
}

/**** AbstractAlgorithme (alg utilisé par defaut)***/

public abstract class AbstractAlgorithme implements IAlgorithme {
	public double calculateNoteEnseigne(String nomFiness,String nomSirene) {	
		if(nomFiness==null) return 0.0;
		if(nomFiness.equals(nomSirene))return 100.0;
		return 0.0;
	}
}

/**** ConcreteAlgorithme: démo ***/

public class ConcreteAlgorithme extends AbstractAlgorithme {
	public double calculateNoteEnseigne(String nomFiness,String nomSirene) {
		if(nomFiness==null || nomFiness.trim().equals("") ||  
                            nomSirene==null || nomSirene.trim().equals(""))return 0.0;
 
                final String[] listeFinessEnseigne=nomFiness.split(" ");
		final String[] listeSireneEnseigne=nomSirene.split(" ");
		double[] notes =new double[listeFinessEnseigne.length];
		int dimension=notes.length;
		for(int i=0;i<dimension;i++) notes[i]=0.0;
		int k=0;
		for( String mot:listeFinessEnseigne){
		  for (String terme: listeSireneEnseigne ){
			if (mot.equals(terme)) notes[k]=100.0; 
		  }
		  k++;	 
		}
		double note=0.0;
		for(double n:notes){
		   note+=n;	
		}
		return note/dimension; //DIV ZERO!
	}
}

La classe Comparaison contient les détails de l'implémentation du motif stratégie.
En effet, la classe Comparaison délègue l'algorithmique de comparaison à la classe/interfae AbstractAlgorithme/IAlgorithme via l'attribut algorithme.
Néanmoins, cette classe fournit, dans le constructeur sans argument, une implémentation par défaut.
Le client peut redéfinir dynamiquement l'algorithme de comparaison, comme illustré dans le client ci-après

/****Comparaison (interface et implémentation)***/

public interface IComparaison {
	public NotesComparaison compare(EtabFiness finess, EtabSirene sirene);
	public void setAlgorithme(IAlgorithme algorithme) ;
 
}

/************ classe importante implémentant le motif stratégie************************/

public class Comparaison implements IComparaison{
	private IAlgorithme algorithme;
	public Comparaison(IAlgorithme algorithme){
		this.algorithme=algorithme;
	}
	public Comparaison(){
		this.algorithme=new Algorithme();
	}
	/***Methode prinicpale...***/	
	public NotesComparaison compare(EtabFiness finess,EtabSirene sirene){
		NotesComparaison notesComparaison=new NotesComparaison();	
		/*****noteEnseigne à claculer...****/
		double noteEnseigne=0.0;	
		noteEnseigne=algorithme.calculateNoteEnseigne(finess.getNom(), sirene.getNom());
		notesComparaison.setNoteEnseigne(noteEnseigne);	
		return notesComparaison;
	}
	//setters...	
	public void setAlgorithme(IAlgorithme algorithme) {
		this.algorithme = algorithme;
	}
	//inner class
	private class Algorithme extends AbstractAlgorithme{	
	}
}

Avant de présenter le client, voici le fichier de configuration spring qui va être utilisé:
/**** spring.xml****/

<beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
		xmlns:p="http://www.springframework.org/schema/p" xmlns:context="http://www.springframework.org/schema/context"
		xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
		http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-2.5.xsd"
		>
<bean id="finess1" class="fr.netapsys.designpatterns.entites.EtabFiness">
	<property name="nom" value="SARL AMBULANCE TAXI PARIS"/>
	<property name="codeCategorie" value="100"/>
</bean> 
<bean id="sirene1" class="fr.netapsys.designpatterns.entites.EtabSirene">
	<property name="nom" value="SARL TRANSPORT AMBULANCE PARIS"/>
	<property name="type" value="1"/>
</bean>
</beans>

/****************** Main client**************/

public class Main {
final private static Logger logger=Logger.getLogger("fr.netapsys.designpatterns.main.Main.class");
	public static void main(String[] args) {
		/* point d entree de spring: déclarer dans le fichier spring.xml le bean */  
		ApplicationContext ctx=(ApplicationContext)
					new ClassPathXmlApplicationContext(new String[]{"resources/spring.xml"});
		//Exemple de finess structure ...
		EtabFiness finess1 = defineExempleEtabFiness(ctx);		
		//exemple de sirene structure ...**************************
		EtabSirene sirene1 = defineExempleEtabSirene(ctx);
		/********************** TEST 1: Comparaison par defaut (cad algorithme par defaut qui opere) ***************/	
		IComparaison comparaison=new Comparaison();
		NotesComparaison notesComparaison=comparaison.compare(finess1, sirene1);
		logger.info("Résultat de comparaison par defaut de\n"+finess1+"\net de\n"+sirene1 +
				"\n\n-->NOTES:"+notesComparaison+"\n"  );
		/********************** TEST 2: attache un algorithme concret à la comparaison ***************/		
		//definir algo de la comparaison 
		IAlgorithme algorithme = defineConcreteAlgorithme();
		//attacher cet algo à Comparaison
		//comparaison=new Comparaison(algorithme);
		comparaison.setAlgorithme(algorithme);
		notesComparaison=comparaison.compare(finess1, sirene1);
		logger.info("Resultat de comparaison avec algorithme concret de\n"+finess1+"\net de\n"+sirene1 +
				"\n\n-->NOTES:"+notesComparaison  );
	}
	private static IAlgorithme defineConcreteAlgorithme() {
		IAlgorithme algorithme=new ConcreteAlgorithme();
	   return algorithme;
	}	
	private static EtabSirene defineExempleEtabSirene(ApplicationContext ctx) {
			return (EtabSirene)ctx.getBean("sirene1");
	}
	private static EtabFiness defineExempleEtabFiness(ApplicationContext ctx) {
		 return (EtabFiness)ctx.getBean("finess1");
	}
}

L'exécution de la classe Main produit la sortie suivante:

INFO  ( Main.java:54) Résultat de comparaison par defaut de
Finess:Nom:SARL AMBULANCE TAXI PARIS	CodeCategorie=100
et de
Sirene:Nom:SARL TRANSPORT AMBULANCE PARIS	Type=1
-->NOTES:noteEnseigne=0.0
 INFO  ( Main.java:64) Resultat de comparaison avec algorithme concret de
Finess:Nom:SARL AMBULANCE TAXI PARIS	CodeCategorie=100
et de
Sirene:Nom:SARL TRANSPORT AMBULANCE PARIS	Type=1
-->NOTES:noteEnseigne=75.0

Voilà, ça fait beaucoup de lignes de codes mais le résultat est intéressant puisque changer/redéfinir l'algorithme est dynamique.
Vous pouvez en ajouter/définir un autre adapté aux nouvelles règles métier sans modifier la classe Comparaison.

Pratiquer le design-pattern Observer en 15 min

Abderrazek CHINE — Tue, 18 Aug 2009 20:10:00 +0200

Les design-pattern (ou motifs de conception) réalisent le principe de ne pas réinventer la roue en capitalisant les expériences.
En effet, un design-pattern décrit à la fois :

Les situations de conception que l'on rencontre trop souvent dans le développement de logiciels
Les solutions types (abstraites ou de haut niveau) identifiées pour ces problèmes (formelles ou non, indépendamment des langages objets)
Les bénéfices d'utiliser ces solutions dans le développement de logiciels.

Les design-pattern offrent donc une description complète des problèmes répétitifs et les solutions abstraites retenues en expliquant les conséquences à l'usage.
Cette description reste indépendante du langage objet et voire du métier développement de logiciels.
Néanmoins, notons que les design ne sont pas des briques logicielles.
Les design-pattern se divisent en trois groupes: les design de création, de structure et de comportement.
Dans ce billet, nous mettons en pratique le design-pattern "observer" faisant partie du dernier groupe.
L'exemple choisi est volontairement simpliste néanmoins il illustre bien une problématique réelle. L'exemple pratique s'appuie sur les classes/interfaces du package java.util
Le seul pré-requis est une petite dose d'abstraction.

Le design-pattern observer

Situation:

Le besoin consiste à notifier tout changement de l'état d'un objet aux objets dépendants (pour rester simple, la notification est unidirectionnelle).
Le premier objet est appelé "observable" ou observé et les objets qui dépendent se nomment "observer" ou observateurs.
Les observateurs peuvent répercuter le changement notifié de façon dynamique.
La dépendance entre objet observable et objets observateurs est également gérée dynamiquement : On peut ajouter/retirer un observateur à tout moment sans bien sûr affecter le code des classes existantes.

Solution(avec API JAVA):
La classe de l'objet "observé" doit étendre la classe "Observable" et ainsi l'objet ajoute un observateur via la méthode addObserver,
Les objets observateurs doivent implémenter l'interface Observer et par conséquent implémenter la méthode "void update(Observable obs, Object obj)",
Au moment du changement dans l'état de l'objet observé, notifier les observateurs (par exemple, sur le setter de cet attribut).
NB. Tous les détails sont données dans la partie mise en pratique ci-après.

Avantages:

Ne pas réinventer la roue,
La solution offerte par les API Java répond à la situation posée et est robuste,
Facile à mettre en place.

Mise en pratique:

Une entreprise (siège) peut avoir ou être liée à plusieurs établissements. On souhaite notifier tout changement survenu dans "Entreprise" aux objets liés, de type "Etablissement" et ajoutés comme observateurs.
Le code des classes java ci-après montre comment notifier dynamiquement tout changement dans l'objet observé aux observateurs inscrits.
On commence par écrire une classe "Entreprise" de l'objet observé. Celle-ci étend la classe Observable et doit notifier les observateurs via les deux méthodes "setChanged" et "notifyObservers" de la classe mère Observable comme le montre le code java qui suit.
Ensuite, on donne le code la classe "Etablissement" qui implémente l'interface "Observer".

//la classe Entreprise 
public class Entreprise extends Observable {
	 private int id;
	 private boolean etat;
	 public void setEtat(boolean etat){
		this.etat=etat;		
		setChanged();
		notifyObservers(this.etat);		
	 } 
	 public boolean isEtat(){ return etat;}
	//autre setters/getters ...
	public int getId() {
		return id;
	}
	public void setId(int id) {
		this.id = id;
	}
	public String toString(){
		return "Entreprise (id="+id+" etat="+etat+")";
	}
}

De l'autre côté, la classe "observateur" doit implémenter l'interface "Observer" ce qui exige de définir la méthode "void update(Observable obs, Object obj)".
C'est dans cette méthode qu'il faut indiquer le code métier qui sera exécuté à chaque modification de l'attribut surveillé de l'objet "Entreprise".
Bien évidemment, l'objet observé doit ajouter/déclarer un ou plusieurs observateur(s) pour que le processus de notification soit activé.
Dans l'exemple, à chaque fois que l'attribut "etat" change, une notification est envoyée aux observateurs "Etablissement".
A la réception de la notification, chaque observateur "Etablissemet" actualise l'attribut "infos" avec la chaîne "Notification reçu le...".
Notez que la réécriture de la méthode toString() de la classe Etablissement permet d'afficher sur la console cet objet avant et après toute modification de l'état de l'objet "Entreprise".

public class Etablissement implements Observer{
 
	private int id;
	private String infos;
	public void update(Observable obs, Object obj) {
		if(obs instanceof Entreprise){
			Calendar calendar=new GregorianCalendar(Locale.FRANCE);
			Date date=calendar.getTime();
			setInfos("Notification recu le "+new SimpleDateFormat().format(date));
		}
	}
	public int getId() {
		return id;
	}
	public void setId(int id) {
		this.id = id;
	}
	public String getInfos() {
		return infos;
	}
	public void setInfos(String infos) {
		this.infos = infos;
	}
	public String toString(){
		return "Etablissement ( id="+id+" infos :"+infos+")";
	}
}

Et on termine avec le client (Main.java) qui illustre les différentes notions expliquées:

public class Main{
 
		//définir un etablissement
		Etablissement etab=new Etablissement();
		etab.setId(1);
		etab.setInfos("RAS");
 
		//definir une entreprise
		Entreprise ent=new Entreprise();
		//Ajouter un observer	
		ent.addObserver(etab);
		System.out.print("Avant mise à jour de l'etat de l'entreprise:\n\tEtab: "+ etab);
		//Effectuer un changement sur l'attribut etat de l'entreprise
		ent.setEtat(true);	
		System.out.print("Après mise à jour de l'etat de l'entreprise:\n\tEtab: "+ etab);
}

L'exécution de ce code affiche sur la console:

Avant mise à jour de l'etat de l'entreprise:
	Etab: Etablissement ( id=1 infos :RAS)
Après mise à jour de l'etat de l'entreprise:
	Etab: Etablissement ( id=1 infos :Notification recu le 18/08/09 19:51)

Résumons les étapes nécessaires:

- La classe de l'objet observé doit étendre la classe "Observable". Elle doit également appeler les méthodes "setChanged" et "notifyObservers" sur l'attribut à surveiller.
- La classe de l'observateur doit implémenter l'interface "Observer" et par conséquent définir la méthode "void update(Observable obs, Object obj)" avec le code métier approprié.
- Enfin, dans le client ajouter à l'observable son/ses observateurs via la méthode "addObserver".

Conclusion

Vous avez entre les mains un design qui va vous faciliter certaines tâches de développement.
L'usage de l'API robuste de Java vous épargne les difficultés de coder par vous-même les notifications entre objets et la gestion de multithread liée.
Vous pourriez dire qu'avec ce design les changements entre entités liées sont maitrisées avec un coût réduit.
Dans un prochain billet, je vous présente un nouveau design qui nous (vous) permettra de supporter au mieux (ne le dites pas fort!) les demandes incessantes du chef de projet (et du client) de faire changer et rechanger le code des règles métier durant le développement du projet.

Donc à la prochaine fois... pour parler de stratégie!

Spring : Merger des collections

Abderrazek CHINE — Fri, 03 Jul 2009 19:13:00 +0200

Ce billet aborde la notion de "merge" (fusion) des collections dans Spring. Cette notion, présente depuis la version Spring 2.0, repose sur l'héritage des définitions des Beans de Spring que nous expliquerons brièvement.
Les exemples donnés sont créés simplement dans un projet java sous eclipse (sans recours à maven).
Un seul pré-requis : connaître la déclaration des collections dans Spring.

Héritage des définitions beans de Spring

Je pense qu'un exemple est plus parlant qu'un long discours pour comprendre cette notion.
Nous allons donc écrire un bean simple, nommé à juste titre classeParent, puis le déclarer dans le fichier de configuration de spring.
Enfin nous déclarons, dans le fichier xml de Spring, une nouvelle (définition) du nouveau bean, nommé classeChild, qui hérite de la définition de classeParent.
Ci-après, la seule classe POJO, ClasseParent.java, déclarant trois attributs avec ses setters/getters (omis ici) :

/** classe ClasseParent**/
package ch1.container.collections;
public class ClasseParent {
	private String nom;
       private String prenom;
	private float points ;
 
	public String toString(){
		return "nom="+getNom()+ " prenom="+getPrenom()+" points:"+getPoints();
	}
//*** les getters/setters sont omis....
}

Le fichier de Spring, nommé spring_collections.xml, déclare ce(s) bean(s) :

<bean id="classe1Parent" class="ch1.container.collections.ClasseParent">
	<property name="nom">
		 <value>CHINE</value>
	</property>
       <property name="prenom">
		 <value>Abderazek</value>
	</property>
	<property name="points">
		<value type="float">200</value>
	</property>
</bean>

Nous ajoutons à ce fichier xml, les lignes ci-après afin de déclarer un bean fils, avec id="classe1Child" qui hérite de toutes les propriétés de la définition du bean classe1Parent.
Notez que :

<!-- classe fille -->	
<bean id="classe1Child" parent="classe1Parent">		
 
       <property name="prenom">
		 <value>Anessem</value>
	</property>
 
	<property name="points">
		<value type="float">800</value>
	</property>
</bean>

Nous venons de voir que le bean classe1Child hérite de l'attribut "nom" et surcharge les attributs "prenom" et "points".
Évidemment, l'intérêt de tout cela saute aux yeux.
Enfin, écrivons la classe TheMain, de test.

package ch1.container;
public class TheMain {
	private static Logger logger=Logger.getLogger("ch1.container.TheMain");
public static void main(String[] args) {
/** point d entree de spring : récupérer dans le fichier xml le bean**/  
 ApplicationContext ctx=(ApplicationContext) new ClassPathXmlApplicationContext(new String[]{"resources/spring_collections.xml"});
  ClasseParent classeParent=(ClasseParent) ctx.getBean("classe1");
 logger.info(">>classeParent:"+classeParent);
 ClasseParent classeChild=(ClasseParent) ctx.getBean("classe1Child");
 logger.info(">>classeChild:"+classeChild);
}

Assurez-vous d'avoir dans le classpath les trois jars suivants : spring-2.5.x.jar; log4j-1.2.x.jar et commons-loggings-1.1.x.jar.
Exécutez la classe sous eclipse (ou encore sous dos). Vous obtenez à peu près ces lignes (extraits) :

INFO: >>classeParent:nom=CHNE prenom=Abderazek points:200.0
** juin 2009 **** ch1.container.TheMain main
INFO: ==classeChild>>nom=CHINE prenom=Anesssem points:800.0

Merger les collections dans Spring

Dans cette seconde partie, nous écrivons une nouvelle classe java que l'on nommera ClazzParent avec ces lignes de code :

package ch1.container.collections;
 
import java.util.Map;
 
public class ClazzParent {
 
	private Map<String,String> proprietes;
	private Map<String,Float> anotherMap;
	//** setters/getters omis...
	public String toString(){
		return getProprietes().toString()+"\n"+getAnotherMap();
	}
}

Et le fichier spring_collections.xml doit comporter la déclaration du bean clazzParent comme suit :

<beans xmlns="http://www.springframework.org/schema/beans"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:p="http://www.springframework.org/schema/p"
	xmlns:context="http://www.springframework.org/schema/context"
	xmlns:util="http://www.springframework.org/schema/util"
	xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
		http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-2.5.xsd
		http://www.springframework.org/schema/util http://www.springframework.org/schema/util/spring-util-2.5.xsd">
<!-- partie merging collections -->
	<bean id="clazzParent" class="ch1.container.collections.ClazzParent">
		<property name="proprietes">
			<props>
				<prop key="administrator">administrator@example.com</prop>
				<prop key="support">support@example.com</prop>
			</props>
		</property>		
		<property name="anotherMap" ref="chiffresMap" />
	</bean>	
	<!--  child from clazzParent with merging map/properies/list/set -->
	<bean id="clazzChild" parent="clazzParent"> <!--  note parent= -->
		<property name="proprietes">
			<props merge="true"> <!--  note merge=true -->
				<prop key="adjointAdmin">admin2@example.com</prop> <!--  new property -->
				<prop key="support">sav@example.com</prop>         <!-- surcharge valeur existante -->
			</props>
		</property>
		<property name="anotherMap" ref="chiffresMap2"/>           <!-- override	-->
	</bean>
	<util:map id="chiffresMap">
		<entry key="chiffre1" value="22.35" />
		<entry key="chiffre2" value="120.20" />
	</util:map>
	<util:map id="chiffresMap2">
		<entry key="chiffre1" value="2299.95" />
		<entry key="chiffre2" value="1299.99" />
	</util:map>
 
</beans>

Il n'y a pas grand chose à expliquer puisque les commentaires insérés sont explicites!
La classe "clazzChild", ayant comme parent "ClazzParent", et ses attributs de type collections sont "mergés" car l'attribut de la propriété "merge" est positionné à "true".
On peut surcharger les valeurs comme expliqué dans le code xml.

Reste à écrire une classe "TheMain.java" permettant de tester ces fusions et surcharges :

public class TheMain {
 
	private static Logger logger=Logger.getLogger("ch1.container.TheMain");
	/**
	 * @param args
	 */
	public static void main(String[] args) {
		/** point d entree de spring: déclarer dans le fichier spring.xml le bean**/  
		ApplicationContext ctx=(ApplicationContext)  new ClassPathXmlApplicationContext(new String[]{"resources/spring_all.xml"});
 
                ClazzParent clazzParent=(ClazzParent) ctx.getBean("clazzParent");
                logger.info(">>clazzParent: "+clazzParent);
		ClazzParent clazzChild=(ClazzParent) ctx.getBean("clazzChild");
                logger.info(">>>>child: "+clazzChild);
	}
}

L'exécution de TheMain affiche ceci :

** juin 2009 *** ch1.container.TheMain main
INFO: >>clazzParent: {support=support@example.com, administrator=administrator@example.com}
{chiffre1=22.35, chiffre2=120.2}
** juin 2009 *** ch1.container.TheMain main
INFO: >>>>child: {support=sav@example.com, adjointAdmin=admin2@example.com, administrator=administrator@example.com}
{chiffre1=2299.95, chiffre2=1299.99}

Script Shell : Formater des chaînes à l'intérieur des scripts

Abderrazek CHINE — Tue, 23 Jun 2009 18:29:00 +0200

Dans le cadre de mes activités, j'ai écrit des scripts Shell ayant pour but de formater des chaînes de caractères à l'intérieur du script, je vous propose de les partager avec vous tout en introduisant des fonctions afin de vous faciliter la prise en main et la réutilisation.
N'étant pas expert du script Shell, tout commentaire est le bienvenu.
Les exemples de scripts donnés ci-après sont testés sous linux et hp-ux.
Le premier exemple étant simple, il prépare le second qui traite du formatage des chaînes. Ceux qui sont pressés peuvent juste jeter un œil sur la seconde partie de ce billet.

Fonction de lecture des arguments passés

Le premier script nommé tst1.sh a deux fonctions simples qui serviront à :

 - Valider le nombre d'arguments attendus par le script. 
 - Afficher ces arguments

Son contenu est comme suit:

#!/bin/sh
scriptName=$(basename $0)
syntaxe=" $scriptName  value \nExemple:\n  $scriptName MY_VAL"
nb_args_needed=1
# ----------------- DECLARER LES FONCTIONS ----------------------------
# declarer une fonction
validateNumberArg()
{ 
 if [ "$#" -lt $nb_args_needed ]
 then
   echo "Erreur: Arguments absents ou le nombre argument \"$#\" est insuffisant \nSyntaxe:\n $syntaxe" 
   exit 1
fi
}
# declarer une fonction affichage arguments
displayArguments() 
{
  echo "Nombres de paramètres : $#"
  for u in $@
	do
	  echo "$u"
	done
}
# ------- FIN DECLARATION DES FONCTIONS --------------------------
# ***********************  ****************   *********************************
# ***********************   Debut du script   *********************************
# *********************** ******************* *********************************
 
validateNumberArg $@
displayArguments $@

Le script peut être exécuté par:

./tst1.sh MAVALEUR

Ce script analyse le nombre d'arguments qui lui sont passés et s'il y en a moins de 2 il affiche la syntaxe d'utilisation et se termine.

Nous allons améliorer ce premier script afin de préciser davantage le format des arguments attendus et par conséquent mieux les récupérer.

#!/bin/sh
scriptName=$(basename $0)
syntaxe=" $scriptName  -a value \nExemple:\n  $scriptName  -a MAVALEUR"
nb_args_needed=2
# déclaration dune fonction exemple
displayArguments() 
{
	  echo "Nombres de paramètres : $#"
	  for u in $@
		do
		  echo "$u"
		done
}
# déclaration d'une fonction
validateNumberArg()
{ 
	if [ "$#" -lt $nb_args_needed ]
	then
	   echo "Erreur: Arguments absents ou le nombre argument \"$#\" est insuffisant \nSyntaxe:\n $syntaxe" 
	   exit 1
	fi
}
# lectureArguments necessite une variable Globale
export MONARGUMENT="" 
lectureArguments()
{
while getopts "a:" OPTION 
do
	case $OPTION in
 
		a) MONARGUMENT=$OPTARG  ;;
		:) echo "*** OPTION \"$OPTARG\" sans arg"
		   exit 1 ;;
		\?) echo "*** OPTION \"$OPTARG\" inconnue !!!"
		    exit 1 ;;
	esac
done
}	
# ***********************--- End Functions ---**************************
# Controler le nombre d arguments passes au script 
validateNumberArg $@
 
# Call function lectureArguments
lectureArguments $@
echo "monArgument: $MONARGUMENT "

Fonction de formatage des chaînes

Cette seconde partie présente un script permettant de formater les chaînes de caractères à l'intérieur du script.
Ce point est mal documenté sur le web à moins de recourir aux fonctionnalités awk, sed,..

La technique utilisée ici repose sur la redéfinition du séparateur IFS à traiter avec beaucoup de précaution.

C'est pour vous éviter des effets de bord que nous indiquons comment sauvegarder la valeur initiale d'IFS afin de la remettre en place aussitôt.

Ci-après quelques fonctions élémentaires qui permettent de réaliser des substitutions puis de formater la chaîne de la manière suivante: Nous récupérons la valeur de l'argument du script qui peut être une liste de codes départements séparée par une virgule. Pour fixer les idées, on suppose que le script est lancé avec la ligne suivante:

./tst2.sh -a 75,76,89

Nous formatons dons la liste passée en argument pour obtenir ceci :

SELECT * FROM REGION WHERE idDpt IN ('75','76','89')

La seule difficulté est de formater dynamiquement la liste passée en argument.
Commençons notre script, nommé tst2.sh, par déclarer deux variables globales comme suit:

# déclarer une variable globale qui récupère la valeur de l'argument
export argListeDpts=""
# Et une autre pour la sortie formatée
export listeDpts=" SELECT * FROM REGION WHERE idDpt IN ("

Pour cela, ajouter la première fonction nommée substrLastChar qui permet de substituer le dernier caractère par une parenthèse fermante par la suite:

substrlastChar()
{
phrase=$1
position=`expr ${#phrase} - 1 `
listeDpts=`expr substr $phrase 1 $position `
}

Puis la seconde fonction qui formate comme attendu la liste passée en argument:

splitterPhrase()
{
 phrase=$1;OLDIFS=$IFS; IFS="\,"; for u in $phrase ; do listeDpts="$listeDpts'$u',"; done; IFS=$OLDIFS;
 substrLastChar
 listeDpts=$listeDpts")"
}

Il reste à adapter la fonction lectureArgs afin de récupérer la valeur de l'argument dans la variable globale listeDpts.

lectureArgs()
{
 while getopts "a:h" OPTION
 do
   case $OPTION in
    h) echo "help syntaxe="; exit 0;;
	a) argListeDpts=$OPTARG;;
	:) echo " option sans arg";exit 1;;
	\?) echo "option inconnue";exit 1;;
   esac
 done
}

Enfin, le script proprement parlant contient ces lignes:

lectureArgs $@
 splitterPhrase $argListeDpts
 echo "resultat=$listeDpts"

L'exécution de ce script avec par exemple l'argument suivant:

./tst2.sh -a 75,76,79,99

renvoie à l'écran la sortie suivante :
resultat= SELECT * FROM REGION WHERE idDpt IN ('75','76','79','99')

Conclusion
Il y a certainement plusieurs façons d'arriver à ce ce résultat (utilisation de awk, sed,..), mais ce billet donne avec détails quelques éléments qui vous permettent d'être en mesure d'automatiser certaines tâches lors du déploiement d'applications sur des plateformes linux ou hp-ux. N'étant pas expert du script Shell, vos remarques sont les bienvenues. Enfin, il faut bien faire attention aux fameuses erreurs de manipulation des chaînes.