Par audit, nous entendons l’audit des actions importantes réalisées sur une application.

Pourquoi auditer ?

Est-il vraiment utile de générer des informations d’audit dans nos applications ? Sans explications de juriste, quelques exemples suffiront à nous en convaincre :

• Un site web de partage de photos doit pouvoir dire qui a uploadé quelle image, depuis quelle adresse IP et à quelle date.
• L’application d’administration d’un site de e-commerce doit tracer toutes les modifications de prix pour empêcher un employé astucieux de baisser à 1 euro le prix de son téléphone préféré le temps de passer commande.

Pour revenir à des explications plus théoriques, les logs d’audit nous apportent :

• les informations nécessaires à la justice en cas d’infraction,
• la détection d’intrusions,
• la reconstitution des événements en complément des logs d’exceptions pour aider au diagnostique de problèmes.

Nous nous placerons dans le cas le plus fréquent où nous ne développons pas d’outil pour consulter ces informations d’audit et où un accès direct au média de stockage (grep sur fichier texte, sql sur base de données, etc) suffit.

Que faut-il auditer ?

Dans un monde idéal, le contenu des messages serait défini avec les équipes de sécurité. En pratique, nous sommes assez seuls pour les choisir et il ne faut pas dramatiser. Si l’on ne prend pas le sujet à la légère, après quelques itérations, notre bon sens est le plus souvent suffisant.

Les éléments clefs à tracer sont :

• L’heure exacte : il est essentiel que les serveurs soient à l’heure pour corréler les logs des différentes briques du système d’information. Le sujet est aujourd’hui censé être banal pour les équipes système (c.f. NTP) et nous pouvons demander le soutien des équipes sécurité pour obtenir gain de cause.
• L’action réalisée : il s’agit souvent du nom de la méthode métier appelée.
• L’identifiant et/ou la valeur des données métier sensibles manipulées : souvent les id ou le toString() des paramètres d’appel.
• L’auteur de la manipulation : nom de l’utilisateur connecté et son adresse ip (pour plus de détails sur l’adresse ip : XForwardedFilter et Tomcat : Adresse IP de l’internaute, load balancer, reverse proxy et header Http X-Forwarded-For).
• La description succincte des exceptions levées pour analyser les éventuelles attaques.

Pourquoi les logs d’accès des serveurs http ne suffisent pas ?

La première idée serait de se contenter des logs d’accès des serveurs web et des firewalls pour auditer les accès à nos applications ; nous n’aurions alors plus rien à faire.

Hélas, cela n’est pas suffisant car il manque dans les logs http des informations clefs :

• Nous n’avons pas l’identité de l’appelant : on a bien l’adresse ip mais pas le login de l’utilisateur authentifié.
• Nous n’avons pas les id passés en paramètre des opérations à auditer (sauf si on fait du REST) ; en SOAP, nous n’avons même pas le nom de l’opération !
• Nous n’avons pas le détail des exceptions levées par l’application.

API : Framework de log vs. framework dédié

Dans un monde idéal, le framework d’audit ne devrait pas dépendre de la configuration des logs pour ne pas risquer qu’une mauvaise manipulation de ces configurations de logs ne le désactive.

En pratique, les frameworks de logs sont les briques les plus performantes et les plus matures pour traiter les besoins d’écriture d’audit et la probabilité de désactiver l’audit en faisant une mauvaise manipulation sur la configuration des logs est négligeable. Ces raisons nous amènent à utiliser SLF4J avec logback ou log4j pour gérer l’audit.

Nous encapsulerons tout de même le logger avec une couche légère packagée dans la librairie Xebia Spring Security Extras qui ajoutera au message l’identité de l’internaute et son adresse IP (via Spring Security). Cette librairie offre une gestion déclarative de l’audit avec une annotation @Audited, son aspect associé AuditAspect et une classe utilitaire Auditor. Nous ne rentrerons pas dans le débat annotations vs. code ; dans la majeure partie des projets, nous avons pu traiter la plupart de l’audit avec une annotation et seuls quelques cas ont nécessité de passer par du code.

Exemple de gestion de l’audit avec l’annotation @Audited :

@Audited(message = "transferMoney(#{args[0].accountNumber}, #{args[1].accountNumber}, #{args[3]})")
public void transferMoney(Account from, Account to, Amount amount) throws BusinessException { ... }

L’attribut message est un pattern supportant Spring Expression Language définissant l’entrée insérée dans le fichier d’audit ; la date, le nom de l’utilisateur, l’adresse ip et l’exception s’il y en a une sont ajoutés au message.

Fragment de configuration Spring Framework pour utiliser l’annotation @Audited :

<beans ...
   xmlns:security-extras="http://www.xebia.fr/schema/xebia-spring-security-extras"
   xsi:schemaLocation="...
        http://www.xebia.fr/schema/xebia-spring-security-extras http://www.xebia.fr/schema/security/xebia-spring-security-extras.xsd">
   <!-- enable Spring AOP -->
   <aop:aspectj-autoproxy/>
  <!-- activate the AutitAspect -->
  <security-extras:audit-aspect />
   ...
</beans>

Message d’audit généré :

... transferMoney(000652584515, 0000684651684, 187.53) by bdupont coming from 192.168.0.14
... transferMoney(000652584515, 0000684651684, 666666.00) threw '...BusinessException: debit amount greater than account balance'
   by bdupont coming from 192.168.0.14

Exemple de gestion de l’audit avec l’utilitaire Auditor :

public void transferMoney(...) throws BusinessException {
   ...
   Auditor.audit("Tranfer '" + amount + "' from " + fromAccount + " to " + toAccount);
}

Message d’audit généré :

... Transfer '187.53 euros' from Account[000652584515] to Account[0000684651684] by bdupont coming from 192.168.0.14

L’entrée d’audit est ajoutée dans un fichier d’audit géré par le logger spécifique "fr.xebia.audit" (voir cet article pour la configuration du logger).

Tous les détails sur l’annotation @Audited sont sur @Audited Annotation.

Intégration du framework dans une application

Ce framework peut être intégré de différentes façons dans une application :

• Intégration Maven :

  <project ...>
     <dependencies>
        <dependency>
           <groupId>fr.xebia.springframework</groupId>
           <artifactId>xebia-spring-security-extras</artifactId>
           <version>1.1.6</version>
        </dependency>
        ...
     </dependencies>
     ...
  </project>
  

  Cet artifact est déployé sur le Maven Central Repository.

• Téléchargement du jar xebia-spring-security-extras-1.1.6.jar (sources).
• En récupérant le code source disponible sous licence Open Source Apache Software Licence 2 dans le repository GitHub https://github.com/xebia-france/xebia-spring-security-extras.

Stockage : fichier texte vs. base de données

Le stockage des entrées d’audit en base de données permet sûrement une recherche plus fine des données que sur des fichiers mais cela ajoute de la complexité (déploiement, exploitation, backup) ainsi que des risques de pannes et impacte les performances. Les approches JMS présentent des contraintes similaires et l’utilisation de systèmes de logs distants comme rsyslog présentent un défi de fiabilité. Ces difficultés sont accentuées lorsqu’une application génère de gros volumes de logs (plusieurs Go/jour).

Pour ces raisons, nous préférons stocker les messages d’audit dans un simple fichier. Les risques de saturation du système de fichiers sont assez facilement gérables par les équipes d’exploitation, les procédures d’archivage et de consultation très simples (gzip, scp, grep, etc) et il n’y a quasiment jamais de problème de performance, même avec des fichiers de quelques Go par jour.

Y-a-t-il un plus grand risque de perdre les données par de mauvaises manipulations ? Si une application est critique, les exploitants doivent déjà ne pas perdre les fichiers de log du système d’exploitation, des serveurs web et autres firewalls.

Pour la gestion des messages d’audit sous forme de fichier texte, nous aimons logback comme nous l’avons expliqué dans Java en Production – Les fichiers de logs mais il est aussi possible d’utiliser Log4j.

Exemple de configuration Logback pour gérer les messages d’audit émis sur le logger fr.xebia.audit :

<appender name="audit-file" class="ch.qos.logback.core.rolling.RollingFileAppender">
   <file>${LOGS_FOLDER}/my-application-audit.log</file>
   <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
      <!-- rotate every day -->
      <fileNamePattern>/my-application-audit.%d{yyyyMMdd-HHmm}.log.zip</fileNamePattern>
   </rollingPolicy>
   <encoder>
      <!-- don't output the date or the logger name because the auditing framework handles this -->
      <pattern>%m %throwable{0}%n</pattern>
   </encoder>
</appender>
<!-- route the 'fr.xebia.audit' log messages to the audit-file -->
<logger name="fr.xebia.audit" additivity="false" level="TRACE">
   <appender-ref ref="audit-file" />
</logger>

Exemple équivalent avec log4j (le EnhancedPatternLayout requiert log4j 1.2.16) :

log4j.appender.auditfile=org.apache.log4j.DailyRollingFileAppender
log4j.appender.auditfile.datePattern='-'yyyyMMdd
log4j.appender.auditfile.file=${catalina.base}/logs/my-application-audit.log
log4j.appender.auditfile.layout=org.apache.log4j.EnhancedPatternLayout
log4j.appender.auditfile.layout.conversionPattern=%m %throwable{short}n
log4j.logger.fr.xebia.audit=INFO, auditfile

Que faire des logs d’audit après les avoir générées ?

Nous ne rentrerons pas plus dans les détails de la gestion des logs d’audit après leur génération par nos applications.

Ce sujet complexe présente aussi bien des aspects juridiques que de confidentialité ou encore de fiabilité. Schématiquement, on n’a pas le droit de garder indéfiniment des données personnelles, il faut restreindre leur consultation et empêcher leur modification et leur destruction par accident comme par malveillance.

Des professionnels de l’exploitation et de la sécurité sont beaucoup plus compétents que nous sur ce sujet .

Pour aller plus loin

Si le traitement de l’audit dans les applications vous a intéressé, nous avons aimé lire :

• The Importance of Audit Logs par George Spafford,
• NIST 800-92 Log Management Guide in the Real World et l’ensemble des présentations de Anton Chukavin.

