Sur certains projets, j’ai eu l’occasion de voir des fichiers de configuration Spring de ce type :

Et bien évidemment, chacun des fichiers de configurations importés était tous semblables, avec comme seule différence les noms de beans Spring ou des valeurs de propriétés.
Si demain, un nouvel environnement devait être ajouté, je vous le donne dans le mille : un copier / coller, un s/environnement1/nouvel-environnement/g !

Même si cela fonctionne bien, ce n’est pas la solution la plus propre : Si le système de monitoring devait être modifié, il faudrait éditer X fichiers, avec le risque d’oublier un fichier, ou un valeur…

Solution 1 : Créer un namepace dédié au monitoring

Une première solution possible serait de remplacer ces imports par un namespace dédié au monitoring. Il suffirait dès lors d’utiliser une configuration de ce type :

C’est déjà beaucoup plus propre, mais cette solution n’est pas des plus pratiques :

La configuration « générique » sera réalisée via une API spécifique à Spring, que peu de développeurs connaissent ( BeanDefinitionParser, ParserContext, BeanDefinitionRegistry, ..), ce qui rends toute modification assez complexe
Le namespace sera dédié au monitoring ! Si le domaine des fichiers était tout autre, il faudrait développer un nouveau namespace.
Le namespace va cacher aux utilisateurs les beans réellement instanciés.
Bref, c’est déjà mieux mais pas encore suffisamment claire et simple.

Solution 2 : Créer un namepace d’importation de modèles de configuration

Afin de répondre à ces problématique, il est possible de créer un namespace beaucoup plus générique. Celui qui permettrait d’importer une configuration classique (un modèle), mais en remplaçant certaines variables par des valeurs.

Le modèle serait un fichier de configuration Spring tout à fait compréhensible par des habitués de Spring, mais dans laquelle des variables seraient définies :

Ici, ${environnement}, est une variable qui sera définie lors de l’importation du modèle :

Conclusion

Cette solution possède donc plusieurs avantages :

En cas de modification du modèle, un seul fichier devra être modifié.
Le namespace pourra être utilisé pour différent domaine ( monotoring, etc .. )
Le modèle sera modifiable par n’importe quel développeur connaissant Spring, et tout à fait lisible

Informations

Ce projet est disponible sous licence Apache 2 sur http://code.google.com/p/spring-import-template/

Et comme pour la première fois, ce livre couvre des sujets inédits comme Spring Dm et la technologie OSGi, ou le nouveau serveur Spring Dm Server permettant de tirer parti de cette dernière.

Mais ce n’est pas tout, il est l’un des tout premiers livres à couvrir Spring 3.0 ( toute langues confondues, ce qui n’est pas rien ! ). Pour rappel, cette version n’est pas encore officiellement sortie.

D’autres sujets ont de leur coté été mis à jour, c’est le cas de Spring MVC, se basant maintenant sur le jeu d’annotations ou le nouvellement nommé Spring Security, successeur de Acegi.
Spring Batch fait aussi parti des sujets traités.

Bref, un pur bonheur pour ceux qui ne connaissent pas Spring, mais aussi un excellent livre pour ceux utilisant Spring 2.0 et voulant se remettre à niveau.

Quelques informations :

Sortie eBook : 23 Juin 2009, disponible sur izibook
Sortie papier : le 7 juillet 2009

Critique du livre, en avant première

Bonne lecture et n’hésitez pas à venir faire vos commentaires

Les deux livres proposés furent : Pro Spring 2.5 et Spring Recipes : A problem-Solution approach

Après lecture des deux ouvrages dans leur langue d’origine, il est resorti que le meilleur choix était Spring Recipes. Sa particuliarité est de ne pas présenter Spring à la manière d’une documentation mais plus en exposant des problèmes, et en proposant une solution pour laquelle Spring est intégrée, et pourquoi il l’est.

Une bonne nouvelle pour les personnes réfractaires à l’anglais, Pearson vient d’annoncer la disponibilité de la traduction. Celle-ci comporte les deux premières parties de l’ouvrage original, traduites par Hervé Soulard.

Pour plus d’information :

Présentation sur le site de Pearson Education
Table des matières
Extrait du chapitre 1 – Inversion du contrôle
Extrait du chapitre 8 – Gestion des transactions
Annonce sur le site de SpringSource

Le premier est Spring Framework qui à largement contribué à la popularisation de ce concept. Le principe original de celui-ci était de créer des POJOs, et de lier ceux-ci via un fichier XML.

L’intérêt premier était que les classes était très peu liées ni même au framework Spring.

Quelques temps plus tard, Google Guice est arrivé avec une autre technique.
Le(s) fichier(s) XML devenant parfois très long, et n’était pas directement géré par les outils de refactoring, un sytème d’injection basé sur des annotations fut préféré par Google.

Ce système gagna un certains succès, et SpringSource à donc repris l’idée en proposant un set d’annotations aussi pour gérer les dépendances.

Que l’on aime ou pas les annotations, elles ont un gros défaut : elles lient directement le code métier au framework d’injection de dépendances !

Afin de résoudre ce problème, les deux Gurus ont décidé de travailler ensemble sur une nouvelle JSR pour standardiser l’injection de dépendance.

Pour l’instant, cette JSR ne comporte qu’un jeu très restreint d’annotation :

• @Inject
• @Qualifier
• @Scope
• @Named
• @Singleton

Je trouve cette initiave intéressante, mais il faut encore voir quelles fonctionnalités des frameworks seront mis en place dans cette JSR.

Spring, et certainement Guice, proposent plus que de l’injection de dépendance ( AOP, gestion des transaction, … ).

Si la JSR se limite à l’injection, on finira tout de même par utilisé des fonctions propres à l’implementation .. et donc le code ne sera de nouveau liés à un framework.

