Netapsys Blog

L'apport du framework Spring

Abderrazek CHINE — Mon, 23 Jan 2012 08:00:00 +0100

L'objet de ce billet est d'expliciter l'apport du framework Spring dans nos développements.
Les concepts de Spring IoC sont présentés accompagnés d'exemple pratique.
L'idée est de partir des critères qualifiant un code de "mauvais" puis d'indiquer les moyens de le corriger ou le contourner.
On s’appuie sur le framework Spring pour améliorer le code et ceci de manière non intrusive.

Le concept central dans le framework Spring est:
"le cycle de vie d'un composant, son assemblage et la gestion de ses dépendances doivent se faire en dehors du composant lui-même"
Il découle que le code de "plomberie" pour gérer les instances de classes (beans) ne sont plus à faire par le développeur.
Une connaissance sommaire de Spring facilite la lecture de ce billet.
Dans l'exemple pratique de ce billet, on recourt aux annotations pour l'injection des dépendances entre les instances de classes (beans).

Question: Quels sont les critères d'un mauvais code?
De manière conceptuelle, les critères d'un mauvais code (ou mauvaise conception) sont au nombre de trois (retenons R.F.I ):

1- Un code Rigide

2- Un code Fragile

3- Un code Immobile

Un code rigide est un code qui est difficile de modifier car toute modification impacte toutes les parties (couches) de l'application.
Un code fragile c'est un code où la simple modification d'une partie (couche) de l'application a pour conséquence de casser d'autres parties (couches) .
Un code Immobile c'est un code non réutilisable ailleurs car il est tellement lié à l'application.
Voici un premier code simple mettant en évidence la présence de l'un de ces trois critères (RFI):

 
/*classe dao*/
2. public class Dao implements IDao{
3.   public String getInfo(){
    //.... code 
4.    return "dao"
    }

/*interface IService*/
5. public interface IService { getInfo();}

/*classe Service*/
6. public class Service implements IService{
7.    private Dao dao;
8.    public String getInfo(){
9.     return dao.getInfo();
       }
       //... etc     
}

A la ligne 7 la couche service dépend d'un détail d'implémentation car son attribut 'dao' pointe sur la classe d'implémentation. Ce qui rend le code rigide et fragile.

Pour contourner ceci, dans la classe Service, l'attribut doit pointer sur l'interface IDao à créer. Mais c'est insuffisant car à un moment ou un autre l'attribut 'dao' doit être instancié dans le service.
Or l'opérateur 'new' d'instanciation doit porter sur une implémentation. Ainsi, le service est toujours lié au détail d'implémentation.
Nous souhaitons que la couche service n'a aucune référence sur les implémentations.

Pour corriger ces facteurs, deux principes sont à respecter (principes de dépendances ):

P1. Les modules de haut niveau ne devrait pas dépendre de modules de bas niveau, les deux doivent dépendre des couches abstraites
P2. Les parties abstraites ne devraient pas dépendre des détails (d'implémentation), ces détails doivent dépendre uniquement des abstractions.

Spring avec le concept IoC va nous permettre de contourner complètement les facteurs RFI.
Nous allons procéder à la mise en place en reprenant l'exemple précédent.

 
/*interface IDao*/
public interface IDao{ String getInfo();}

/*classe dao*/
@Repository
public class Dao implements IDao{
public String getInfo(){
    //.... code 
      return "<dao/>"
 }
/*interface IService*/
public interface IService { getInfo();}

/*classe Service*/
@Service
public class Service implements IService{
     @Autowired
     private IDao dao; /**** ligne modifiée ****/
     public String getInfo(){
       return dao.getInfo();
    }     
}

Notez la présences des annotations @Repository et @Service de Spring ajoutées dans les classes d'implémentation.
L'autre modification consiste à injecter, via l'annotation @Autowired de Spring, une instance de 'dao'.
Toutes ces annotations servent à configurer Spring. On peut bien évidemment obtenir le même résultat par de la configuration XML. Par conséquence, la classe de détail Service ne dépend que de l'interface IDao.
Ainsi, nous obtenons une classe testable sans connaitre les détails d'implémentation.
On peut, par exemple, la tester juste avec un bouchon (mock) de la classe Dao.
En résumé, le couplage entre la couche service et celle de dao est faible.
Le framework Spring sera configuré afin de gérer les beans, les dépendances entre les beans et leur cycle de vie.
La figure suivante illustre cela
Pour ce faire, voici le fichier de configuration de spring qui vient en complément des annotations précédentes:

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

Bien sûr, le fichier est maigre et il le restera surtout que l'on utilise que les annotations.
la ligne context:component-scan précise les packages où Spring doit chercher les beans à injecter.
Mais cela n'est pas suffisant comme nous le verrons ci-après.

Question: Que signifie un bean?
C'est une instance de classe simple (POJO) managée par Spring. C'est à dire, une classe instanciée et assemblée par Spring,

Question: A ce stade et juste en lisant le fichier de configuration de spring, quels sont les (nos) beans managés par Spring?
Il y a deux beans : 'dao' et 'service' puisque les deux classes sont correctement annotées (@Repository et @Service)
et surtout que les deux classes se trouvent dans le package du base-package du scan: 'fr.netapsys.tb'.

Attention, l'absence d'annotation appropriée sur une classe ou lorsque le base-package du scan n'englobe pas cette classe produisent une exception générée par Spring.

Enfin, voici les étapes de crétaion dans eclipse d'un projet simple permettant de pratiquer les concepts évoqués:

1- Créer un projet java standard (java 5 ou +)

2- Ajouter les jars suivants:

commons-logging,log4j,spring-beans,spring-core,spring-context

3- Ajouter au projet les packages:

    fr.netapsys.tb.dao,  fr.netapsys.tb.services

4- Ajouter le fichier Spring

  Nommez-le spring-context.xml. Il contient donc une ligne:
  
  <context:component-scan base-package="fr.netapsys.tb "/>

5- Ajouter l'interface IDao et son implémentation Dao:

  L'interface déclare l'unique méthode: String getInfo(); 

  L'implémentation ne fait que retourner la chaîne "<dao/>". 

  Ces deux classes sont dans le package fr.netapsys.tb.dao

6- Ajouter la classe IMyService et son implémentation MyService:

  L'interface IMyService déclare une méthode : String info();

  MyService a un attribut de type IDao :

   public class MyService implements IMyService{
     private IDao dao;
    public String info(){ return dao.getInfos() ;}
 }

@Service
   public class MyService implements IMyService{
     @Resource private IDao dao;
    public String info(){ return dao.getInfos() ;}
 }

7. Vérifier que vous annotez bien les classes Dao et Service. Sans ces annotations, Spring ne pourra pas voir ces beans dans le package de scan

8- Pour tester, ajoutez une classe Main puis insérez ces deux lignes dans sa méthode statique main :

ApplicationContext appCtx= new ClassPathXmlApplicationContext("spring-context.xml");

IMyService service=(IMyService) appCtx.getBean("myService");

La classe Main est dans le package fr.netapsys.tb.client

Voilà, vous avez donc tous les éléments pour tester par vous même l'intégration de spring et surtout découvrir son réel apport.

Dans la seconde partie de ce billet nous répondons à :

- Que doit-on utiliser BeanFactory ou ApplicationContext?

- Que doit-on préféter les annotations ou la configuration par XML?

Eclipse: Rafraîchir automatiquement (Refresh automatically)

Abderrazek CHINE — Thu, 05 Jan 2012 13:54:00 +0100

On répond ici à la question, que tout développeur utilisant L'IDE Eclipse, aurait posé au moins une fois :
Peut-on rafraichir automatiquement sans incessamment appuyer sur la touche "F5" ou passer par le menu?
La réponse est oui.
Voici les détails.

Dans Eclipse ( à partir de version 3.7) et c'est vrai aussi pour STS (Springsource Tool Suite) choisir dans le menu:

Window -> Préférences -> Général -> Workspace --> Cocher les cases de Refresh.

La figure suivante pour Eclipse indigo:

La figure ci-après est une illustration pour STS :

Enjoy,

Les Web Servlet Filters et le cryptage -1ère partie

Abderrazek CHINE — Fri, 19 Aug 2011 20:08:00 +0200

L'objectif du billet est d'expliquer par des exemples concrets la notion de « Filter » (ou Web Filter, en français Filtre).
Pour vraiment comprendre la notion de « Servlet Filter » il faudrait les voir en action sur des exemples réels.
C'est justement ce que nous présentons ci-dessous.
La première partie de ce billet monte une démo simple mais très utile car elle détaille la création d'une « Servlet Filter » qui transforme la requête HTTP POST en simulant le cryptage du mot de passe.

Aucun pré-requis n'est exigé pour cette partie.

Dans la seconde partie, la démo s'intéresse à l'intégration du « Filter » à une application Web existante basée sur spring-security 2.x. Plus précisément, la « Servlet Filter » agit sur les « Filtres » de spring-security.
Cette seconde partie, d'un niveau très avancé, est réservée à ceux connaissant parfaitement spring et spring-security.
Ce qui est commun entre les deux parties est que nous partons d'une application Web existante et nous ajoutons les transformations utiles avec le filtre sans modifier le code java/jsp. Seul le fichier descripteur « web.xml » sera mis à jour.
NOTE. Les dépendances nécessaires seront indiquées.

Commençons par répondre aux questions fondamentales suivantes.

Question1. C'est quoi une servlet Filter?

Les spécifications Servlet v2.3 introduit un nouvel composant nommé «Servlet Filter» qui permet d'intercepter dynamiquement les requêtes et les réponses des méthodes HTTP Get/Post afin de les transformer (pré ou post-traitement). La servlet «Filter» diffère d'une servlet standard car elle ne produit pas de réponse à une requête.

NOTA. L'interception d'un flux (stream ouvert) lié à une requête/réponse n'est pas chose aisée pour des raisons, entre autres, de sécurité. L'encapsulation des objet de type ServletRequest garantit que les paramètres de la requête ne seront pas altérés. C'est pourquoi des règles strictes sont à observer. Le seul moyen de transformer la requête (ou la réponse) est d'envelopper (d'emballer) la requête/réponse interceptée dans une nouvelle classe «Wrapper» qui hérite de HttpServletRequestWrapper ou de HttpServletResponseWrapper.

Définition du filter extraite du site Oracle: The Java Servlet specification version 2.3 introduces a new component type, called a filter. A filter dynamically intercepts requests and responses to transform or use the information contained in the requests or responses. Filters typically do not themselves create responses, but instead provide universal functions that can be "attached" to any type of servlet or JSP page.

Question2. Comment écrire un nouveau Filter?

La «servlet Filter» doit implémenter l'interface javax.servlet.Filter qui déclare trois méthodes permettant de greffer les transformations. Ces méthodes (toutes void) sont :

doFilter(HttpServletRequest rq,HttpServletResponse rp,FilterChain ch)
throws ServletException,IOException;

init(FilterConfig fConfig) throws ServletException;

destroy();

La méthode principale est «doFilter». Elle centralise le code des transformations voulues, et c'est ici que le chaînage doit être réalisé avec l'appel suivant ch.doFilter(req,rep) ce qui permet de passer la main aux autres Filtres jusqu'à la servlet ou la jsp finale.

Passons à la pratique.

Développons d'abord un exemple simple et pratique.

Mais avant, préparons ensemble l'environnement en commençant par le projet Web (existant) avant de lui rajouter le Filter.

1- Créer sous eclipse, un projet «Dynamic Web Project» nommé «demo1». Indiquer « Tomcat » comme serveur conteneur servlet.

2- Créer une servlet nommée MyServlet dont le code se résume à:

 [java]
	final String NAME="j_username";
	final String PWD="j_password";
    	public MyServlet() {
        super();
    	}
	protected void doGet(HttpServletRequest req, HttpServletResponse resp) 
	throws ServletException, IOException {
		doPost(req, resp);
				
	}
	protected void doPost(HttpServletRequest req,HttpServletResponse resp) 
	throws ServletException, IOException {
		String nom=req.getParameter(NAME);
		String pwd=req.getParameter(PWD);
		
		PrintWriter pwriter=resp.getWriter();
		pwriter.println("<h1>nom="+nom+", pwd="+pwd);
		
	}

La page jsp nommé «login.jsp» qui contient le formulaire de saisie du couple nom/password. Le code jsp est :

 [jsp]
   <html>
   <body>
   <form action="MyServlet" method="post">
   <label>Nom : </label><input id="j_username" name="j_username" value="TOTO"/>
   <label>Identifiant : </label><input type="password" id="j_password"  
    name="j_password" value="TOTOLEVRAI"/>
   <input type="submit" value="ok">
   </form>
   </body></html>

Notez l'action du formulaire (balise <form>) est MyServlet. Et les deux champs de saisie sont nommés respectivement 'j_username' et 'j_password'.

Testons que tout fonctionne bien en saisissant dans le navigateur l'Url :
http://localhost:8080/demo1/login.jsp.

Saisir le nom 'toto' et son password 'TOTOLEVRAI' et MyServlet affiche ceci : nom=toto, pwd=TOTOLEVRAI

Voici donc l'application Web existante.

Elle est bien simple et le contenu de son descripteur « web.xml » est, pour l'instant, bien maigre :

 [xml]
   <servlet>
    <description></description>
    <display-name>MyServlet</display-name>
    <servlet-name>MyServlet</servlet-name>
    <servlet-class>[NOM_PACKAGE].MyServlet</servlet-class>
   </servlet>
   <servlet-mapping>
    <servlet-name>MyServlet</servlet-name>
    <url-pattern>/MyServlet</url-pattern>
   </servlet-mapping>
    <welcome-file-list>
    <welcome-file>index.jsp</welcome-file>
   </welcome-file-list>

Attention, il faudrait compléter ce fichier avec le nom de votre package de MyServlet ci-dessus.

Pour la suite, supposons que notre client exige de ne pas afficher ni stocker en clair les mots de passe.

Évidemment c'est ici le «Filter» entre en jeu.

Ecrivons une classe Servlet Filter, nommée MyFilter. Celle-ci va s'appuyer sur une autre, nommée MyRequestWrapper qui hérite de HttpServletRequestWrapper et qui permet d'envelopper la requête en entrée et lui greffer les transformations utiles.

L'idée intéressante est que, dans MyRequestWrapper, la méthode String getParameter (String param) définie dans la classe mère est surchargée.
Le décorateur assure ainsi que l'application Web existante continue à fonctionner correctement alors que la valeur du paramètre "j_pasword" a été transformé.
En principe, d'autres méthodes sont à surcharger mais pour notre démo cela est suffisant.

La création de ce «Filter» se fait en trois étapes :

Étape 1. Écrire la classe enveloppe MyRequestWrapper.java :

 [java]
public class MyRequestWrapper extends HttpServletRequestWrapper {

	public MyRequestWrapper(HttpServletRequest request) {
		super(request);
	}
	//surcharger la méthode getParameter
	public String getParameter(String param){
		if(param.equals("j_password")){
			return "Xyuty/Rcryptedendur!=";
		}else{
			return super.getParameter(param);
            }
	}
  }

Étape 2. Écrire la classe Filter nommé «MyFilter» dont voici son contenu :

 [java]
 import java.io.IOException;
 import javax.servlet.*;

 public class MyFilter implements Filter {

   private FilterConfig fConfig;
   public MyFilter() {
        super();
    }
   public void doFilter(ServletRequest req,ServletResponse resp,FilterChain ch) 
   throws IOException, ServletException {
	String pwd=(String) request. getParameter("j_password");
	if (req instanceof HttpServletRequest && pwd!=null ){
	  MyRequestWrapper requestWrapper=new 
	  MyRequestWrapper((HttpServletRequest)req);
	  ch.doFilter(requestWrapper, resp);
	}else{
	   // pass the request along the filter chain
	   ch.doFilter(request, response);
	 }
	}
	public void init(FilterConfig fConfig) throws ServletException {
		this.fConfig=fConfig;
	}
	public void destroy() {fConfig=null;}
 }

Étape 3. Compléter le fichier «web.xml» afin d'ajouter la déclaration du Filter comme suit :

<filter>
  <filter-name>myFilter</filter-name>
   <filter-class>[NOM_PACKAGE].MyFilter</filter-class>
  </filter>
  <filter-mapping>
   <filter-name>myFilter</filter-name>
   <url-pattern>/*</url-pattern>
  </filter-mapping>

Adaptez ce fichier avec le nom de votre package et relancer l'Url précédente dans le navigateur, le résultat affiché est :

nom=toto, pwd=Xyuty/Rcryptedendur!=

Voilà la première démo est terminée. Les étapes nécessaires de création d'une «Servlet Filter» permettant d'effectuer des transformations du flux de la requête sont explicitées.

Donc, nous avons simulé le cryptage du mot de passe avec une chaîne écrite en dur. Nous aurions dû appeler une méthode qui effectue réellement le cryptage. C'est ce que nous ferons dans la seconde partie.

Le duo Spring et Scala en 20 minutes

Abderrazek CHINE — Fri, 24 Jun 2011 06:58:00 +0200

Réunir le duo "Scala" et "Spring" dans une démo est une belle entreprise.
Combiner le meilleur des deux rapidement est une expérience excitante!:)
A Netapsys, Spring est bien présent dans tous les projets J2EE.
Scala aura-t-il le même sort? Ce qui est sûr, Scala a tous les atouts pour.

Sur le net, bien que ce sujet est peu abordé mais vous trouvez ici un article intéressant sur ce thème.
Ce billet vous présente une démo qui montre comment, en 20 minutes, réaliser cette expérience (magique :)).

La démo reprend l'exemple d'envoi de mail (voir ici) que je recommande sa lecture :).

Passons aux choses pratiques...

Prérequis:
Ajouter au projet scala créé sous eclipse les dépendances :

spring-2.5.6.jar, spring-test-2.5.6.jar,  jsr250-api-1.0.jar, 

mail-1.2.4.jar, activation-1.1.jar, 

Junit-4.4.jar, commons-loggings-1.1.1.jar.

NOTE. Les numéros de versions sont données à titre indicative.
Je recommande JUnit-4.4 afin d'éviter un bug connu dans la suivante.

ACTE 1: Fichier de Spring

Créer un fichier xml et placer le dans le répertoire src.
Ce fichier ne contient qu'une seule déclaration du bean JavaMailSender de l'API Spring.

 
<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">
	
 <context:component-scan base-package=
    "fr.netapsys.blog.simulatemail" />	
 <bean id="javaMailSender" 
  class="org.springframework.mail.javamail.JavaMailSenderImpl">
   <property name="host" value="localhost" />
 </bean>
</beans>

ACTE 2: Un trait IMailSender

Le code scala du trait (interface) est:

 
package fr.netapsys.blog.springmail
trait IMailSender {
  def send(to:String,from:String,body:String)
  def send(to:String,from:String,subject:String,body:String)
}

Rien à dire de particulier. un trait bien ordinaire!.

ACTE 3: Une classe MailSender

MailSender est la seule classe (service) scala qui gère l'envoi de mail.
Elle étend le trait "IMailSender"
Elle s'appuie sur l'API Spring org.springframework.mail.javamail.Spring JavaMailSender.
Voici le contenu de MailSender.scala:

 
package fr.netapsys.blog.springmail
import javax.mail.internet.MimeMessage
import org.springframework.mail.javamail._
import org.springframework.stereotype.Service
import javax.annotation.Resource
@Service("mailSender")
class MailSender  extends IMailSender {
var javaMailSender:JavaMailSender=null
def send(to: String, from: String,subject:String, body: String){
    javaMailSender.send( 
       new MimeMessagePreparator() {
	 override def prepare( mimeMessage:MimeMessage) {
	  val helper = new MimeMessageHelper(mimeMessage, false)
	  helper.setTo(to); helper.setFrom(from)
	  helper.setSubject("NO SUBJECT!!")
	  if(subject!=null) helper.setSubject(subject)
	  helper.setText(body, true)
	}		
    }
 )
}

 def send(to: String, from: String, body: String)=
                 send(to,from,null,body)
  
 @Resource
 def setJavaMailSender(jMailSender:JavaMailSender) {
  this.javaMailSender = jMailSender;
 }
}

Comme en java, voir billet, la méthode send de JavaMailSender prend en argument
l'interface MimeMessagePreparator ayant une seule méthode nommée
prepare surchargée dans ce code.
Ce qui explique la présence du terme réservé "override" devant def prepare.
L'annotation de Spring @Service permet d'injecter ce service comme nous le verrons
dans la classe object "Main" ci-après.
Le setter annoté avec @Resource permet d'injecter la variable JavaMailSender.

ACTE 4: Une classe Main avec simulation de l'envoi

 
package fr.netapsys.blog.springmail
import javax.annotation.Resource
import org.springframework.mail.javamail._
import org.springframework.context.support._
import org.springframework.context.ApplicationContext

object Main extends App{
//init Spring AppContext
val ctx:ApplicationContext = new 
    ClassPathXmlApplicationContext("spring-mail.xml")
// get the only bean from spring ctx
val mailSender:IMailSender= 
    ctx.getBean("mailSender").asInstanceOf[IMailSender]
//call method send
mailSender.send("a.c@n.fr","from@from.fr",
     "Scala and Spring form a couple of shock!")
}

Avant d'exécuter ce "Main", télécharger smtp.jar
Déposer ce jar dans un répertoire nommons-le SMTP_REP.
Dans SMTP_REP, lancer avec la console Dos, la commande "jar -java smtp.jar" et laisser la console ouverte.
Le billet détaille ce point.
Enfin, dans eclipse, clic droit sur "Main" Run as Scala Application.
Les résultats sont affichés dans la console Dos et des fichiers logs sont rajoutés dans le répertoire SMTP_REP.
C'est la fonction "send" ayant trois arguments qui est utilisée dans le "Main".
Voilà, j'ai bien dit que c'était simple mais surtout rapide.
Vous avez le meilleur de Spring et de Scala entre vos mains.

Et si on évoque les "Closures" dans scala, les "Free variable" et les 'Open Terms"?
Ah non! on va laisser tout ça à une prochaine fois disons après le bronzage de l'été:)

Langage Scala [3ème partie]

Abderrazek CHINE — Wed, 22 Jun 2011 21:56:00 +0200

Nous avons vu dans la seconde partie quelque concepts de scala qui vous ont donné l'envie de poursuivre la découverte de scala.
L'apprentissage de scala nous donne l'opportunité de redécouvrir ce que nous connaissons au quotidien: le monde java/j2ee.
Et nous encourage aussi à porter un regard critique sur le code que nous produisons.

Ce qui est sûr est que la liste des grands clients séduits par scala s'allonge: Sony, SAP, Siemens, EDF,...

Nous avons évoqué le concept "tout est fonction" dans scala, plus précisément, une fonction est un objet avec la méthode "apply".

Le plan de cette 3ème partie est comme suit:

-  Connexion JDBC,
-  Retour sur les constructeurs et les annotations

Avec ces annotations, c'est fini la galère des getters/setters (même s'ils sont générés par EDI).
Les démos sont testés avec eclipse sous windows.

Démo 1 JDBC

Le code suivant, déjà présenté dans la seconde partie, est remanié et complété avec try-finally afin de libérer les ressources jdbc.
L'url pointe sur une base informix, vous pouvez l'adapter à votre base, mysql ou toute autre base fera l'affaire.
Les éléments en majuscule dans l'url doivent être vérifiés.
Enfin, n'hésitez pas à réécrire la requête SQL simplement avec le nom correct de votre table.

package fr.netapsys.blog.jdbc
import java.sql._
object MainJdbc extends App {
	@throws(classOf[SQLException])
	def connect:Connection ={
		classOf[com.informix.jdbc.IfxDriver].newInstance
		DriverManager.getConnection(
                    "jdbc:informix-sqli://localhost:PORT/BD:informixserver=SERVER", 
                    "informix", "administrateur")
	}
        // la fonction connect affecté à l'attribut con
	var con=connect
	var rs:ResultSet=null
	var stm:Statement=null
	try{ 
		stm= con.createStatement
		rs=stm.executeQuery ("select count(*) nb from agent")
		if(rs.next) 
		 Console.println("Nb agents="+rs.getInt("nb"))
	}finally{
		if(null!=rs)rs.close
		if(null!=stm)stm.close
		if(null!=con)con.close
	}		  
}

Vous notez bien qu'une fonction nommée "connect" est affectée à une variable nommée "con".
Une fonction dans scala est un objet tout simplement. Nous illustrons ce point intéressant ci-après.
En attendant, vous constatez que MainJdbc est un object qui ne définit pas de méthode "main".
C'est la seconde façon de définir une classe "main".

Je reviendrai aussi sur les annotations afin d'en rajouter d'autres.

Démo 2 Les constructeurs et les annotations

L'exemple suivant illustre la déclaration d'un constructeur principal et avec l'annotation @BeanProperty du package scala.reflect, nous avons les getters/setters sans écrire du code (de plomberie).

package fr.netapys.blog.constructeurs
import scala.reflect.BeanProperty

class Etablissement(@BeanProperty var raisonSociale:String , @BeanProperty var id:String) {

	@Override
	override def toString():String={
		"Rs='"+getRaisonSociale() + "' id="+ getId()
	}
}

Notez que les setters/getters sont appelés dans la méthode toString surchargée ici.
Les getters/setters sont générés par scala car : - la présence de l'annotation @BeanProperty - les arguments du constructeur sont des "var" (d'où les setters générés)

Le code de la classe "object" permet de tester notre exemple volontairement simple :

object MainEtablissement extends App{
	val etab:Etablissement = new Etablissement("rs1","02A")	
	etab.setRaisonSociale("new rs")	
	println( etab )
}

Je vous laisse découvrir la sortie de la console en cliquant droit sur cette classe "MainEtablissement" puis Run as Scala Application.

Pour finir, j'aborderai prochainement le mariage heureux du duo Spring et Scala.
Ca promet.

Langage Scala [2ème partie]

Abderrazek CHINE — Tue, 21 Jun 2011 11:32:00 +0200

Nous avons vu dans la première partie une introduction de scala avec des démos de ses concepts de base.

Ces démos, j'espère, vous ont donné l'envie de découvrir ce langage fort intéressant.

Dans le passé, l'informatique a été révolutionnée avec le concept "tout est objet" et il me semble qu'un nouveau concept "tout est fonction" va marquer l'informatique de demain.

Scala tente de rapprocher ces deux concepts en donnant de la liberté aux développeurs de faire le choix

Scala impose un typage statique strict mais lève les restrictions imposées par certains concepts java. Nous y reviendrons dans la 3ème partie.

L'attrait de scala est dans le fait que les meilleures choses qui existent dans les langages récents (objet ou fonctionnel) sont désormais à portée de main.

Passons à la pratique...

Le plan de ce billet est comme suit:

- Lecture de fichier dans scala;
- Notion de traits (interface ou classe abstraite)
- Connection JDBC dans scala

Démo 1. Lecture de fichier

Ce bout de code déjà présenté dans la première partie. Nous avons vu qu'une seule ligne permet de lire le contenu d'un fichier :

  
	fromFile("nom_fichier")

Simple et rapide car pas de checked exception dans scala. N'oubliez pas de faire l'import de scala.io.Source.fromFile
Si le fichier n'existe pas il peut être judicieux de récupérer l'exception pour la traiter dans le programme.
Ceci peut se faire, avec java.io.FileNotFoundException, comme suit:

 
	try{
		  fromFile("nom_fichier")
	catch{
	    case e:FileNotFoundException => {
		logger.error(e.getMessage())
		//traitement de reprise a faire...
	    }
      }

Un point intéressant est de constater qu'en scala il y a un seul bloc try-catch. Avec le mot clé "case" on peut traiter toutes sorte d'exception dans le même bloc catch.
Un billet sera consacré au mot clé "case" prochainement.

Démo 2. Notion de trait

La notion de trait peut être considérée comme proche de l'interface ou une classe abstraite dans java. Un trait peut contenir de l'implémentation comme dans les classes abstraites java.
Mais encore une fois c'est complètement différent de java.
La notion de trait permet d'implémenter, à un dosage calculé, l'héritage multiple. Bien évidemment, les inconvénients de l'héritage multiple ne sont pas complètement levés. Avec la notion de trait, ils peuvent être contournés.

Vous dites que rien de nouveau ici mais si.

Avec les exemples ci-après, nous allons nous rendre compte de l'utilité des traits.

  * Démo 2.1 Exemple simple

Un trait se déclare avec le mot clé "trait" de scala, écrivons ces deux lignes dans un fichier IVoiture.scala.

		
	trait IVoiture {
	   def avancer():Unit
	}

La classe qui étend (extends car pas de implements dans scala) ce trait est nommée Voiture:

 
class Voiture extends IVoiture {
    val MESSAGE="Ma voiture avance..."
    override def avancer()  { 
	println(MESSAGE) 
	()  //renvoi par defaut value() qui siginifie void
    }
}

* Démo 2.2. Exemple avancé (cette partie un peu difficile est optionnelle pour la suite)

C'est un peu verbeux et long comme exemple.

Il est même inutile pour le résultat obtenu mais il permet de s'exercer sur les notions déjà vues et d'illustrer l'intérêt de la notion "trait".

Cet exemple inspiré d'un projet réel qui, en croisant de nombreux référentiels, tente de fiabiliser les données sur les activités des entreprises.

Ici, la donnée d'activité qui correspond au code Ape dans l'INSEE est comparé à un autre code d'activité du référentiel FINESS.
Le but ici est de définir trois traits et de montrer ensuite comment peut-on adapter le comportement des classes.

Le comportement de ces classes peuvent être adaptées en fonction de l'un des traits (polymorhisme sans héritage ni composition).

Je sais que ce n'est pas clair!

Écrivons quelques lignes de code puis lançons l'exécution qui nous permettra d'y revenir avec des explications claires.

# - Premier trait IReferentiel dont voici le contenu:

 
   trait IReferentiel {
	def getCodeActivite(id:String):String	
  }

# - Le second nommé IRefINSEE qui étend le précédent:

trait IRefInsee extends IReferentiel {
  abstract override def getCodeActivite(id:String): String ={
	super.getCodeActivite(id)+ " FINESS: '" + findByIdActivite(id)+""
  }
  private def findByIdActivite(id:String):String ={
   id match{
     case "8610Z" => "101"
     case _ => throw new 
         IllegalArgumentException("idActivite "+id+" not correct ")	
    }
  }
}

# - Le 3ème trait nommé IRefFiness

trait IRefFiness extends IReferentiel {
 abstract override def getCodeActivite(id:String): String = { 
   super.getCodeActivite(id)+" INSEE:'"+findByIdActivite(id)+"" 
 }
 private def findByIdActivite(id:String):String={
   id match{
    case "101" => "8610Z"
    case _ => throw new 
            IllegalArgumentException(" id="+id+" not correct ")	
   }
 }
}

Et une classe "Entreprise" du modèle dont voici le contenu:

 
class Entreprise (nom:String,identifiantActivite:String) 
extends IReferentiel {
  override def getCodeActivite(identifiantActivite:String): String = {
	   " FROM REFERENTIEL "  
}		 
override def toString():String={
   "Entreprise(nom="+nom+" idActivite="+identifiantActivite+
    " codeActivite='"+getCodeActivite(identifiantActivite)+"')"	
}  
}

Enfin, écrivons un object Main pour test:

object MainTraits {
    def main(args:Array[String]):Unit={
      val entrep:Entreprise=new 
               Entreprise("EntrepF1","125") with IRefFiness 
      println(entrep)

      val entrepInsee:Entreprise=new 
           Entreprise("EntrepSirene1","8610Z") with IRefInsee 
       println(entrepInsee)
   }
}

Vous constatez que l'attribut entrep est déclaré en ajoutant en fin de ligne "with IRefFiness" ou "with IRefInsee". Ceci déterminera le comportement de l'instance de cette classe.
Voici un aperçu des résultats que vous devriez obtenir en cliquant droit sur "MainTraits" puis Run As "scala application" :

 
Entreprise(nom=EntrepF1 idActivite=125 codeActivite=' FROM REFERENTIEL  INSEE:'8623Z')
Entreprise(nom=EntrepSirene1 idActivite=8610Z codeActivite=' FROM REFERENTIEL  FINESS: '101')

Pour finir, un bout de code scala pour se connecter à une base (ici c'est Informix car je n'en vois pas beaucoup d'exemples sur le net )

import java.sql.{SQLException,DriverManager,Statement,Connection}
import java.sql.ResultSet
object MainJdbc extends App {
 
 @throws(classOf[SQLException])
 def connect:Connection ={
     classOf[com.informix.jdbc.IfxDriver].newInstance
     DriverManager.getConnection(
       "jdbc:informix-sqli://localhost:PORT/BD:informixserver=IFX_SERVER", "U", "P")
 }	
 val con:Connection=connect 
 val stm:Statement= con.createStatement
 val rs=stm.executeQuery ("select count(*) nb from TABLE")
 var nb=0
 if(rs.next) Console.println("Nb="+rs.getInt("nb")
			  
}

Nous introduisons dans cet exemple, quelques notions intéressantes illustrant, entre autres, le concept "tout est fonction".
Vous notez bien qu'une fonction nommée "connect" est affectée à une variable nommée "con".
L'object MainJdbc ne contient pas de méthode "main".

Je vais devoir m'arrêter là, nous détaillerons ces nouveautés au prochain billet où je reviendrai sur les annotations.

A la prochaine fois.

En java, comment tester en simulant l'envoi de mail?

Abderrazek CHINE — Mon, 20 Jun 2011 21:26:00 +0200

L'objet de ce billet est de répondre à la question posée dans le titre. Précisément, en mode non connecté, comment simuler l'envoi de mail?
Ici, on ne traite pas la notion d'envoi en masse.

C'est un problème récurrent qui s'impose avant ou durant les tests/recettes des programmes java envoyant des mails (surtout en masse).
L'utilisation du serveur mail de l'entreprise (ou de gmail) peut être pénalisant surtout lorsqu'il s'agit d'envoi en masse ou encore durant les mises au point. En six actes, nous donnons la démarche accompagnée d'une démo.
La démo s'appuie sur Spring bien qu'il n'est pas nécessaire ici (mais difficile de s'en passer).

En effet avec Spring, nous écrivons beaucoup moins de plomberie de l'API mail java.
La démo est un projet Java standard. Toutes les indications de configuration des jar nécessaires ou de Spring sont détaillées.
La démo est réalisée sous windows mais le principe est le même pour les machines linux.

Passons à la pratique...

Acte 1: Télécharger smtp.jar

Acte 2: Déposer ce jar dans un répertoire de votre choix, nommons-le SMTP_REP

Acte 3: Avec la console, se déplacer dans le répertoire SMTP_JAR puis lancer la commande: java -jar smtp.jar

                    Laisser la console ouverte.

Acte 4: Configurer le classpath du projet java

Créer sous eclipse un projet java standard. Ajouter les jars suivants:
 spring-2.5.6.jar, spring-test-2.5.6.jar
 mail-1.4.2.jar, activation-1.1.jar

 JUnit-4.4.jar ( éviter de prendre JUnit 4.5 bugué?)

 jsr250-api-1.0.jar
 commons-logging-1.1.1.jar

Acte 5: Créer un fichier de configuration de Spring nommé spring-mail.xml dont voici son contenu:

 [code 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">

<!-- component-scan necessaire pour l'injection autowiring -->
  <context:component-scan base-package=
      "fr.netapsys.blog.simulatemail" />
	
<bean id="mailSender" 
       class="org.springframework.mail.javamail.JavaMailSenderImpl">
	<property name="host" value="localhost" /> 
	<property name="javaMailProperties">
			<props>
				<prop key="mail.debug">false</prop>
			</props>
	</property>
</bean></beans>

La seule chose à signaler est que nous allons utiliser la classe de Spring nommée JavaMailSenderImpl.
La propriété "host" pointe vers "localhost". C'est ce que nous désirons et que nous expliquons plus loin.
Le reste des propriétés ne sont pas utiles pour notre démo. Eventuellement, lorsque mail.debug est à true, les logs du serveur mail sont verbeux.
Les commentaires insérés dans le fichier sont utiles.

Acte 6: Ecrivons un peu de code java , une seule classe nommée fr.netapsys.blog.simulatemail.MailSenderSpring

 [code JAVA]

package fr.netapsys.blog.simulatemail;
import javax.annotation.Resource;
import javax.mail.MessagingException;
import javax.mail.internet.MimeMessage;
import org.springframework.mail.*;
@Service
public class MailSenderSpring {
   private JavaMailSender mailSender;						
   public void send(final String mailTo, final String from,  final String subject,
        final String bodyMail) throws MailSendException, MailException {
    // classe anonyme Preparator
    MimeMessagePreparator preparator=new MimeMessagePreparator() {
	public void prepare(MimeMessage mimeMessage) 
               throws MessagingException {
    MimeMessageHelper helper=null;
    // use the true flag to indicate a multipart message
    helper = new MimeMessageHelper(mimeMessage, false);
    helper.setTo(mailTo);
    helper.setFrom(from);
    helper.setSubject(subject);
    helper.setText(bodyMail, true);
    }
    };
   this.mailSender.send(preparator);
}
@Resource(name="mailSender")
  public void setMailSender(JavaMailSender mailSender) {
    this.mailSender = mailSender;
  }
}

Acte 7: Un test unitaire avec Junit: Ajouter dans eclipse une classe Junit test case nommée "TestSenderMail"

 [code java]

package fr.netapsys.blog.tests;
import javax.annotation.Resource;
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.blog.simulatemail.MailSenderSpring;

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration (locations = {"classpath*:spring-mail.xml" }) 
public class TestSenderMail {
 @Resource
 protected  MailSenderSpring mailSenderSpring;
	
 @Test public void testSendMail() {
  mailSenderSpring.send( "toto@g.fr","from@m.fr","sujet tst mail"," body ....");
	//no Assert !
 }
}

Dans eclipse, clique droit sur la classe Junit puis run as Junit Test.

On obtient sur la console Dos laissé ouverte quelques messages utiles sur l'ouverture d'une session smtp. Et dans le répertoire SMTP_REP, des fichiers logs et un .mht qui récapitulent les éléments liés à l'envoi de mail. Je vous laissent les découvrir.

Conclusion:

C'est simple!.

En résumé, lancer smtp.jar et configurer votre mailSession ou les propriétés de votre serveur mail pointant vers localhost et le tour est joué.

Enjoy!

Billet inspiré de la lecture de tririga

Langage Scala [1ère partie]

Abderrazek CHINE — Thu, 16 Jun 2011 18:02:00 +0200

En quelques démos, nous allons illustrer l’intérêt (et la puissance) du langage Scala. Ces démonstrations sont réalisées sous Windows avec Eclipse Helios et le plugin scala. Vous dites encore un nouveau langage à apprendre! Rassurez-vous, j’ai eu la même réaction que vous. Sachez que le site social Twitter utilise Scala (en abandonnant Ruby). Il faut préciser que Scala est un langage pur objet et en plus:

 * scala compilé produit du « bytecode » exécutable dans la JVM,
 * la syntaxe de Scala est proche de Java,
 * l’API java est supporté dans Scala,

Sachez qu'aucun prérequis n'est nécessaire (peut être faire l'exemple HelloWorld ici).
Le plan du billet est le suivant :

une introduction pour tenter d’expliquer l’utilité de Scala,
un premier exemple pour illustrer l’intérêt de Scala,
plusieurs démo sur les concepts de Scala.

Les démos sont réalisées sous Eclipse Helios avec installation du plugin scala (url update: http://download.scala-ide.org/releases/2.0.0-beta). Sinon, on peut directement tester les morceaux de code scala sur le site http://www.simplyscala.com/.

Pour la suite, nous donnons:

un premier exemple, autre que le fameux HelloWorld qui, dans ce contexte n'apporte pas grand chose,
plusieurs démo sur les concepts de Scala.

Scala n’est pas un concurrent (direct) à Java. Scala concilie la programmation fonctionnelle et celle orientée objet (OOP).

L’orientée objet introduit, à juste titre, une couche d’abstraction utilisant à bon escient, j’ose espérer, les concepts de « design pattern » afin de construire une solution maintenable et robuste.
Sauf que les contraintes des langages orientées objet font que des kilomètres de code utile (appelés aussi de la plomberie ) sont écrits pour réaliser cette solution technique.
Scala concilie les deux approches en permettant, par exemple, de passer une nouvelle fonction en argument aux méthodes existantes.

Passons à la pratique..... c'est toujours mieux que les discours!

DEMO 1:

Après l’installation du plugin dans Eclipse, cliquer open new scala project ==> saisir le nom du projet « firstscalaproj» par exemple. Vérifier que le JDK est de version 1.5 ou + puis ==> « next » ==> « finish »

Le projet créé avec les librairies de scala dans le « classpath» et un répertoire « src » vide pour l’instant. Clic droit sur « src » ==> new package nommé « fr.netapsys.blog.exemple1 ».

Clic droit sur « src » ==> new « Scala Object » puis saisir le nom de la classe « FirstExemple » et saisir le nom du package ==> finish. Une classe, par défaut publique, est créée dans le package avec, pour l'instant peu de lignes :

 /*scala*/
package fr.netapsys.blog.exemple1

object FirstExemple {
}

Nous la complétons pour ajouter l’équivalent de la méthode main de java comme suit :

 **scala**  FirstExemple.scala
1 package fr.netapsys.blog.exemple1
2 import System.out.println
 3 object FirstExemple {

 4   def main(args: Array[String]): Unit = {
	//function
 5	def afficheListe(liste: List[Int],msg:String) {
 6	  println("Affichage "+msg+" : "+liste)
	}
 7	val entiers = List(-1, 1, 2, 3, 4, 5, 6)
 8	afficheListe(entiers,"de la liste")

	/* filtre fonctionnel */
 9	val positifs = entiers.filter(_ > 0)
10	afficheListe(positifs,"des entiers positifs ")
	/* other filter fonctionnel */
11	val grands = entiers.filter(2<)  //_ > 2)
12	afficheListe(grands,"des entiers plus grands que 2 ")

	////un peu de fonctionnel ...interessant
13	val intermeds = positifs.filter(x => x > 1 && x < 6)
14	afficheListe(intermeds, "des entiers entre 2 et 5 ")

15	val exist=intermeds.exists(_==8)
16	if(exist) println("existe!")
17	else println ("n'existe pas!")
	//Enfin, une seconde façon d’afficher la liste
18	intermeds.foreach(println)		
19  }
20 }

Ecoutez, je sais bien ce que vous dites! On n’est loin de java et puis c’est assez … PERListe / Rubyiste.
Rassurez vous, nous décortiquons tout ce code pas à pas plus loin.
Mais avant, exécutons cette classe dans Eclipse par un clic droit sur « FirstExemple.scala » ==> Run as ==> Scala Application.

Le résultat de l'exécution est donné ci-dessous :

Expliquons un peu : Dans Scala et contrairement à java, une classe est par défaut publique. Un même fichier d'extension .scala peut contenir plusieurs classes.

Déclaration de classe (objet)

- Toute classe est publique donc pas de modificateur de visibilité - Elle peut être abstraite comme en java. Scala va plus loin que java puisque même ses attributs peuvent être abstraits. - On distingue une classe particulière nommé « object » utilisée dans ce démo. Elle reproduit le contexte statique de java. En scala l’objet est une instance singleton et donc ne nécessite pas d’être instanciée. Enfin, signalons qu’à la différence de java, le contexte statique n’existe pas.

Déclaration d’attributs

La syntaxe de déclaration d’un attribut est comme suit : [indicateur de visibilité] (val|var) nom_attribut [:Type =Valeur]

Tout ce qui est entre crochets [] est optionnel.

L’indicateur de visibilité est optionnel peut prendre la valeur « private ou protected ». Quand rien n’est mentionné il est par défaut publique et donc accessible à l’extérieur de la classe. Le symbole (var|val) indique qu’il peut être soit un attribut muable soit un immuable. Le choix est ici exclusif. Notez que «val» est l’équivalent de « final » en java.

L’option [:Type] permet de préciser le type de l’attribut Int, String, Number, ..etc Le système d’inférence de scala détermine le type d’un attribut au moment de l’affectation. Par exemple,

 
private val nb:Int=9

var str:String

private var k:Int=_

val pStr=""

var abstrAttribut:Int

Donc, le champ nb est un objet Int initialisé à 9.
k est un Int initialisé avec la valeur par défaut (0 pour Int). Scala infère à pStr son type, ici String, à partir de la valeur d'init.
Enfin, le champ Int abstrAttribut est abstrait puisqu'il n'est pas initialisé.
Attention, si un champ n’est pas initialisé alors il est considéré comme abstrait. Scala étend le domaine « abstrait » et va plus loin que java.

Déclaration des constructeurs

Parlons des constructeurs de classes de scala qui sont légèrement (j’ai bien dit légèrement) différents de java mais pas de quoi nous décourager!

Le constructeur principal (et non le constructeur par défaut) se déclare en une seule ligne comme dans cet exemple :

class Entreprise(var raisonSociale :String,var id :Int)

Et c’est tout! Oui on a défini deux attributs de la classe et le constructeur qui prend en paramètres ces deux attributs. C'est concis.

Voilà, on peut instancier la classe comme suit :

Entrep :Entreprise=new Entreprise(“Pharamcie toto”,1)

Je crois que nous avons les éléments utiles pour détailler notre démo1.

object de notre démo1 n'a pas besoin de constructeur (c'est une instance reproduisant le contexte statique connu dans java).

La fonction/méthode def main est le point d'entrée (Ligne numérotée 4) et elle indique qu'elle prend en argument un tableau de String identique à java. Elle retourne un type Unit et avec le signe "=" elle précise ce qu'elle doit retourner. Le type scala.Unit est l'équivalent de void en java.

Ligne 5, juste après avoir défini la fonction def afficheListe qui elle prend comme arguments une List et un String. Rien de nouveau sous le ciel scala! Oui, pour l'instant! Ligne 7, on déclare un attribut List initialisée. L'inférence de scala détermine le type c'est à dire une liste Int. Ligne 8 affiche cette liste.

A Ligne 9 arrive aux "trucs" intéressants: On passe à la fonction filter de List une nouvelle fonction qui est : "_ > 0"
Ainsi, comme résultat du filtre on obtient les entiers positifs. Cette forme abrégée aurait pu être écrite sous la forme explicite: "x=>x>0"
Si vous êtes encore là, c'est que vous commencer à adopter scala.
Poursuivons, à la ligne 13 une autre fonction sous une forme plus élaborée
x=> x>2 && x=>x<6
qui permet de ne retenir que les entiers qui sont conformes aux deux conditions. On obtient donc que les entiers compris (strictement) entre 2 et 6 comme la capture ci-dessus le confirme.

A la ligne 18, encore une autre façon de passer une fonction (ici System.out.println importée en haut) à la méhode foreach de List.

On peut aussi, passer le Logger de log4j ou toute autre méthode de trace comme suit :

val logger:Logger= Logger.getLogger(this.getClass().getName())

interms.foreach(logger.trace)

Ajouter log4j.jar au classpath du projet et, dans le code, la ligne

import org.apache.log4j.Logger.

Vous avez un aperçu de la richesse et la puissance de scala avec ces premiers exemples où l'emploi des filtres de scala. Ces filtres peuvent être adaptés et enrichis de manière simple.

En java c'était aussi possible (avec les classes anonymes bien qu'il y a des contraintes à respecter mais trop limité pour la récupération du binding contexte ). Mais, en java, le prix à payer est fort! Peut-être que les closures dans les futures versions java (closures abandonnés dans java 7?) .

Dans les prochains billets nous détaillerons, entre autres, le code ci-après permettant de lire un fichier :

        var contenu=""
	val nomFichier="test.txt"
	try{
	 contenu = fromFile(nomFichier).mkString
	}catch{
	   case e:FileNotFoundException => e.getMessage()
	   logger.error("Fichier "+nomFichier)
	   System.exit(1)
	}	
        logger.info("contenu du fichier :
"+contenu)

NOTE: En fait, une ligne suffit car le catch de l'exception est optionnel. En réalité, dans scala, Il n'y a pas de checked exception.
Pensez à l'import scala.io.Source.fromFile et java.io.FileNotFoundException.
Là il faut que je m'arrête! On reparlera de tout cela prochainement.

En attendant, enjoy!

NOTE: A la fin de la rédaction de cette première partie, j'ai découvert ce très bon article, en français, site que je conseille sa lecture.

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.