Synthèse

Nous avons vu aujourd’hui une façon simple de gérer l’audit d’applications java en reposant sur le framework de log de l’application (Logback voire Log4j) pour écrire les messages dans de simples fichiers texte avec une surcouche très légère composée d’une annotation @Audited et d’un utilitaire Auditor.

Historique
25/11/2010 : passage à la version 1.1.5 de la librarie xebia-spring-security-extras avec utilisation du namespace de configuration.
20/12/2011 : xebia-spring-security-extras : passage à la version 1.1.6 et aux URLs GitHub

• La configuration via annotations, parce que c’est tendance
• Les Web Fragments, un bon moyen de modulariser
• L’exécution asynchrone, pour les architectures Comet

La configuration via annotations, c’est tendance

L’épidémie continue ! Je ne parle pas de la fameuse grippe qui circule en ce moment … mais des annotations. C’est la première nouveauté que je voulais mettre en avant concernant les Servlets 3.0. Dorénavant, vous pourrez configurer vos Servlets, Filtres et autres ContextListeners via des annotations spécifiques. Vous en êtes fan ? Tant mieux. Pour ma part, je n’utilise directement les servlets que très rarement, ce n’est donc pas cette nouveauté qui m’intéresse le plus. Pour avoir déjà eu cette discussion avec des collègues, cette réponse engendre rapidement des exclamations du type : « Tout le monde ne fait pas que du Spring !». Et pourtant, c’est un fait : cela fait bon nombre d’années que je n’ai pas eu besoin de créer de servlets, Spring ou non. Et vous, quels usages en faites vous ?
D’autre part, de manière générale, il ne faut pas dénigrer les bons vieux fichiers XML. S’ils peuvent paraître lourds et verbeux, ils ont l’avantage de centraliser les différentes déclarations et configurations à un seul endroit. Il ne me semble d’ailleurs pas complètement burlesque de découpler un mapping de son objet cible : les annotations sont avant tout destinées à des méta-données statiques.

Cet aparté mis à part, revenons au cœur du sujet : les annotations disponibles dans Servlet 3.0 :

• @WebServlet, permet de marquer une classe comme servlet. Cette classe doit toujours étendre HttpServlet

@WebServlet(name="simpleservlet", urlPatterns="/myservlet", "/simpleservlet"})
public class SimpleServlet extends HttpServlet { ... }

• @WebFilter, de la même manière, cette annotation permet de déclarer un Filtre

@WebFilter(urlPatterns={"/mufilter","/simplefilter"})
public class SimpleFilter implements Filter { ... }

• @WebInitParam, cette annotation est utilisée pour préciser des paramètres d’initialisation aux Servlets ou aux Filtres

@WebServlet(name="simpleservlet", urlPatterns="/myservlet", "/simpleservlet"}, initParams={
    @WebInitParam(name="param1", value="value1"),
    @WebInitParam(name="param2", value="value2")
})
public class MyServlet extends HttpServlet { ... }

• @WebListener, permet d’annoter un ContextListener pour vous permettre de recevoir certains événements de la WebApp

@WebListener
public class MyListener implements ServletContextListener { ... }

• @MultipartConfig, sur une Servlet, cette annotation indique que la requête attendue est du type mime/multipart et son contenu est rendu directement disponible par l’intermédiaire de la méthode request.getParts() … enfin !

Vous l’avez compris, avec l’introduction des annotations, le descripteur de déploiement web.xml devient optionnel. La configuration est simplifiée, c’était le but recherché, mais rien de révolutionnaire dans cette fonctionnalité.

Outre les annotations, les spécifications fournissent un autre nouveau moyen d’ajouter des Servlets et Filtres. Une API permet la configuration dynamique au Runtime lors des différents évènements récupérés par le ContextListener. Pour quoi faire ? Pour permettre aux Frameworks de s’initialiser dynamiquement à partir de fichier de configuration ? Dans les faits, l’intérêt est limité puisque l’ajout de Servlet passe par l’intermédiaire d’un simple nom de classe (qui sera chargé par un Class.forName() ). Il vous sera donc difficile de passer des valeurs dynamiques à celle-ci avant son initialisation. Du coup, on perd l’intérêt d’un tel mécanisme.

context.addServlet("name", "description", "fr.xebia.web.servlet.SimpleServlet", initParams, -1, false);
context.addServletMapping("name", urlPatterns);
context.addFilter("filterName", "description", "fr.xebia.web.filter.SimpleFilter", initParams, false);

Les Web Fragments, un bon moyen de modulariser

Les web fragments fournissent un moyen simple de partitionner logiquement le descripteur de déploiement (web.xml). Ainsi, différents frameworks (Struts, JSF …) pourront fournir par ce biais une configuration Web par défaut directement depuis leur Jar. Ils faciliteront et masqueront ainsi au maximum leur configuration à leurs utilisateurs.

La déclaration d’un fragment est simple. Il s’agit d’un fichier XML conventionné qui doit :

• se nommer web-fragment.xml
• être placé dans le répertoire META-INF d’un Jar
• avoir comme élément racine du XML une balise <web-fragment>

Pendant le déploiement, le conteneur est responsable de scanner, découvrir et traiter les différents fragments répondant à ces critères.

< !-- Exemple de web-fragment.xml -->
<web-fragment>
  <name>XebiaCustomFragment</name>
  <listener>
    <listener-class> fr.xebia.web.servlet.CustomListenerInFragment</listener-class>
  </listener>
  <servlet>
    <servlet-name>CutomServletInFragment</servlet-name>
    <servlet-class>fr.xebia.web.servlet.CutomServletInFragment</servlet-class>
  </servlet>
</web-fragment>

Il vous est possible de nommer vos fragments par l’intermédiaire d’une balise spécifique <name />. Cette balise vous permet de contrôler qu’un fragment ne soit chargé qu’une seule et unique fois. D’autres balises : <absolute-ordering />, <ordering />, <before />, <after />, <others /> permettent de contrôler l’ordre de déclaration des différents fragments.

<web-fragment>
  <name>XebiaCustomFragment2</name>
  <ordering><after>XebiaCustomFragment</after></ordering>
  ...
</web-fragment>

Il y a fort à parier que les frameworks web stars adopteront rapidement cette nouveauté pour faciliter la vie de leurs utilisateurs. Les tambouilles internes de configuration se feront plus discrètes tout en accentuant la modularité de vos projets. Pourtant ces fragments seront-ils d’une réelle utilité ? Pour ma part, je pense que cette fonctionnalité est une belle avancée. Elle incite les développeurs à regrouper leur code et configuration dans un même endroit. Il s’agit donc, si on peut dire, d’une première étape vers un développement modulaire.

L’exécution asynchrone, pour les architectures Comet

Je vous ai gardé le meilleur pour la fin, c’est à mon avis la nouvelle fonctionnalité la plus remarquable : l’ajout de l’exécution asynchrone. Jusqu’à présent, lorsqu’un utilisateur appelait une servlet, il n’avait d’autre choix que d’attendre la fin du traitement avant de pouvoir reprendre la main : l’exécution d’une Servlet était synchrone. Ce comportement était-il désiré ou subi ? Probablement un peu des deux. Lorsque vous vouliez lancer un traitement et rendre la main rapidement à vos utilisateurs, vous deviez gérer par vous-même le fonctionnement asynchrone : pools de threads, files d’attente, listeners … bref, le début des galères. À quoi bon garder cette glue technique pour un besoin aussi simple que récurrent ?

Servlet 3.0 vous propose donc un mécanisme d’exécution asynchrone vous permettant de simplifier ce code à son strict minimum. Configuré dynamiquement par le code request.startAsync() ou via les propriétés asyncSupported et asyncTimeOut des annotations présentées précédemment, il est possible de rendre le traitement d’une requête asynchrone, avec si besoin, un timeout. Pour cela, une nouvelle API permet de suspendre et de reprendre le traitement d’une requête en cours d’exécution et d’activer ou non la réponse en fonction des besoins de l’application. Il est également possible d’ajouter des listeners qui recevront les notifications de fin de traitement ou de timeout. Ce nouveau mécanisme vous sera particulièrement utile si vous désirez mettre en place une architecture du type Comet dont la caractéristique principale est de laisser ouvert le plus longtemps possible un canal de communication entre le client et le serveur (dans l’attente de nouveautés sur le serveur).

@WebServlet("/servletAsync", asyncSupported=true)
public class MyServlet extends HttpServlet {
   public void doGet(HttpServletRequest request, HttpServletResponse response) {
     // Ajouter un listener
    request.addAsyncListener(new MyAsyncListener())
    // Definition du timeout programatiquement
    request.setAsyncTimeout(10000);
     // Execution asynchrone et récupération du context
     AsyncContext context = request.startAsync(request, response);
   }
}

Dans ce second article, nous allons découvrir des outils d’injection plus évolués, qui devraient nous permettre de réaliser par la suite notre premier exemple ‘réel’ d’implémentation Guice.

Injection ‘nommée’

Reprenons l’exemple simple utilisé dans l’article précédent pour en augmenter la difficulté.
Nous partons du postulat que notre DAO ne possède plus une seule, mais deux implémentations distinctes : MyBasicDaoImpl, précédemment utilisée, et MyBasicDaoMock, une nouvelle implémentation utilisant une base volatile.
Nous allons utiliser ces deux implémentations successivement dans notre service, et donc injecter deux implémentations différentes de la même interface dans notre service :

@Override
public void displaySample() {
	try {
		recorder.append("Calling DAOn");
		String daoResult = basicDao.select();
		recorder.append("Result from DAO : " + daoResult + "n");
		recorder.append("Calling memory DAOn");
		daoResult = memoryDao.select();
		recorder.append("Result from memory DAO : " + daoResult + "n");
	} catch (IOException e) {
		e.printStackTrace();
	}
}

Premier point à noter, pour notre DAO existant rien ne change, Guice utilisera la première implémentation déclarée pour résoudre la dépendance.
Pour notre seconde dépendance, nous utiliserons l’injection nommée.
Première solution, créer une annotation, @Memory, en utilisant la BindingAnnotation de Guice :

