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.

Bref, quand je dis quelques temps, il faut comprendre il y a presque qu’un an .. depuis lors, j’ai eu pas mal de choses sur le cotés qui m’ont empécher de finir d’étudier et de passer la certification. Mais il y a quelques semaines, j’ai voulu vérifier la validité de mon voucher pour l’examen, et il arrivait à terme sous peu.

Et au lieu de laisser le bon expirer dans le tiroir, j’ai fixé une date pour l’examen, et j’ai tenter d’étudier quand j’en avais le temps histoire de ne pas arriver devant l’examen sans avoir revu un peu la matière.

Cet examen à eu lieu hier, et je dois dire que je ne me sentais pas prêt du tout, vu le peu de temps que j’ai eu au final.
J’ai finalement réussi cet examen, avec un score de 85%.

Pour ceux qui seraient intéressés, je me suis basé sur ces références :

J2EE WebServices
BluePrints
XYZWS ( avec Mock Exam gratuit )

Bonne chance à ceux qui tenteront cette certification !

Si vous avez déjà joué avec cela, j’aimerai votre avis !

En effet j’ai ceci, basé sur l’exemple dans la doc :

Un Customizer :

public class MyCustom implements GroovyObjectCustomizer {
    public void customize(GroovyObject groovyObject) {
        System.out.println("Customization");
        DelegatingMetaClass meta = new DelegatingMetaClass(groovyObject.getMetaClass()){
            public Object invokeMethod(Object o, String s, Object o1) {

                System.out.println("Invoke Method 1");
                return super.invokeMethod(o, s, o1);    
            }

            public Object invokeMethod(Object o, String s, Object[] objects) {
                System.out.println("Invoke Method 2");
                return super.invokeMethod(o, s, objects);    
            }
        }   ;

        meta.initialize();
        groovyObject.setMetaClass(meta);
    }
}

Un bean groovy

class MyObject implements Runnable {

    public void run() {
        print "Run !"
    }

}

Ce fichier de configuration :

  <lang:groovy id="test" script-source="be/hikage/groovy/MyObject.groovy" customizer-ref="custom"/>

    <bean id="custom" class="be.hikage.groovy.MyCustom"/>

Et une application test

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

        Runnable run = (Runnable) context.getBean("test");

        run.run();

En lance cela, je m’attendais à voir un « Invoke Method 1″ ou un « Invoker Method 2″, mais rien, comme si cela ne passait pas du tout par ma metaclasse.

Et si je caste l’objet en GroovyObject et que j’effectue l’appel manuellement, la c’est bien invoqué.

Avez vous déjà remarqué ce problème ?

Je commence donc :

• Création du composant
• Création du renderer
• Création du Tag
• Ajout dans faces-config des composants
• Création de la taglib

Bref, je déplois une page de test, et pas de bol, ca ne marche pas..

Après quelques recherches, je découvre qu’avec Facelet, le « Tag » n’est pas utilisé, et donc la méthode setProperties non plus. Le problème qui en survient, est que les expressions languages sont directement passée via setValueBinding au composant, et non plus « traitée » par le Tag.

Il faut donc faire une vérification au niveau du composant, dans les accesseurs, pour vérifier si une ValueBinding n’existe pas pour la propriété :