Déploiement de Silverpeas sur JOnAS

Voici la présentation que j'ai donnée pour OOsphère, en avril 2010, au sujet du déploiement de Silverpeas sur JOnAS et sous JBoss 5.

SLF4J et JCL sous Jonas 5

Lors du déploiement d'une application JavaEE, la configuration des logs est un passage obligé. La principale contrainte vient du fait qu'au déploiement, on subit le choix des développeurs : Log4J, jakarta commons-logging (ou JCL), SLF4J ou d'autres encore que je m'abstiendrai de citer ici.

SLF4J associé à LogBack est probablement ce qui se fait de mieux aujourd'hui. Il propose d'ailleurs des mécanismes d'interopérabilité avec les autres APIs de Log. Par exemple, dans la dernière application que j'ai déployée, tous les logs envoyés à JCL sont interceptés par SLF4J grâce à la librairie jcl-over-slf4j.jar. A l'inverse, Jonas 5.1 renvoie tous les logs de SLF4J vers JCL.

Tests unitaires pour Google App Engine

Les tests unitaires des applications GAE posent les problèmes classiques des applications déployées dans des conteneurs : peut-on tester les classes hors de son contexte cible, peut-on simuler le conteneur, ou faut-il déployer l'application pour la tester ?
La première solution est celle qui s'approche le plus de l'unicité du test, il doit donc être privilégié autant que possible, c'est la technique qui est utilisée pour les POJOs sans contexte d'exécution. En revanche, c'est tout à fait impossible si notre classe a besoin d'une API fournie par le conteneur ou, pire encore, hérite d'une classe ou implémente une interface fournie par celui-ci. Ces cas sont classiques en JavaEE. Dans ce domaine, la tendance a été de remplacer le conteneur par des objets mock ou fake.
Nous allons étudier ce qui est proposé par Google pour son App Engine.

JRebel avec OpenJDK et Grizzly

Grâce au ParisJUG,j'ai pu obtenir une licence JRebel. JRebel est censé faire gagner du temps aux développeurs en leur évitant de redémarrer leur application ou serveur d'applications après chaque changement. Selon le serveur d'applications, le redéploiement à chaud peut répondre partiellement à ce besoin, mais JRebel semble aller plus loin, en rechargeant les classes au niveau de la JVM.

Dans un projet récent, j'ai eu à travailler avec Grizzly, OpenJDK et Jersey pour développer des services RESTful, et j'ai compris l'intérêt que pouvait avoir ce type d'outil car, en phase d'évaluation de la plateforme, je fais beaucoup de petites modifications dont je veux voir immédiatement l'effet. Si redémarrer Grizzly est très rapide, cela demande des clics à des endroits différents dans l'IDE, Eclipse en l'occurrence. J'ai donc décider d'inclure JRebel dans cet environnement.