@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.FIELD, ElementType.PARAMETER})
@BindingAnnotation
public @interface Memory {}

Il suffit alors d’annoter le constructeur du service :

@Inject
public MyServiceImpl(MyBasicDao basicDao, @Memory MyBasicDao memoryDao) {
	super();
	this.basicDao = basicDao;
	this.memoryDao = memoryDao;
}

et d’annoter la déclaration de dépendance dans la classe Module

binder.bind(MyBasicDao.class).annotatedWith(Memory.class)
    .to(MyBasicDaoMemoryImpl.class);

Cette solution est relativement élégante, mais comporte le défaut de multiplier les classes d’annotation.
Le même résultat peut être atteint en utilisant une classe Guice permettant de nommer ses classes, mais sans créer d’annotation spécifique, à l’aide de l’annotation @Named et de la méthode Names.named(String)
Le code ci-dessus est équivalent à :

// Dans MyModule
binder.bind(MyBasicDao.class).annotatedWith(Names.named("Memory"))
    .to(MyBasicDaoMemoryImpl.class);
// Dans MyServiceImpl
@Inject
public MyServiceImpl(MyBasicDao basicDao, @Named("Memory") MyBasicDao memoryDao) {
    ...
}

Utiliser une dépendance conditionnelle à l’aide de l’annotation @Provides

Continuons à affiner notre injection de dépendance, en la conditionnant à des conditions runtime.
Imaginons que nous voulions injecter une implémentation de notre DAO en dépendant d’un paramètre runtime (nous nous baserons simplement sur un nombre aléatoire).
Pour cela, nous allons utiliser une méthode @Provides (à ne pas confondre avec les Providers de la version 1 de Guice).
Cette méthode doit être placée dans un module (où elle sera auto-découverte et retournera une instance de la classe injectée).

// Dans MyModule
/**
 * Provides method
 */
@Provides
@Inject
private @Named("Random")
MyBasicDao provideRandomDao(MyBasicDao basicDao,
		@Named("Memory") MyBasicDao memoryDao) {
	if (RandomUtils.randomBoolean()) {
		return basicDao;
	}
	return memoryDao;
}

On peut noter que cette méthode peut elle-même être injectée (avec les instances de Dao précédemment utilisées).

Conclusion

Nous avons maintenant une certaine souplesse dans l’injection, qui va nous permettre d’aborder dans un prochain billet un exemple plus concret.
À noter que durant la rédaction de ce billet, la version 2.0 de Google Guice a été officiellement releasée, et que les prochains billets se baseront sur cette version stable.

Téléchargez le projet Eclipse sur le Google Code de Xebia.

SOA

• Fuji, le futur d’OpenESB

Le coin de la technique

• Concevoir des APIs efficaces
• JavaFX : informations et controverses
• Sortie de Wicket 1.3.6
• @Inject standardisation de l’injection de dépendances
• Sortie de Tapestry 5.1
• Trucs et astuces Json – Restfull

Evènements de notre communauté en France et à l’étranger

• Soirée Datagrid au Paris Jug

SOA

Fuji, le futur d’OpenESB

La prochaine version d’OpenESB, qui sera estampillée ‘v3′, est en cours de développement sous le nom de code ‘Project Fuji’. Ce projet a été récemment mis en avant par Andi Egloff, dans un webcast qui fait le tour des nombreuses nouveautés. Les principales d’entre elles sont :

• Integration Flow Language (IFL) : il s’agit d’un DSL externe permettant de définir des flux d’intégrations. Le rôle de ce langage est donc le même que le DSL interne offert par Apache Camel.
• Distributed JBI : La spécification JBI (JSR-208) ne couvre pas la problématique de distribution des composants JBI sur plusieurs noeuds. Fuji apporte une extension propriétaire pour permettre cette distribution.
• Utilisation de composants OpenJBI : ces composants seront utilisables directement dans OpenESB v3. Le projet prévoit de mettre les composants dont la compatibilité aura été validée dans le repository Maven du projet.
• Enterprise Integration Patterns : un certain nombre d’EIP sera supporté en standard et configurable via le langage IFL.

La version finale d’OpenESB v3 est prévue pour le second semestre 2009, l’équipe du projet annonce une probable preview pour JavaOne en juin.

Le coin de la technique

Concevoir des APIs efficaces

John De Goes vient de publier une série de deux articles (première partie et deuxième partie) portant sur les bonnes pratiques de conception d’APIs. Il s’appuie sur un exemple d’API de configuration pour illustrer son propos. Les points qu’il met particulièrement en avant sont :

• Il est important de sélectionner le niveau d’abstraction approprié et d’assurer l’uniformité de celui-ci sur l’ensemble de l’API, ainsi que de définir et respecter une responsabilité pour chaque classe. Ceci concerne la granularité des méthodes, le type d’objets manipulés en entrée et en sortie, ainsi que la présence et le type d’exception éventuellement renvoyée.
• N’offrir qu’une seule possibilité pour chaque besoin, afin d’éviter la confusion chez l’utilisateur de cette API.
• S’appuyer sur les possibilités offertes par le langage pour empêcher certaines mauvaises utilisations d’une API.
• L’API doit être la plus intuitive possible afin de minimiser autant que possible le besoin pour l’utilisateur d’avoir à se plonger dans une documentation.

Certaines de ces idées sont déjà partagées par de nombreux développeurs, mais comme c’est souvent le cas dans l’énonciation de bonnes pratiques ou de patterns, tout l’intérêt réside ici dans la formalisation apportée par l’auteur.

Les lecteurs intéressés par cette problématique pourront se tourner vers le livre de Jaroslav Tulach, Practical API Design, qui apporte l’intéressant retour d’expérience d’un architecte de NetBeans, ou encore How to Design a Good API and Why it Matters par Joshua Bloch (auteur de Effective Java).

JavaFX : informations et controverses

Depuis plusieurs mois, nous vous rapportons les différentes informations et controverses à propos de JavaFX. Cette technologie RIA, développée par Sun, et introduite en décembre 2008 fait beaucoup parler d’elle car personne ne sait dire aujourd’hui ce qu’il adviendra de JavaFX dans les mois et années à venir.

Les propos particulièrement négatifs dont JavaFX a été victime à ses débuts se font moins nombreux, non pas parce que cette technologie a convaincu, mais parce qu’elle n’est plus au centre des débats. En fait, ceci est bénéfique puisque cela permet d’observer plus sereinement les différents exemples postés régulièrement par la communauté JavaFX naissante. Il ressort de ce tour d’horizon que les capacités actuelles de JavaFX ne prêtent pas à critique : les fonctionnalités de graphisme et d’animations qui sont offertes semblent satisfaire de nombreux développeurs. Le problème porte principalement sur les manques et les promesses non tenues à ce jour :

• la portabilité de JavaFX sur plusieurs environnements (_desktop_, web, mobile, et TV, le fameux ‘All the screens of your life‘) n’est pas assuré puisque le déploiement est impossible sur mobile, faute de device compatible. Le fonctionnement sur téléviseur est lui toujours prévu dans une version ultérieure.
• les composants graphiques de haut niveau sont absents. Il s’agit pourtant d’un élément indispensable pour le développement d’applications RIA.

Joshua Marinacci, un des meneurs de JavaFX chez Sun, a été interviewé par Scott Hanselman dans un podcast. Il annonce que la démonstration de JavaFX sur TV pourrait être faite lors de JavaOne 2009, en juin. Il reconnaît par ailleurs le marketing excessif entourant cette technologie.

Outre ces réflexions d’ordre technique, le rachat de Sun par Oracle constitue une autre source de débats. Personne ne sait quelle décision Oracle prendra quant à JavaFX : soutenir ce projet qui nécessite encore un investissement lourd pour prétendre réellement concurrencer les autres acteurs RIA ou abandonner ce marché. Les différentes opinions sur ce sujet sont présentées et argumentées dans le dernier podcast des Cast Codeurs.

Sortie de Wicket 1.3.6

Wicket, le framework orienté composant de la Fondation Apache, sort en version 1.3.6 (1.4 toujours en release candidate 2).

Malgré les 7 mois d’écart avec la version précédente, il ne faut pas s’attendre à une révolution pour cette nouvelle mouture. Il s’agit en effet d’une version de stabilisation et d’amélioration. On notera donc de nombreux correctifs de bugs et plusieurs améliorations.

Cette version est téléchargeable sur le site d’Apache ou en changeant votre version de pom.xml en 1.3.6.

A noter, toujours autour de Wicket, le retour critique de Tom’s Quest sur Wicket et ses limites après la présentation, chez Zenika, de Martin Dashorst, un des committers principaux de Wicket et coauteur du livre Wicket In Action.

@Inject standardisation de l’injection de dépendances

Pas mal de bruit la semaine dernière dans la blogosphère Java avec l’annonce par Google et SpringSource d’une nouvelle proposition de JSR dédiée à l’injection de dépendances : @Inject (« Annotations for Dependency Injection »).
Comme le souligne ‘Crazy’ Bob Lee, l’auteur principal de Google Guice, la sortie de Spring 1.0, il y a déjà 5 ans, a apporté l’injection de dépendances aux masses, via un fichier de configuration propriétaire. Il y a 3 ans, Google Guice a proposé la même chose via des annotations (et SpringSource propose la même chose depuis Spring 2.5).
Si le succès de Google Guice est assez limité face au raz de marée Spring, le constat est là : il manque un standard. Comme les deux librairies ne sont pas compatibles, si vous exposez à un autre projet/équipe une librairie contenant des dépendances injectées par Google Guice, et que l’autre équipe utilise Spring, elle devra redéfinir tous les beans et leurs dépendances dans un fichier de configuration Spring (ou des annotations Spring).
@Inject propose donc de standardiser les annotations, afin de rendre portables sur différents frameworks (Guice, Spring, Tapestry IOC, etc.) des classes injectables.

Lire notre article à ce sujet : @Inject standardisation de l’injection de dépendances.

Sortie de Tapestry 5.1

