Wiser est un petit serveur SMPT facilement intégrable dans une classe de test unitaire (Junit, TestNg, etc.). Il réceptionne les messages et les sauvegardes dans un tableau au lieu de les envoyer sur le réseau. Ces messages sont ensuite disponibles pour vérification.
Avec ce serveur, il est possible de vérifier tous les types de mails même ceux qui contiennent des pièces jointes. Il est développé dans le projet subethasmtp.
Dans un projet maven il est nécessaire d’ajouter les dépendances suivantes :
Il faut, ensuite, écrire une méthode qui va envoyer un email et la tester dans une classe JUnit. Je vous propose d’utiliser JavaMail. Remarque : vous pouvez aussi envoyer un email à partir d’un logiciel comme thunderbird s’il est configuré avec Wiser comme serveur SMTP.
/**
* Méthode qui envoie un email.
*/
public void sendEmail(String serveur, int port) throws AddressException, MessagingException {
Properties prop = System.getProperties();
prop.put("mail.smtp.host", serveur);
prop.put("mail.smtp.port", String.valueOf(port));
Session session = Session.getDefaultInstance(prop,null);
InternetAddress[] internetAddresses =
new InternetAddress[] {new InternetAddress("toi@xxx.com")};
Message message = new MimeMessage(session);
message.setFrom(new InternetAddress("moi@xxx.com"));
message.setRecipients(Message.RecipientType.TO, internetAddresses);
message.setSubject("Test");
message.setText("test mail");
Transport.send(message);
}
/**
* Démarrage de Wiser avant l'éxécution du test.
*/
@Before
public void setUp() {
wiser = new Wiser();
wiser.setPort(2500); // port par défaut : 25
wiser.start();
}
@After
public void tearDown() {
wiser.stop();
}
@Test
public void testSendEmail() {
try {
sendEmail("localhost", 2500); // Appel de la méthode qui envoie l'email.
assertEquals(1, wiser.getMessages().size());
for (WiserMessage message : wiser.getMessages()) {
String envelopeSender = message.getEnvelopeSender();
String envelopeReceiver = message.getEnvelopeReceiver();
MimeMessage mess = message.getMimeMessage();
// Il ne reste plus qu'a vérifier le contenu de l'email.
}
} catch (Exception e) {
fail();
}
}
Pour installer WordPress 3.2.1, il faut disposer d’une version de PHP supérieure ou égale à 5.2.4. Or, sur l’hébergement de free.fr, la version proposée est 5.1.3RC4-dev. Votre blog vous affiche donc le message d’erreur suivant dès la première connexion :
Votre serveur utilise la version 5.1.3RC4-dev de PHP mais WordPress 3.2.1 nécéssite au moins la version 5.2.4.
Heureusement, en suivant ce tutoriel il est possible de contourner le problème. Vous pouvez télécharger ici la version patchée de WordPress qui fonctionnera directement sur les pages perso de free. Elle contient les modifications suivantes :
Modification de la vérification de la version du PHP
Suppression du paramètre httponly dans d’appel de la méthode setcookie
Implémentation de deux méthodes qui n’existaient pas encore dans la version php de free
—EDIT le 05/09/2011
Après quelques tests, il s’avère que l’ensemble de la gestion des dates utilise la librairie PHP 5.2 et supérieure ce qui provoque ce genre d’erreurs :
Fatal error: Call to undefined function timezone_open()
Fatal error: Call to undefined function timezone_offset_get()
Fatal error: Call to undefined function date_create()
etc.
J’ai donc redéfini quelques méthodes pour pouvoir lister et rédiger des articles. Il reste néanmoins d’autres erreurs à d’autres endroits (par exemple la prévisualisation d’un article) toujours à cause de la gestion des dates…
A chaque fois que j’essaie de configurer un tomcat derrière un serveur apache, je tombe toujours sur les mêmes problèmes, je perds toujours du temps à retrouver les mêmes solutions dans les documentations. C’est pour cela que j’écris cet article que j’espère le plus simple et pratique que possible.
Déposer le fichier mod_jk.so (qui se trouve dans l’archive téléchargée) dans le répertoire $APACHE_HOME/modules/. Pour configurer ce connecteur, deux fichiers sont nécessaires
workers.properties : permet au connecteur de se connecter au serveur tomcat.
httpd.conf : permet au connecteur de rediriger les requêtes HTTP vers le serveur tomcat.
Voici un fichier worker.properties exemple :
# La liste des workers
worker.list= worker1, jkstatus
# Configuration du worker1 : connexion à tomcat
worker.worker1.type=ajp13
worker.worker1.host=localhost
worker.worker1.port=8009
# Configuration de jkstatus : agrège des statistiques sur le connecteur
worker.jkstatus.type=status
Voici quelques lignes à ajouter au fichier httpd.conf pour configurer mod_jk :
Une fois cette communication faite il faut rendre les applications tomcat visibles depuis Apache. Cette étape peut être aussi bien réalisée à partir du fichier httpd.conf que worker.properties. Par exemple, voici la directive à ajouter au fichier de configuration du serveur Apache :
Il existe beaucoup d’autre façons de configurer ces deux serveurs. Pour plus d’information voici quelques sites qui décrivent dans les détails les différentes configurations possibles :
JBoss propose un certain nombre d’archetypes dont un qui génère une application J2EE6 pour JBoss 7 : org.jboss.spec.archetypes:jboss-javaee6-webapp. Or, par défaut, maven ne connait pas cet archetype. Voici comment réussir à l’utiliser dans Eclipse.
Avant toute chose, il faut vérifier que maven est configuré pour aller chercher des librairies sur le repository JBoss : le fichier settings.xml (~/.m2/settings.xml ou $MAVEN_HOME/conf/settings.xml) doit contenir le code XML suivant :
Ensuite, pour créer le projet dans Eclipse, il faut commencer par installer le catalogue JBoss : Windows -> Preferences… puis dans la fenêtre Maven -> Achetypes cliquer sur le bouton Add Remote Catalog… Saisir https://repository.jboss.org/nexus/content/groups/public/archetype-catalog.xml dans l’intitulé Catalogue File et JBoss dans Description. Après l’opération, il ne reste plus qu’à accéder au wizard de création d’un projet Maven (File -> New -> Project… puis Maven project) et de sélectionner l’archetype jboss-javaee6-webapp.
Ce qui équivaut à une application de départ avec un exemple JSF2 s’appuyant sur une base de données embarquée avec quelques classes constituant un modèle MVC, un exemple de service web REST, et un exemple de test unitaire avec Arquillian. A noter aussi, l’utilisation d’un EJB3 archivé dans un WAR et non un EAR comme il aurait fallu le faire avec J2EE5.
Pour déployer l’application il faut la packager et utiliser le plugin JBoss de déploiement déjà configuré par l’archetype (maven package jboss-as:deploy). Attention, pour que tout se déroule correctement, il faudra avoir démarré votre serveur JBoss7 au préalable.
J’ai eu l’occasion de travailler sur plusieurs outils de build très différents comme MakeFile, Ant ou Maven. Chacun possède ses spécificités, ses avantages et ses inconvénients. Mais en règle générale, j’ai l’impression que les gens associent souvent un outil avec une technologie particulière : MakeFile pour C/C++, Ant ou Maven pour le Java. En réalité il est possible d’utiliser ces outils de build indépendamment des technologies utilisées.
Je pense que Maven est l’outil le plus abouti sur lequel j’ai travaillé jusqu’à présent. Il y a peu de temps, je découvrais qu’il était possible de l’utiliser avec des projets Flex grâce à l’extension FlexMojo. Cela m’a redonner envie de trouver une solution simple pour utiliser Maven dans un projet C/C++.
Jusqu’à aujourd’hui je ne connaissais que le plugin Native mais je l’ai toujours trouvé trop compliqué et au final, je n’ai jamais réussi à l’utiliser. C’est dans ce contexte d’échec que je viens de découvrir une extension C/C++ (et Fortran) qui fonctionne sans effort ou presque : maven-nar-plugin. Lorsque j’écris “presque” sans effort c’est tout simplement parce que les plugins nécessaires ne sont pas encore disponible sur le repository central.
Voici la structure standard des répertoires de cette extension :
Pour installer maven-nar-plugin dans le répository local, il est nécessaire d’installer au préalable la librairie net.sf.antcontrib:cpptasks-parallel qui se trouve sur le repository GIT http://github.com/duns/cpptasks-parallel.
Il faut procéder de la même façon pour installer le plugin nar qui se trouve sur le repository GIT https://github.com/duns/maven-nar-plugin.git et l’archetype maven-archetype-nar-exec sur le repository https://github.com/duns/maven-archetype-nar-exec.git. Cet archetype va permettre de créer un projet exemple pour débuter rapidement grâce à la commande suivante :
Après l’exécution du build Maven sur ce nouveau projet (mvn install par exemple), l’exécutable se retrouve dans le répertoire target/nar/my-cpp-app-1.0-SNAPSHOT-*-executable/bin/*/my-cpp-app.
Il y a quelques mois, on m’a fait découvrir le plugin eclipse MoreUnit. Comme je le trouve très pratique, je profite de mon blog pour en parler. Il permet de gagner du temps pour le développement et l’exécution des tests unitaires. Il facilite aussi l’association entre les classes destinées à l’exécution et celles qui vont les tester. Ce plugin est disponible sur le marketplace.
Si l’option Decorate Classes with Test Case est activée (Window > Preferences… > General > Appearance > Label Decorations), les classes qui sont testées sont représentées avec un icon différent :
La même marque verte apparaît au niveau de la marge de l’éditeur Java au début des méthodes testées :
A partir d’une classe, un menu contextuel permet les actions suivantes :
Ouvrir la classe de test associée
Générer la classe de test si celle-ci n’existe pas
Exécuter la classe de test en entier
Exécuter les méthodes de test associées à une sélection de méthodes de la classe d’origine
Le plugin sait aussi prendre en compte les refactorings de la classe testée :
Si la classe testée est renommée, la classe de test est renommé elle aussi
Idem, si la méthode testée est renommée, les méthodes de test le sont aussi
Si la classe testée change de package, la classe de test change aussi de package
Enfin, la dernière fonctionnalité que je trouve très utile dans certains contextes, MoreUnit peut générer les mocks des objets utilisés dans la classe testée. Il est compatible avec Mockito et EasyMock. Il ne reste plus qu’a les paraméter.
Dans cet exemple, je vais générer un fichier Excel à partir d’un managed bean.
L’idée de base est de récupérer le context de la servlet pour créer une réponse et rediriger l’utilisateur vers cette dernière. Voici à quoi ressemble mon bean :
@Model
public class MonBean {
public String execute() throws IOException {
// Création du fichier excel :
String fileName = "azerty.xls";
HSSFWorkbook wb = new HSSFWorkbook();
HSSFSheet sheet = wb.createSheet(fileName);
HSSFHeader header = sheet.getHeader();
header.setCenter(fileName);
// Récupération de la réponse HTTP
ExternalContext externalContext = FacesContext.getCurrentInstance().getExternalContext();
HttpServletResponse response = (HttpServletResponse) externalContext.getResponse();
response.setContentType("application/vnd.ms-excel");
response.setHeader("Content-disposition", "attachment; filename="+ fileName);
// Ecriture de la réponse
ServletOutputStream out = response.getOutputStream();
wb.write(out);
out.close();
FacesContext.getCurrentInstance().responseComplete();
return null;
}
}
Ensuite, il suffit de demander la méthode execute() du bean.
Vous pouvez trouver le code source de cet exemple ici. Pour exécuter l’exemple il faut lancer la commande mvn compile tomcat:run et se diriger vers l’adresse http://localhost:9090/home.jsf
Comments (0) 