Plus d’information :

Blog Google
Blog de Nicolas De Loof
Draft de la spécification

La première concerne SpringSource Tool Suite. Cet packaging d’Eclipse proposant divers outils pratique pour le développement avec Spring mais aussi OSGi avec Spring dm Server est proposé gratuitement. Avant cela, il était disponible uniquement pour les clients du support.

La deuxième concerne un nouveau projet dans le portfolio Spring : Spring Roo ( prononcez Rou, comme Kango-roo ).
Derrière ce nom farfelu se cache un Grails ( ou un Rail ) pour Java !

N’ayant pas encore eu le temps de jouer avec, je vous conseille la lecture de cet article ou bien celui-ci ( en anglais, mais écrit par un des développeur de Spring Roo ).

Bonne lecture !

La première catégorie est celles des formations orientées « Equipe de Developpement ». Celle-ci regroupe les formations sur Spring, Groovy&Grails, OSGi et ActiveMQ.

La deuxième concernant l’équipe de production et comporte des formations sur l’administration et l’optimisation de Tomcat, Apache HTTP ainsi que sur Tc Server.

Mais la grosse nouveauté est l’apparition de deux nouvelles certification :

SpringSource Certified Enterprise Integration Specialist : JMS, Service Web ( SOAP et REST ), ..

SpringSource Certified Web Specialist : Spring WebFlow, Spring JavaScript, Spring Faces

=> Télécharger
=> Annonce
=> Documentation
=> Changelog

Cette version apporte un nouveau namespace afin de faciliter la configuration du framework :

<!-- Configuration du messageBroker ( remplacement du MessageBrokerFactoryBean ) --> 

<flex:message-broker services-config-path="classpath*:services-config.xml"      

 

<!-- Configuration du messageBroker ( remplacement du FlexRemotingServiceExporter ) --> 

<flex:remote-service ref="monBeanService" />

L’autre importante nouveauté est la gestion de la sécurité avec Spring Security.

Pour rappel, cette version se base sur Java 5 mais reste compatible J2EE 1.4 et JEE 5.

Parmis les nouveautés :

• Plus de fonctions de type Java 5 utilisant les Collections et Map génériques, plus de FactoryBean générifiés
• Mise à jour l’API de concurrence de Spring (TaskExecutor) utilisant les nouvelles fonctionnalités de Java 5
• Ajout du module OXM (Object/XML Marshalling) dans Spring Core. Ce module provient à l’origine du projet Spring WS, et permet une intégration facile des outils de marshalling ( JAXB, JiBX, Castor, XMLBean et XStream ) dans une application.
• Ajout d’un client REST (RestTemplate)
• Spring Portlet MVC se base dorénavant sur le standard Portlet 2.0
• Ajout d’un support basique de JPA 2.0

Par contre, il n’y a pas encore de documentation officielle pour la milestone 2.

Concernant la milestone 3, celle-ci devrait ajouté le support de la validation déclarative (JSR-303 BeanValidation), de nouvelles annotations, de nouveaux namespaces ( ORM, scheduling ). Spring MVC quand à lui va se voir refondre le système de gestion des conversation.

Pour rappel, cette version se base sur Java 5 mais reste compatible J2EE 1.4 et JEE 5.

Parmi les grands changements

• Une nouvelle structure pour le projet ainsi qu’un nouveau système de build
• Mise à jour du code pour utiliser pleinement Java 5 ( Generics, varargs, … )
• Support des expressions languages pour la configuration
  • Utilisation de #{} dans les fichiers XML
  • @Value pour l’utilisation directement dans le code
• Début du support de REST
• Utilisation d’un déport Subversion à la place de l’ancien CVS

Liens

=> Télécharger
=> Annonce
=> Javadoc
=> Documentation
=> Changelog

En Java, l’envoi d’email passe par l’API JavaMail. Celle-ci est très puissante, mais n’est pas des plus simple à utiliser.
Mais si par chance, vous travaillez déjà avec Spring Framework dans votre projet, vous pourrez facilement envoyer des emails sans connaitre JavaMail.

Pour mon exemple, je vais créer un service qui aura la responsabilité d’envoyer un email lorsqu’une erreur surviendra.
Pour cela, nous allons tout d’abord définir le contrat du service

Une fois cela fait, nous allons créer une implémentation, utilisant les classes d’aides de Spring :

Vous pouvez voir qu’une instance de MailSender est injectée ( Point 1 ). Cette interface fait partie du framework Spring et est est le point d’entrée de l’API Spring pour l’envoie de courrier électronique. Cette interface possède deux méthodes permettant d’envoyer un ou plusieurs messages:

Ces messages devant être du type SimpleMailMessage, il est donc nécessaire de créer une instance de ce type ( Point 2 ).
Il ne nous reste plus qu’a remplir les informations de l’email : adresse de destination, adresse d’origine, le sujet et le texte ( Point 3 ).

La dernière étape consiste à utiliser le MailSender pour envoyer le message ( Point 4 ).

Il ne nous reste plus qu’à fournir l’implémentation du MailSender à notre service pour que le tout fonctionne.
Cet étape étant purement de la configuration Spring :

L’implémentation utilisée est de type JavaMailSenderImpl, et donc nous retrouvons bien l’API de base JavaMail sans avoir à connaître son utilisation directe.

Cela dit, cette première version n’est pas complète. En effet, si le texte et le sujet des emails envoyés sont clairement des données dynamiques, l’origine et la destination pourraient être externalisée dans le fichier de configuration XML.

De plus l’utilisation de SimpleMailMessage ne permet pas l’utilisation du format HTML ni même les fichiers attachés.
Une version plus évoluée du service vous sera présenté dans un prochain billet.