Tapestry, dont on parlait récemment dans l’article l’injection de dépendances avec Tapestry IoC, passe en version 5.1 en respectant à la lettre son nouveau planning d’une version tout les 4 à 6 mois.
Outre les améliorations de performance et les nombreux bugs corrigés, la mise à jour embarque des nouveautés sur le support JavaScript, à la traîne par rapport au prédécesseur Tapestry 4.
Le rafraîchissement de plusieurs zones d’une page en une seule requête Ajax est maintenant supporté. Tapestry embarque maintenant la console JavaScript Blackbird.
Du côté des améliorations sur les templates, le chargement et le rendu des pages ont été optimisés, ce qui rend T5 plus rapide que jamais.
Vous pourrez aussi apprécier l’amélioration substantielle de l’archetype quickstart qui offre désormais une jolie interface, avec un design css intégré.
L’intégration de Spring est maintenant à double sens : on peut injecter des services Tapestry dans un Bean Spring.
Pour la prochaine version, qui sortira sans doute à la rentrée 2009, l’accent sera mis sur l’intégration de Spring Web Flow, et la possibilité d’utiliser une application Tapestry en tant que Portlet.

• Release note
• Site Maven du projet

Trucs et astuces Json – Restfull

Edwin Khodabakchian, fondateur de Collaxa (aujourd’hui au coeur de la stratégie SOA d’Oracle), nous donne quelques bonnes pratiques pour écrire des services web REST en utilisant Json (un couple qui a le vent en poupe). Actuellement lancé dans l’écriture de Feedly, une extension Firefox qui agrège des tweets et des entrés Google Reader, Edwin fera régulièrement profiter ses lecteurs de son expérience. Sans entrer dans les détails de ces bonnes pratiques, nous retiendrons l’astucieux découpage en 7 phases d’implémentation :

• Definir un service ou une ressource simple : définir le modèle Json et les 4 opérations REST et le servlet qui les fournit.
• Ecrire un client : utiliser le service avec un javascript simple. Cette possibilité est offerte par de nombreux frameworks, dont JQuery.
• Ajouter une étape de validation : modifier le service pour valider les ressources Json et utiliser les codes retour HTTP.
• Complexifier les ressources : modifier la hiérarchie d’Url pour servir des ressources plus riches. Tester la pérennité des ressources simples (phase 2).
• Ajouter un cache : améliorer les performances et la scalabilité de votre système.
• Implémenter la sécurité : utiliser une authentification web.
• Publier des événements business : pour découpler les processus REST des processus back-end. Les ressources REST sont traitées, un évènement business est lancé, qui déclenche le ou les traitements back-end.
• Gérer un cycle de vie pour les ressources : coupler un état de la ressource avec la phase de validation et la phase de publication des évènements.

Evènements de notre communauté en France et à l’étranger

Soirée Datagrid au Paris Jug

Le DataGrid au Paris Jug, c’est demain.
Pensez à réserver si ce n’est déjà fait.

Si le succès de Google Guice est assez limité face au raz de marée Spring, le constat est là : il manque un standard. Comme les deux librairies ne sont pas compatibles, si vous exposez à un autre projet/équipe une librairie contenant des dépendances injectées par Google Guice, et que l’autre équipe utilise Spring, elle devra redéfinir tous les beans et leurs dépendances dans un fichier de configuration Spring (ou des annotations Spring).

@Inject propose donc de standardiser les annotations, afin de rendre portables sur différents frameworks (Guice, Spring, Tapestry IOC, etc.) des classes injectables.

Pourquoi autant de bruit ?

Une autre JSR qui parle d’injection de dépendances a déjà passé le stade de la proposition, la JSR 299, ex-Web Beans, portée en particulier par Gavin King de Red Hat, auteur d’Hibernate. La JSR 299 va beaucoup plus loin (trop?) que l’injection de dépendances, sujet abordé dans de précédentes revues de presse.

La JSR 299 a déjà beaucoup fait parler d’elle, car elle a récemment été remaniée, afin d’être intégrée à temps à Java EE 6 (dont la spécification doit être terminée dans 3 mois). Vous pouvez lire les commentaires sur notre revue de presse du 26 Janvier dernier, dans laquelle nous nous étonnions de l’absence de SpringSource dans la JSR 299.

Quelques extraits de ces commentaires :

Emmanuel Bernard (JBoss) : « …SpringSource n’a jamais demandé à faire partie du groupe d’expertise… »
Emmanuel Bernard : « …JBoss a passé un temps énorme à construire JSR 299… »
Antonio Goncalves (Java EE 6 Expert Group) : « …la JSR 299 ne se transforme pas radicalement, je dirais plutôt qu’elle réduit sa voilure et se concentre sur son but initial : un contexte unifié entre les EJBs et JSF… »
Cyrille Le Clerc (Xebia) : « …une JSR qui se transforme radicalement, au point de changer de nom, pendant la phase de Public Review, après deux années et demie de travail intensif, cela me parait exceptionnel et peu rassurant… »

Bonne idée, mauvais timing ?

C’est dans ce contexte que Google et SpringSource décident de proposer @Inject. L’intention est légitime, et les deux acteurs sont sans aucun doute les plus expérimentés sur le sujet de l’injection de dépendances. Il semble en effet beaucoup plus aisé pour Guice, Spring ou autre framework d’implémenter une JSR de la taille de l’éventuelle JSR @Inject, alors qu’on les voit mal implémenter rapidement la JSR 299. Google et SpringSource suggèrent donc à la JSR 299 de ne plus spécifier l’injection de dépendances, et de réutiliser les annotations définies dans @Inject (extrait de la proposition : « JSR 299 is defining a dependency injection framework for Java EE, and might support these annotations.« ).

En revanche le timing nous semble vraiment mal choisi : cette spécification est proposée à quatre mois de la validation de Java EE 6 (Septembre 2009). Cela semblait déjà compliqué pour la JSR 299 (dont l’inclusion à Java EE 6 n’a toujours pas été votée), et @Inject ajoute très tard son grain de sel.
Même si Bob Lee pense pouvoir faire valider @Inject par le JCP en cinq mois, ou moins dans le cadre de Java EE 6, il est peu probable qu’@Inject fasse partie de Java EE 6 ; on n’a jamais vu de JSR consensuelle validée aussi rapidement, comment ferait une JSR polémique ? La JSR 299 fait quant à elle face à un planning de plus en plus serré. Le résultat des courses est sans appel : on « risque » donc de voir arriver une spécification Java EE 6 sans JSR d’injection de dépendances.

Hormis Gavin King (JSR 299 – JBoss) et Bob Lee (@Inject – Google) qui ont âprement débattu sur la blogosphère, les membres des expert groups de JSR 299 et Java EE 6 sont restés silencieux … comme Rod Johnson, co-inspirateur de @Inject (qui était sans doute bien occupé la semaine dernière).

Enfin, je vous suggère de prendre quelques minutes pour lire le « brouillon » de proposition de JSR @Inject. On y voit de nombreux noms connus et reconnus parmi les supporters de cette JSR (Joshua Bloch, Paul Hammant – ThoughtWorks & PicoContainer founder, Doug Lea, Tim Peierls, James Strachan, Hani Suleiman, Jason van Zyl – Maven Plexus, Thiago H de Paula Figueiredo – Tapestry IoC). @Inject ne propose que de standardiser les annotations, et ne décrit pas la manière dont les dépendances vont être résolues, ce sera à la charge du conteneur. Le périmètre fonctionnel de la proposition est donc très focalisé.

Sous vos yeux ébahis, une injection de dépendance sans Spring, sans Guice et sans JSR

Pour rappel, même si aucune JSR d’injection de dépendances n’est intégrée dans le futur à Java EE 6, vous avez le droit d’injecter vos dépendances vous même, sans Spring, sans Guice, par exemple avec un simple constructeur Java !

public class MyService {
	private MyDAO myDAO;
	public MyService(MyDAO myDAO) {
		this.myDAO = myDAO;
	}
}

Ce qui vous permettra d’y injecter bouchons ou mocks depuis vos tests unitaires.

Quelques liens sur le sujet

• l’annonce sur le blog de Bob Lee
• la réaction de Gavin King et les échanges avec Bob Lee dans les commentaires
• le projet @Inject sur Google Code
• Proposition de la JSR @Inject
• quelques (rares) commentaires intéressants sur TSS
• @Inject sur twitter

• Le démarrage d’une application est plus rapide avec une configuration IOC en annotations Java qu’avec une configuration XML à parser
• On peut tester unitairement les modules d’injection puisqu’il s’agit de classe Java simple
• Finie la configuration laborieuse en XML

J’ai même envie de rajouter que l’apprentissage d’une API Java est bien plus rapide que celui d’une syntaxe XML. Tout comme Guice, Tapestry IoC se concentre sur l’injection de dépendances et ne tente pas de fournir une stack complète de développement comme le fait Spring. On ne trouve ni les Aspects, ni le pattern Template cher à Spring. Pour répondre aux besoins de programmation par aspect, Tapestry IoC propose des interceptors qui peuvent décorer les services. D’autre part, dans Tapestry IoC, l’injection est définie dans un ou plusieurs module(s) chacun d’eux pouvant contribuer à la configuration et aux services de l’application.

Dans ce premier article de la série Tapestry 5 qui commence aujourd’hui, nous verrons les bases de l’injection avec Tapestry IoC et les différences par rapport à Spring et Guice.

L’injection par Builder

Pour commencer, prenons un service qui utilise un DAO.

public MyServiceImpl implements MyService {
  private final MyDao dao;
  public MyServiceImpl(MyDao dao){
     this.dao = dao;
  }
}
public MyAppModule {
  public static MyService build(MyDao dao){
    return new MyServiceImpl(dao);
  }
}

C’est la forme la plus simple de l’injection supportée par Tapestry. Ici on a directement la main sur l’instanciation du service. Notons que la classe MyAppModule n’implémente ou n’hérite d’aucune classe. Au lieu de cela, il suffit de fournir une méthode nommée ‘build’ que Tapestry utilise pour enregistrer le nouveau service. Si on veut fournir plusieurs services, on peut créer des méthodes buildXxx où Xxx prendra le nom à donner au service par exemple ‘buildMyDao’.

Pour ce qui est du paramètre dao, Tapestry injecte le premier service du même type qu’il trouve dans le registre. Cette méthode a le mérite d’être simple, mais ce n’est pas la méthode recommandée car elle force l’instanciation de tous les services au démarrage d’une part. D’autre part la méthode build est static ce qui n’est pas non plus recommandé notamment pour les tests unitaires.

Pour comprendre, il faut savoir que dans Tapestry, tous les services injectés sont en fait des proxies qui vont, par défaut, instancier le service à la première utilisation. Cela permet de charger l’application encore plus rapidement, de n’instancier que ce qui est réellement utilisé, et d’éliminer tout problème de dépendances cyclique.

Attention: Les services sont construits dans un scope ‘singleton’ par défaut où ‘per-thread’.

On joue ici sur les terres de Guice qui de son côté propose le bind to instance, équivalent. Bien sûr, on pourra faire un équivalent avec Spring en passant soit par une BeanFactory et du XML, soit par Spring JavaConfig @Bean.

Les Binders

Ici comme ailleurs, on peut activer le chargement retardé des services en passant par le Binder Tapestry. On va aussi pouvoir distinguer les différents services qui implémentent la même interface.

public MyAppModule {
  public void bind(ServiceBinder binder){
    binder.bind(MyService.class, MyServiceDaoImpl.class).withId("MyServiceDao");
    binder.bind(MyService.class, MyServiceXMLImpl.class).withId("MyServiceXML");
  }
}

Le ServiceBinder permet d’associer une classe à son implémentation. En plus de l’association interface-implémentation, on spécifie un identifiant qui distinguera notre service. Attention : l’identifiant du service doit être unique pour toute l’application (utilisez une ou plusieurs classes de constantes pour votre identifiants).

En revenant à notre classe MyServiceImpl, on peut se demander comment Tapestry va injecter le dao. C’est le constructeur avec le plus de paramètres qui est appelé. L’injection peut aussi être gérée par setter ou par des annotations de champs.

Si on imagine maintenant que plusieurs services implémentent l’interface MyDao, il faut récupérer la bonne instance avec @Inject.

public MyServiceImpl implements MyService {
  private final MyDao dao;
  @Inject
  private AnotherService otherService;
  public MyServiceImpl (@Inject("MyDao") MyDao dao){
     this.dao = dao;
  }
}

Avec l’annotation, on a choisi de récupérer le dao ayant pour identifiant « MyDao » dans le constructeur. On notera que le champ otherService est directement injecté sans passer par le constructeur. La méthode par constructeur est toutefois préférable pour obtenir des champs finaux et permettre l’injection de Mock dans les unitaires.
C’est également obligatoire pour les tests vraiment unitaires (en isolation) qui souhaitent remplacer « otherService » par un Mock ou un bouchon.

Faut-il le dire ? On voit clairement l’inspiration donnée par Guice, tant sur le ServiceBinder que sur l’annotation @Inject.

Attention: Contrairement à Guice et Spring, Tapestry IoC n’est pas sensible à la casse.

Tapestry recommande encore une autre méthode pour distinguer les services en utilisant les Markers. Il s’agit de créer une annotation qu’on utilisera à la place d’@Inject pour récupérer la bonne instance.

@Target(
{ PARAMETER, FIELD })
@Retention(RUNTIME)
@Documented
public @interface MyDaoHibernate
{
}
public MyAppModule {
  public static void bind(ServiceBinder binder){
    binder.bind(MyDao.class, MyDaoHibernateImpl.class).withId("MyDao").withMarkerId(MyDaoHibernate.class);
  }
}
public MyServiceImpl implements MyService {
  private final MyDao dao;
  public MyServiceImpl (@MyDaoHibernate MyDao dao){
     this.dao = dao;
  }
}

On a donc d’abord créé une annotation Runtime pouvant être appliquée sur des paramètres ou des champs. On l’a ensuite associée à la déclaration du service via le ServiceBinder. Enfin, on a injecté le paramètre du constructeur avec notre annotation marker.

Cette nouvelle approche peut paraître un peu lourde, mais elle a l’avantage de faciliter le refactoring et de réduire encore les risques liés à la configuration. Quoi que l’on fasse, il restera toujours des annotations à mettre dans le code source de nos services. Même si cette fois l’annotation utilisée vient de nos sources et pas d’un import tapestry5.ioc.XXX ce qui est moins intrusif il faut bien le reconnaître.
A mi-chemin entre la String de configuration et le Marker, utiliser une bonne vieille constante semble être un bon compromis.

Les modules

On en a vu un exemple plus haut, un Module est une classe POJO qui doit contenir des méthodes utilisant une convention de nom. Jusqu’à maintenant tous les exemples ont utilisé des méthodes statiques. Ce n’est absolument pas une obligation. On peut très bien utiliser des méthodes d’instance et stocker les services dans des champs pour réaliser un cache de services. Dans ce cas, l’injection des dépendances du module pourra se faire comme d’habitude dans le constructeur ou dans les champs.

Avec un peu d’aide, Tapestry IoC est capable de charger automatiquement tous les modules du classpath. Il suffit de les lister dans le Manifest du Jar. On ajoute donc une ligne à notre Manifest :

Tapestry-Module-Classes: org.example.mylib.MyAppModule, org.example.mylib.internal.InternalModule

C’est déjà bien, mais la liste des modules s’allongeant, cela peut vite devenir désagréable. Pour éviter de trop rallonger le Manifest, et pour se simplifier la vie, on va plutôt fournir une seule classe. Avec l’annotation @SubModule, on ajoute directement dans notre module ancêtre la liste des « sous-modules » à charger.

@SubModule({InternalModule.class})
public MyAppModule {
 /* ... */
}

Le registre, une fois lancé, pourra charger tous les modules du classpath. On voit déjà le gros avantage pour des plugins. Ils pourront par exemple être livrés séparément de notre application principale.

Les configurations

Un des points forts de Tapestry IoC est la notion de configuration distribuée. Le principe est de permettre d’une part, de passer une configuration à la construction d’un service. D’autre part, chaque module peut contribuer à la construction de la configuration de tous les services.

Imaginons par exemple un système d’export de fichiers associant un type à un FileExporter qui permet de générer l’export. Notre service fournit un PDFExporter et un CSVExporter. En basant notre FileExporterService sur une configuration, on pourra plus tard ajouter dans un autre module un WordExporter par exemple.

public MyFileExporterModule {
  public static FileExporterService buildFileExporterService(Map<String,FileExporter> contributions)
  {
    return new FileExporterServiceImpl(contributions);
  }
  public static void contributeFileExporterService(MappedConfiguration<String, FileExporter> configuration)
  {
    configuration.add("csv", new CSVFileExporter());
    configuration.add("pdf", new PDFFileExporter());
  }
}

On a créé un module publiant un service FileExporterService prenant une map de FileExporter en paramètre. On a pris soin d’ajouter à la map de configuration nos deux exports existants : le CSVFileExporter et le PDFFileExporter.

On peut maintenant ajouter un module fournissant un nouveau type d’export.

public static void contributeFileExporterService(MappedConfiguration<String, FileExporter> configuration)
  {
    configuration.add("doc", new DocFileExporter());
  }

Cette fois, c’est un objet de type MappedConfiguration qui doit être pris en paramètre pour être reconnu par Tapestry IoC.

Il existe trois types de configuration supportés par Tapestry :

• Configuration<T> liste non ordonnée d’objets, dans le builder on utilisera une Collection<T>
• OrderedConfiguration<T> liste ordonnée, dans le builder on aura une List<T>
• MappedConfiguration<S,T> dans le builder on aura une Map, les clés ne sont pas sensibles à la casse

Bien forcé de constater que ni Spring, ni Guice ne proposent quelque chose de similaire.

Lancer le registre

Il est temps d’utiliser nos modules dans une application. Il suffit de lancer le registre Tapestry en listant un, ou plusieurs modules à charger. On peut ensuite accéder à nos services.

public MyApplication {
  public static void main(String [] args) {
    RegistryBuilder builder = new RegistryBuilder();
    builder.add(MyAppModule.class);
    Registry registry = builder.build();
    registry.performRegistryStartup();
    MyService service = registry.getService(MyService.class);
    service.doSomething();
      //for operations done from this thread
    registry.cleanupThread();
      //call this to allow services clean shutdown
    registry.shutdown();
  }
}

La construction du registre n’est pas très compliquée, mais on peut déjà reprocher la lourdeur du système et l’absence de Helper pour faciliter la construction du registre. Devoir par exemple appeler successivement builder.build() puis registry.performRegistryStartup()
paraît étrange comparé à la concurrence.
Ce léger défaut est dû au fait que Tapestry IoC est plus fait pour le framework Tapestry 5 que pour une utilisation extérieure, historiquement en tout cas.

Pour conclure

Voilà un framework d’injection vraiment léger et facile à prendre en main. Du côté injection de dépendances, on apprécie la méthode par constructeur inspirée de Guice. Reste le problème des annotations dans les sources métiers qui sont trop intrusives à mon goût, même avec des Markers. Pourquoi ne pas permettre d’injecter les paramètres à fournir au constructeur directement dans le ServiceBinder du module ? Par contre, le chargement automatique des modules et la configuration distribuée, sont de réels plus auxquels on prend goût très rapidement.

Dans le prochain article, nous tenterons de mettre en avant les particularités de Tapestry IoC et ce que ce framework pourrait changer pour nous autres développeurs.

Pour aller plus loin

• Tapestry IoC
• Tapestry Wiki
• Tapestry Central

Nous entamons aujourd’hui une série d’articles qui a pour but de vous faire toucher du doigt la grande liberté qu’offre l’injection de dépendance par code. Nous irons progressivement des concepts de base de Guice 2.0, vers une utilisation avancée du framework.

Déclarer une dépendance avec l’annotation @Inject.

Prenons le postulat de départ suivant : la classe MyServiceImpl (qui implémente l’interface MyService) doit recevoir l’injection de la classe MyBasicDaoImpl (qui implémente l’interface MyBasicDao).
Dans le code source de la classe à injecter, nous allons donc indiquer que Guice doit s’occuper de cette injection, en utilisant l’annotation com.google.inject.Inject. Dans ce premier exemple, nous positionnerons cette annotation au niveau du constructeur.

En outre, nous déclarons un Appendable qui nous permettra de réaliser des traces. Cet appendable sera injecté directement dans la variable.

public class MyServiceImpl implements MyService {
	@Inject
	private Appendable recorder;
        private final MyBasicDao basicDao;
	@Inject
	public MyServiceImpl(MyBasicDao basicDao) {
		super();
		this.basicDao = basicDao;
	}
}

Vous remarquerez que grâce à l’injection par constructeur, nous sommes en mesure de déclarer la variable basicDao finale.

L’injection peut être réalisée au niveau du constructeur, d’une méthode voire même de la variable elle-même. Quelques avantages / inconvénients de ces différentes méthodes :

• Constructeur
• + Les variables peuvent être déclarées finales
• - Ne peut être utilisé si l’objet est instancié hors de Guice
• Méthode
• + Permet d’injecter un objet instancié hors de Guice
• + Les classes filles n’ont pas besoin de connaître les dépendances des classes mères.
• Variable
• + Syntaxe la plus compacte
• - Réduit la testabilité et l’encapsulation

La méthode recommandée par Google est l’injection par constructeur.

Lier une interface à son implémentation réelle, dans un Module

Il nous faut maintenant lier l’interface MyBasicDao à l’implémentation que nous souhaitons utiliser dans un premier temps, à savoir MyBasicDaoImpl.
Ceci se fait dans un module de configuration étendant com.google.inject.Module à l’aide d’un DSL relativement explicite.

public class MyModule implements com.google.inject.Module {
	@Override
	public void configure(com.google.inject.Binder binder) {
		// Bind to class
		binder.bind(MyBasicDao.class).to(MyBasicDaoImpl.class);
		binder.bind(MyService.class).to(MyServiceImpl.class);
		// Bind to instance
		binder.bind(Appendable.class).toInstance(System.out);
	}
}

Le Module permet de lier des interfaces à des classes que Guice se chargera d’instancier (_bind … to_) mais aussi à des classes déjà instanciées (_bind … toInstance_) comme c’est le cas pour notre Appendable, qui sera lié à la console System.out.

Récupérer une instance auprès de l’Injector

Dernière étape, il nous faut obtenir une instance injectée de notre service.
C’est auprès de la classe com.google.inject.Injector que nous la récupérerons. Cet injecteur est créé de manière statique, à partir d’un ou plusieurs Module.
Dans cet exemple, nous réaliserons cette opération à partir d’un main.

public class MyMain {
	public static void main(String[] args) throws IOException {
		Injector injector = Guice.createInjector(new MyModule());
		MyService myService = injector.getInstance(MyService.class);
		myService.displaySample();
	}
}

Et Spring dans tout ca ?

La question qui se pose dès que l’on aborde l’injection de dépendances est bien sûr ‘Oui, mais par rapport à Spring ?’.
Essayons d’éviter la réponse de normand, même si Spring et Guice ne jouent pas dans la même cour : Guice se concentre exclusivement sur l’injection de dépendances, alors que Spring vise à offrir une stack complète.
L’équipe de Guice répond d’ailleurs elle-même à la question sur son wiki.
Cependant, pour donner un point de vue plus pragmatique :

• le footprint du Jar du Guice est bien inférieur à celui (ceux) de Spring Core.
• le chaînage des Beans est plus rapide avec Guice, même si cet argument pèse peu, la majorité des dépendances étant chargées à l’initialisation de l’application.
• Guice est plus intrusif (apparition d’annotations dans le code source des services métier)
• la programmation orientée aspect de Guice est au stade embryonnaire.

Dans la suite de cette série d’articles, nous essayerons de montrer que la différence d’approche entre Guice et Spring offre plus de libertés aux développeurs (mais conduit peut-être aussi à plus de chaos).

La suite ?

C’est déjà la fin de ce premier tutoriel, et vous savez maintenant injecter simplement une classe. Cependant, dans le projet tel qu’écrit aujourd’hui, la classe MyBasicDaoImpl sera injectée dans toutes les classes nécessitant un MyBasicDao. Dans un prochain article, nous verrons comment lever cette limite.

Téléchargez le projet Eclipse sur le Google Code de Xebia

Ressources

Site officiel
Un comparatif de performances Spring / Guice, basé sur les versions précédentes

Actualité éditeurs / SSII

• Dans le cambouis de SpringSource dmServer

Agilité

• Les facteurs clés dans l’adoption d’une démarche Agile au niveau de l’entreprise.

RIA

• Sortie de Microsoft Silverlight 2.0
• Un flash Player 10 précipité pour la sortie de Silverlight 2 ?
• Testez unitairement et fonctionnellement vos applications Flex avec FlexMonkey

Le coin de la technique

• NetBeans vs Eclipse RCP : Comparaison des mécanismes d’extensibilité des plug-ins
• Java 6 Update 10 : Quoi de neuf docteur ?
• Noyés dans les annotations ?

Actualité éditeurs / SSII

Dans le cambouis de SpringSource dmServer

Après l’annonce de la sortie officielle la semaine dernière, SpringSource vous propose de découvrir les entrailles de la bête, par le biais d’une télé-conférence, le 29 octobre à 15:00 CET. Au programme :

• installation et configuration du serveur
• construction d’une application modulaire
• création d’un package déployable (PAR)
• développements itératifs et tests

Les liens d’inscription se trouvent sur l’annonce originale de SpringSource.

Agilité

Les facteurs clés dans l’adoption d’une démarche Agile au niveau de l’entreprise.

Dans le cadre de la conférence Agile 2008, Michael Mah se prête au petit jeu de la comparaison de productivité entre une entreprise Agile et une entreprise classique (devinez qui a la meilleure productivité).
Mais ce que nous retiendrons surtout de cette présentation, ce sont les cinq facteurs clés qui ont permis de convertir toute une entreprise (BMC) aux méthodes agiles :

• Avoir des éléments moteurs : avoir le soutien des cadres dirigeants, former des Scrums Masters, s’appuyer sur un noyau de convaincus / passionnés.
• Être toujours prêt à publier : faire des sprints courts de 2 semaines, des builds quotidiens, et porter l’effort sur des revues de codes régulières et exigeantes.
• Travailler en équipe 24h/24h : communiquer efficacement, s’armer d’outils efficaces (wiki, vidéo-conférences, réunions de visu régulières), organiser des Scrum de Scrum.
• Gérer son backlog : tenir un seul backlog partagé, mais plusieurs gestions ‘locales’ de celui-ci, nommer une seule équipe chargée de rédiger les user stories, se doter d’une équipe « d’architectes » pour interfacer la R&D et le backlog.
• Arrêter le développement WaterFall : passer à des développements pilotés par les tests (TDD), organiser des debriefings réguliers pour ne pas retomber dans les travers classiques, faire auditer les processus par un oeil externe.

Même si certains des points sus mentionnés portent à controverse (on pense en particulier aux TDD qui font débat), ces facteurs clés sont souvent mis en avant, en particulier par les fondateurs de la méthode Scrum, Ken Schwaber et Jeff Sutherland.

Retrouvez l’intégralité du vidcast et du support de présentation sur InfoQ.

RIA

Sortie de Microsoft Silverlight 2.0

Microsoft a annoncé cette semaine la sortie de Silverlight 2.

Lors de notre récent contest RIA dans lequel nous avions essayé de dégager les avantages et inconvénients de différents framework RIA, nous annoncions un certain nombre de points négatifs sur la version Silverlight que nous avions utilisée (Silverlight 2 Beta 2). Microsoft comble avec cette release officielle un certain nombre d’entre eux :

• Microsoft se rapproche du monde Java en proposant un ensemble d’outils permettant le développement Silverlight directement au sein d’Eclipse. Eclipse4SL, de son petit nom, est actuellement disponible en version alpha, la version finale étant prévue pour le printemps 2009. Eclipse4SL contiendra également un éditeur graphique permettant la manipulation et la visualisation du XAML.
• Microsoft prévoit également d’enrichir son catalogue de contrôles via le Silverlight Control Pack (SCP). Seront disponibles des contrôles du type Accordion, DockPanel, ViewTree ou AutoComplete sous la Microsoft Permissive License (open source).

Un flash Player 10 précipité pour la sortie de Silverlight 2 ?

Adobe a annoncé la semaine dernière la sortie de Flash Player 10 en release sous le nom d’Astro.

Cette nouvelle version comporte des améliorations graphiques et audio :

• Des nouveaux effets 3D plus fluides et plus performants.
• Des effets et filtres customisables par le biais de l’outil Pixel Bender.
• Gestion de traitement de texte avancé avec plus d’éléments typographiques.

Adobe a également pris en compte des demandes d’amélioration de la communauté Flash avec entre autres :

• plus de contrôles sur le menu contextuel: il est maintenant possible d’ajouter des items en texte riche.
• la manipulation de grandes images bitmap (jusqu’à 4096 par 4096)
• sortie de la version Linux en simultanée avec la version Windows, les problèmes spécifiques Ubuntu ont été réglés depuis la bêta
• les touches clavier du type Ctrl, Espace… peuvent maintenant être accessibles en plein écran: ce qui peut être pratique pour le développement des jeux Flash.

Vous pouvez retrouver la liste complète des fonctionnalités sur le site d’Adobe.

Comme le signale l’article publié sur le blog de Cedric Champeau, à la sortie du plugin un certain nombre de bugs persistent, la sortie simultanée de Silverlight 2 aurait-elle fait accélérer les choses ?

Testez unitairement et fonctionnellement vos applications Flex avec FlexMonkey

Une à une, les barrières au développement de Flex tombent. Dernière avancée, la mise en ligne d’un framework de tests automatisés, FlexMonkey. Pour InfoQ, Stu Stern (Gorilla Logic), fondateur du projet, revient sur les grandes lignes de ce projet OpenSource :

• Ne nécessite pas de plugin autre que le plugin Flash
• Possibilité d’enregistrer et de rejouer des tests (à la manière d’un Selenium), aussi bien que d’éditer le code source des tests, écrit en AS3
• Outil sous licence Apache2. Cependant, le framework utilise l’API Flex Automation, qui n’est disponible que sous Flex Builder Pro (qu’il vous faudra donc acquérir si vous souhaitez modifier FlexMonkey).
• Possibilité de simuler des évènements asynchrones avec un temps d’attente plus ou moins long.

L’application de démonstration est relativement bluffante pour un produit aussi jeune.
Alors, pourquoi ne pas laisser le singe tester votre RIA ?

Le coin de la technique

NetBeans vs Eclipse RCP : Comparaison des mécanismes d’extensibilité des plug-ins

Pour faire suite au Paris JUG de la semaine dernière, voici un bel exemple de débat entre choisir une solution standard de JavaSE ou l’utilisation de la plateforme OSGi. En effet, dans le monde des plateformes Rich-Client, Netbeans a choisi un mécanisme d’extensibilité qui s’appuie sur le ServiceLoader du JDK 6 au contraire d’Eclipse qui a préféré tout basculer sous OSGi et ses bundles.

Les avantages et les inconvénients des deux mécanismes sont présentés dans cet article où l’auteur semble avoir un léger penchant pour Eclipse.
Heureusement, les commentaires instructifs qui suivent, dont ceux du responsable technique de la documentation de NetBeans, Geertjan Wielenga, viennent alimenter le débat.

En quelques mots, Netbeans est simple d’apprentissage mais avec une mise en œuvre peu explicite et confuse. En face, Eclipse offre la rigueur de définition des bundles OSGi (très précise) mais avec une plus longue prise en main.

Java 6 Update 10 : Quoi de neuf docteur ?

Beaucoup de nouvelles fonctionnalités orientées utilisateur finale pour facilité le déploiement et l’exécution d’applet, parmi lesquelles :

• L’intégration de Java Quick Starter (JQS)
• Un service Windows (XP/2000) permet de précharger dans le cache disque de l’OS des fichiers les plus utilisés par la JRE, afin de permettre un démarrage à froid plus rapide.
• Next Generation Java Plug-in
• Ce plug-in, pour Internet explorer et Firefox 3, permet notamment de démarrer une applet depuis un fichier JNLP de la même manière qu’une application Java Web Start et d’améliorer la communication entre javascript et java (détection de version, téléchargement de la JRE…).
• Java Kernel
• Distribution allégée de la JRE, puis téléchargement à la demande des dépendances selon les applications chargées, pour permettre une réduction du temps de téléchargement et d’exécution initiale de la JVM.
• Possibilité de mettre à jour une même version majeure de la JRE, pour éviter la multiplication des installations et réduire les téléchargements.
• Réécriture de l’accélération Direct3D pour la plateforme Microsoft Windows, qui est désormais activée par défaut.
• Java DB 10.4 est dorénavant inclus dans la JRE.
• Nouveau Look & Feel Nimbus utilisant des graphiques 2D vectoriels à la place de bitmaps pour les composants permettant de mieux gérer le redimensionnement.

La liste complète des fonctionnalités sur le site de Sun.

Noyés dans les annotations ?

L’introduction des annotations a permis l’arrivée de la programmation déclarative en Java en ajoutant des metadatas à nos objets. Si la programmation déclarative est une bonne chose, l’utilisation des annotations à tout va engendre de plus en plus de bruits dans nos objets. Comme ce mécanisme se propage à la majorité des frameworks, vos beans se retrouvent noyés au milieu de dizaines d’annotations Spring / Hibernate / JPA / JUnit / EJB / JBoss Cache / Validation / GridGain / j’en passe et des meilleures …

Nous sommes loin de penser que leur utilisation est une mauvaise chose. Pourtant, il faut reconnaitre que les annotations sont souvent sur-utilisées. Il nous faudra par ailleurs faire d’autant plus attention dans le futur avec l’arrivée du Jdk 7 qui devrait permettre l’ajout d’annotations un peu partout dans le code :

• Map<@NotNull String, @NotNull List<@Readonly Document>> files;
• class Folder<F extends @Existing File> { }
• void monitorTemperature() throws @Critical TemperatureExceptuion { }
• String s = (@NotNull String) object;
• boolean isNotNull = myObject instanceOf @NotNull String;
• new @NonEmpty @ReadOnly ArrayList<String>()

Il est donc important de savoir utiliser les annotations à bon escient. C’est ce que nous propose l’auteur de cet article dont nous mettons en avant ici les principaux points.

L’utilisation des annotations est conseillée lorsqu’elles :

• Facilitent la configuration
• Évitent les interfaces inutiles et remplacent les interfaces ‘marqueur’
• Permettent la déclaration de métadatas interprétées au runtime

À l’inverse, il est déconseillé d’utiliser celles-ci lorsqu’elles :

• décrivent des informations spécifiques à un environnement (base de données / JNDI …)
• sont utilisées comme des macros

Au final, il sera difficile de trouver un consensus sur ce sujet polémique qui n’est pas sans nous rappeler d’autres critiques similaires.

Les 10 commandements des logs applicatives

Tout au long du cycle de vie d’une application J2EE, il est nécessaire de posséder des traces de qualité :

• durant le développement, afin de suivre l’exécution pas à pas et de détecter d’éventuelles anomalies.
• durant la recette, afin de corréler anomalies fonctionnelles et exécution du programme.
• durant l’exploitation, afin de surveiller la « bonne santé » de l’application.

Mais obtenir des traces de qualité n’est pas un exercice trivial. C’est pourquoi nous vous proposons nos 10 commandements des logs.

Lire cet article »

Simplifiez votre configuration Spring 2.5 avec les annotations

Spring 2.5 est sorti depuis le 19 novembre 2007 comme nous l’annoncions, il y a quelques temps, dans notre revue de presse. Vous avez comme moi sagement mis à jour vos poms Maven2 vers la dernière release de Spring (normalement et la plupart du temps compatible avec les versions 2.0.x).

Mais avez-vous vraiment profité des nouveautés de cette version en terme de configuration ?

Lire cet article »

Programmation concurrente : notions fondamentales

Jouer avec les Threads n’est pas trivial. En informatique de gestion, cette difficulté est heureusement masquée par les serveurs d’application et les API spécifiques. La plupart du temps, ils permettent aux développeurs de s’abstraire de ces contraintes et de se concentrer sur le code métier, moins technique. Il arrive pourtant qu’il faille se relever les manches. Certains besoins vous ont certainement déjà poussé à faire communiquer 2 Threads.
Si le développement n’est pas facile, le debug peut devenir une calamité ! La programmation concurrente ne soulève pourtant que 3 types majeurs de problèmes. Faites le sondage autour de vous, les développeurs associent trop rapidement le mot clé synchronize au multithreading sans en comprendre véritablement le fonctionnement. Demandez-leur ensuite de vous décrire l’utilité du mot clé volatile …

Cet article revient sur les grands principes de la programmation concurrente.

Lire cet article »

Les nouveautés Spring 2.5

Spring introduit plusieurs nouveautés concernant sa configuration, toutes les évolutions visant à la simplifier (ou à améliorer l’existant) :

• Ajout de nouvelles balises basées sur les possibilités d’extension de schéma de Spring (Exemple : L’ajout des namespaces jms, context ou l’amélioration des namespaces jee, aop)
• La création de JavaConfig
• Le support des annotations Java 5, déjà amorcé dans Spring 2.0

Dans cet article, nous nous concentrerons sur les possibilités de configuration avec les annotations mais sans éviter un ou deux écarts .

Configuration XML

Je vous parle d’annotations depuis le début de cet article, et le premier bout de code que je vous propose est en … XML. Eh oui, la prise en compte par Spring des annotations se configure encore en XML.

Mais heureusement avec l’extension de schéma ‘context’, cette configuration est très simple. Il suffit d’ajouter deux balises : la première sert à ajouter un certain nombre de BeanPostProcessor (voir la documentation), la seconde à définir le ou les packages (séparés par des virgules) que Spring va devoir parcourir à la recherche de nos annotations.

<beans
	...
	xmlns:context="http://www.springframework.org/schema/context"
	xsi:schemaLocation="
http://www.springframework.org/schema/context
http://www.springframework.org/schema/context/spring-context-2.5.xsd">
	<context:annotation-config />
	<context:component-scan base-package="fr.xebia.demo.wicket.blog.service" />
</beans>

La balise <context:component-scan> n’est requise que si nous utilisons les annotations ‘stéréotype’ de Spring. Il est possible d’être plus directif sur la recherche d’annotations dans les classes comme le montre l’exemple ci-dessous.

<context:component-scan base-package="example" use-default-filters="false">
   <context:include-filter type="aspectj" expression="example..Stub*"/>
   <context:include-filter type="annotation" expression="example.Mock"/>
   <context:exclude-filter type="annotation" expression="org.springframework.stereotype.Repository"/>
</context:component-scan>

Les stéréotypes Spring

Habituellement pour déclarer un bean géré par Spring, on devait ajouter une balise <bean name=...> dans notre fichier xml de configuration Spring. La balise <context:component-scan> vue précédemment indique à Spring qu’il doit rechercher dans le code certaines annotations que voici : @Repository, @Service, @Controller, @Component.

Ces annotations n’ont pas d’effet particulier sur l’injection de dépendances : elles servent entre autres à ‘catégoriser’ plus finement nos beans pour, en cas de besoin, appliquer des aspects plus facilement par la suite. Il faut voir ces annotations comme une bonne pratique à mettre en place pour donner du sens à nos beans.

• @Repository : Cette annotation existe depuis Spring 2.0 et sert à identifier un bean de type DAO.
• @Service : Celle-ci identifie le bean comme un service
• @Controller : Utile uniquement si l’on utilise SpringMVC, cette annotation indique un contrôleur Spring MVC.
• @Component : Cette dernière est l’annotation générique pouvant fonctionner pour n’importe quel bean

Autre avantage, Spring se sert de ces annotations pour appliquer lui aussi quelques aspects, comme par exemple, @Repository qui est pris en compte par Spring comme un marqueur pour la translation automatique d’exception pour la couche de persistance.

Voici un exemple très simple :

@Repository
public class ClientDAO {
    [...]
}

Chaque annotation prend un attribut ‘name’ optionnel qui peut être utilisé pour nommer explicitement le bean.

Ces annotations permettent de référencer nos beans dans le contexte d’application Spring pour qu’il puisse réaliser les injections de dépendances. Sans annotation, un bean n’est pas traité par Spring. Il existe une dernière annotation permettant de demander à Spring d’injecter des dépendances sur un bean qu’il ne gère pas : c’est l’annotation @Configurable. Spring ne va pas gérer le bean mais va quand même réaliser l’injection des dépendances sur celui-ci.

Pour modifier le cycle de vie de nos beans, il est aussi toujours possible de préciser le scope avec l’annotation du même nom : @Scope.

L’injection des dépendances

Nous venons de voir comment référencer nos beans dans le contexte d’application Spring. Nous allons étudier maintenant la façon de configurer l’injection de nos dépendances. Cela passe, bien sûr, par l’ajout de quelques annotations dans notre code. Il y a deux catégories d’annotations : les standards et les propriétaires Spring.

Le support de la JSR-250 et de JPA

La JSR-250 introduit plusieurs annotations permettant de déclarer un besoin d’injection de dépendances. Spring supporte l’annotation @Resource permettant la déclaration d’une ressource à injecter (cette annotation peut prendre l’attribut ‘name’ en paramètre). Dans la terminologie Spring, ce type d’injection est appelée ‘by-name’. Pour déclarer une dépendance comme obligatoire, on ajoutera l’annotation @Required. Dans cette JSR, il existe deux autres annotations prises en charge par Spring : @PreConstruct et @PostDestroy qui remplace l’utilisation des interfaces InitializingBean et DisposableBean.

Ces annotations sont disponibles en standard dans le jdk6. Si vous utilisez le jdk5, vous devrez obtenir le jar à cet url ou si vous utilisez maven, la dépendance à ajouter est la suivante javax.annotation:jsr250-api:1.0.

JPA de son côté introduit lui aussi quelques annotations supportées par Spring : @PersistenceUnit qui permet l’injection d’un EntityManagerFactory et @PersistenceContext (ou @PersistentContext{+}s+) pour l’injection d’un EntityManager.

Les annotations spécifiques Spring

Spring permet aussi l’utilisation de l’annotation @Autowired qui lui est propre. Cette annotation fonctionne comme le @Resource sauf qu’ici Spring fera de l’injection ‘by-type’ c’est à dire en se basant sur la classe du bean à injecter. Il n’est ici pas possible de préciser un nom de bean explicitement. Il est par contre possible d’utiliser l’annotation @Qualifier pour permettre à Spring de choisir la bonne dépendance. Avec cette annotation on précise des qualifiers à la fois sur les beans managés et sur les attributs ou sur les méthodes où Spring doit injecter des dépendances : Spring trouvera le meilleur candidat à l’injection en s’aidant de ces qualifiers si besoin.

Pour déclarer une dépendance comme obligatoire, on utilisera l’attribut required de l’annotation @Autowired.

Pour faciliter le travail du transaction manager, l’annotation @Transactional peut être positionnée sur une classe ou sur les méthodes qui la composent pour préciser à Spring quelles méthodes doivent s’exécuter dans une transaction (sans oublier d’ajouter <tx:annotation-driven transaction-manager= »txManager »/> avec votre fichier de configuration XML). L’annotation prend plusieurs attributs permettant de configurer le comportement transactionnel à appliquer.

A-t-on encore besoin de fichier XML ?

Avec l’introduction des annotations, a-t-on encore besoin de fichiers XML pour configurer Spring ? La réponse est bien sûr ‘oui’ puisqu’il reste nécessaire pour configurer la prise en compte des annotations. Cependant, ces annotations permettent de beaucoup simplifier et d’alléger le fichier de configuration. Seul le strict nécessaire subsistera : la configuration et la déclaration des ressources communes à tous les beans ainsi que la création des beans que nous ne développons pas (et donc sur lesquels nous ne pouvons pas positionner d’annotations).

Notamment, la configuration et l’utilisation d’AOP ainsi que la déclaration du transaction manager, d’Hibernate ou de JPA sont les éléments qui peuvent rester dans le fichier de configuration XML classique.

Ressources

• http://www.infoq.com/articles/spring-2.5-part-1
• http://static.springframework.org/spring/docs/2.5.x/reference/beans.html#beans-annotation-config
• http://www.springframework.org/schema/context/spring-context-2.5.xsd

J’ai assisté, il y a peu, à une excellente présentation de l’AOP et de AspectJ plus particulièrement. J’ai tout de suite été séduit et j’ai donc cherché des applications pratiques pour ce genre de technologie.
Le cas d’école pour apprendre l’AOP que l’on trouve régulièrement est l’exemple du logging.

public aspect LoggerAspect {
	pointcut log() : call(* *.methodToLog(..));
	before() : log() {
		System.out.println("Avant l'exécution de"+thisJoinPoint.toShortString()) ;
	}
	after() : log() {
		System.out.println("Après l'exécution de"+thisJoinPoint.toShortString()) ;
	}
}

Cet aspect affiche un message avant et après l’appel de la méthode.

Je vous propose ici de modifier cet exemple pour effectuer des mesures de performance dans une application.
Pour cela nous pouvons utiliser JAMon qui permet de positionner simplement des prises de mesure et de les consulter au travers d’une application web fournie. Dans JAMon, on utilise des Monitor auquel on associe un nom logique.

Pour notre prise de mesure, nous voulons savoir combien de temps on passe dans telle ou telle partie de code. A la différence de l’exemple du login, le pointcut que nous allons définir va utiliser le mot-clé execution plutot que call pour se positionner au plus près du code exécuté.

La définition du _poincut_ sera d’autant plus simple si le code que l’on doit monitorer a été contraint par des règles de nommage ou si les éléments du code utilise ou hérite d’un framework.

Exemple :

pointcut monitor() : execution(* *.*Service.*(..)) ; // Correspond à toutes les méthodes des classes qui finissent par <em>Service</em>
pointcut monitor() : execution(* *.GenericService+.*(..)) ; // Correspond à toutes les méthodes des classes qui héritent de la classe <em>GenericService</em>
pointcut monitor() : execution(* *.services.*.add*(..)) ; // Correspond à toutes les méthodes qui commencent par <em>add</em> des classes qui sont dans le package *.services.*

Ensuite, Il faut définir l’advice. Nous voulons savoir combien de temps prend l’exécution des méthodes correspondant au pointcut. Nous utiliserons donc le mot-clé arround() qui permet d’effectuer des pré\- et post-traitements.

Puisque nous allons positionner ces prises de mesure avec de l’AOP, nous utiliserons thisJointPoint.toShortString() (qui donne le nom court du pointcut) comme nom pour le Monitor JAMon que nous positionnerons.

Voici l’exemple complet :

public aspect PerfMonitor {
	pointcut monitor() : execution(* *.ClassToMonitor.methodToMonitor(..)) ;
	Object arround() : monitor() {
		Monitor monitor = MonitorFactory.start(thisJoinPoint.toShortString());
		Object returnedObject = proceed();
		monitor.stop();
		// Si on veut avoir une trace de la mesure dans les logs
		// LogFactory.getLog(getClass()).debug(monitor.toString()) ;
		return returnedObject;
	}
}

Une fois, notre aspect définit, nous allons pouvoir voir ce que donne notre prise de mesure.

La distribution de JAMon contient une application web qui permet de visualiser les statistiques des différents Monitor positionnés dans le code.

Pour que cela fonctionne simplement, il suffit de déposer le fichier jamon.jar dans le répertoire de librairie partagée (ex: common/lib sous Tomcat) afin que les classes de JAMon soient chargées par le « system class loader ». Ensuite, déployer l’application web jamon.war comme n’importe quelle application.

Une fois votre application démarrée, vous pouvez accéder à la page http://webserver/jamon/jamonadmin.jsp pour voir les statistiques produites par le monitoring de votre code.

Voici un exemple du rendu de cette page :

Remarque : JAMon fournit d’autres possibilités de prise de mesure :

• le ServletFilter JAMon qui va mesurer le temps de chargement de chaque page pour avoir un aperçu global des performances de l’application.
• le JAMonDriver ou la JAMonDataSource qui encapsule le vrai driver JDBC pour mesurer les accès à la base de données.

Ce genre d’outil est surtout en mode « diagnostic » pour trouver et optimiser les traitements coûteux plutôt que pour effectuer de véritables tests de performance sur une application.
L’avantage de le combiner avec de l’AOP, c’est de permettre de « monitorer » des traitements dont nous n’avons pas le code source.

L’outil Glassbox qui permet de faire des prises mesures automatiquement dans une application se base justement sur l’AOP pour positionner ses messures.

Google a adopté dans Guice la configuration tout en Java : tout ce fait à base d’annotations et de l’API. De fait, il n’y a plus de fichier de configuration XML.

C’est encore un des reproches que l’on entend sur Spring : on déporte beaucoup de choses dans un fichier XML qui ne compile pas et pour lequel on n’est pas assisté.

Dans le même ordre d’idée, Les nouvelles annotations créées avec JPA (Java Persistence API) changent aussi notre façon de configurer Hibernate. Avant, on configurait tout dans le bon vieux hibernate.cfg.xml, maintenant on a la possibilité de le faire avec les annotations.

Maintenant que nous avons le choix : quelle solution doit-on préférer ? Java ou XML ?

Configuration en Java (API + Annotations)

Pour

• Compilation (vérification des liens et de l’existence des classes par le compilateur)

• Code-completion

• Simplicité et concision (par rapport au XML)

• Refactoring simple

Contre

• Tout changement entraîne une recompilation

• Configuration répartie dans le code

Configuration en XML

Pour

• Souplesse : Permet d’effectuer des changements sans impact sur le code (et sans recompilation)

• Pas de couplage fort du code avec le framework

• Configuration centralisée

Contre

• Perte de lisibilité

• Source d’erreur

• Refactoring manuel (Search & Replace)

En synthèse