vendredi 14 décembre 2012

Attention aux parenthèses dans Logback

J'ai perdu une soirée à cause de ça. Et j'ai perdu un peu de crédibilité aussi, en ouvrant un ticket sans fondement. Et tout ça parce que j'avais mal lu la documentation.

L'histoire a commencé quand j'ai voulu ajouter l'adresse IP des clients de mon application Web dans les logs. J'avais déjà configuré mon MDCInsertingServletFilter, il ne me restait qu'à utiliser ses informations. J'ai donc configuré le pattern dans le appender, avec un %X{...} et un peu de mise en forme. C'est ici que la parenthèse arrive, et les problèmes avec.
%d{HH:mm:ss.SSS} (%X{req.remoteHost}) [%thread] %-5level %logger - %msg%n


samedi 1 décembre 2012

Accéder à la console de JBoss AS 7 via Apache Web Server

Dernièrement, j'ai eu besoin d'exposer la console d'administration de JBoss AS 7.1 sur un serveur Web Apache. Le choix de la technique à utiliser a été rapide : puisque l'interface de management ne propose pas d'accès AJP, il faut utiliser Apache en reverse proxy HTTP.

Dans un premier temps, j'ai exposé le contexte http://localhost:9990/console via mod_proxy. Je me suis rapidement rendu compte que c'était insuffisant car l'application fait des requêtes AJAX sur le contexte management. La configuration suivante de mod_proxy semblait raisonnable :

ProxyPass /console http://localhost:9990/console
ProxyPassReverse /console http://localhost:9990/console

ProxyPass /management http://localhost:9990/management
ProxyPassReverse /management http://localhost:9990/management
Ça fonctionnait sans problème sous Firefox, mais sous Chrome, j'avais une erreur 403. N'étant pas certain que tous les administrateurs de mes clients utilisent Firefox, je me suis mis en quête d'une meilleure solution.

mardi 11 septembre 2012

JBoss EAP 6 et les bonnes nouvelles

La nouvelle n'est pas très fraîche puisqu'elle date de juin 2012, mais je n'en avais pas encore parlé : RedHat a sorti JBoss EAP 6.

JBoss EAP est la version avec support de JBoss. Pour avoir le droit d'utiliser JBoss EAP, il faut payer une souscription annuelle à RedHat, mais si vous voulez juste jeter un coup d'oeil, il existe un version d'évaluation (30 jours), sans support qu'on peut télécharger sur le Customer Portal de RedHat (avec inscription préalable). Pour schématiser, c'est un JBoss AS avec des bugs en moins et un contrat de support en plus.

Dans le processus de développement, il y a d'abord JBoss AS, développé par RedHat avec des contributions externes, puis lorsqu'une bonne partie des bugs est corrigée, une version de JBoss EAP est livrée. Cette version EAP 6 est basée sur un JBoss AS 7.1. Je ne vais pas revenir sur cette histoire de versions puisque j'en ai parlé dans un billet sur les versions mineures de JBoss publié l'an dernier.

Basé sur JBoss AS 7, EAP 6 fait donc partie de la nouvelle génération des serveurs d'applications, modernes, légers et rapides. C'est la première bonne nouvelle.

Ensuite, les développeurs qui utilisent Maven ont été entendus. Il est possible de télécharger un repository, sous forme d'archive zip, comprenant les artefacts utilisés pour le build de EAP. On pourra donc déclarer des dépendances vers les versions qui utilisées lors du déploiement. Ce repository est aussi accessible en ligne.

Enfin, le code source de EAP 6 est disponible en ligne. Le code est ouvert, même si le binaire n'est pas redistribuable. Le seul bémol, c'est qu'il n'est pas possible de faire le build soi-même. Bon, c'est vrai que ce n'est pas fait pour ça ! Si vous voulez jouer  à faire des builds, il y a JBoss AS pour ça.

Justement, jetons un coup d'oeil de ce coté-ci. EAP 6 a été construit à partir de AS 7.1.2, avec des différences qui semblent faibles. Ça aussi, c'est une bonne nouvelle car les différences entre EAP et AS étaient vraiment marquée en version 5. Voir une version AS dont la qualité est proche d'une EAP est rassurant pour la communauté et l'idée de lancer une distribution CentAS, sur le même principe que CentOS dans le monde linux, me semble s'éloigner, du moins pour l'instant. Le hic, c'est qu'il n'y a pas de release 7.1.2 ; problème juridique et de licence, semble-t-il. Pour utiliser cette version, il faut la construire soi-même. Aujourd'hui, c'est cette version-ci que j'utilise. C'est d'ailleurs la première qui corrige le bug d'intégration avec Log4J qui m'embêtait depuis des mois.

Donc si vous avez une application Java EE à déployer, vous avez le choix entre JBoss EAP 6 ou JBoss  AS 7.1.2. A moins que vous préfériez Glassfish, TomEE,... Mais dans ce cas, je serais surpris que vous ayez lu ce billet jusqu'ici !

samedi 8 septembre 2012

Construire soi-même JBoss AS 7 (ou WildFly)

Question préliminaire : pourquoi vouloir faire un build de JBoss ?

La première raison, c'est pour le principe. JBoss AS est open source et communautaire. Dans cet esprit, il est impératif de proposer un système de build simple et pratique. Sur ce point, je dois dire que les progrès sont impressionnants entre JBoss AS 5 et JBoss AS 7.

La deuxième raison dérive de la première. Je veux pouvoir faire le buid pour m'autoriser à proposer des corrections de bugs. OK, je ne l'ai fait qu'une fois, mais c'est un début.

La troisième raison est plus pragmatique. La version 7.1.2 de JBoss AS n'existe que sous la forme d'un tag dans le référentiel de source, il n'y a pas eu de release officielle. Comme des bugs gênants ont été corrigés, c'est cette version-là que je veux utiliser.

Voyons comment ça marche...

vendredi 13 avril 2012

Développeurs JSF, fuyez @ManagedBean

Quand on fait du JSF, on peut déclarer nos beans avec l'annotation JSF @javax.faces.bean.ManagedBean ou avec l'annotation @javax.inject.Named. Dans ce dernier cas, le cycle de vie du bean est géré par CDI qui met les instances à disposition de JSF.
On retrouve aussi les deux possibilités avec les annotations liées aux portées, qu'on peut prendre dans le package javax.enterprise.context pour CDI ou dans javax.faces.bean pour JSF.

J'ai été confronté récemment à un problème de compatibilité entre CDI et un managed bean JSF. Le bean existait dans une version pure JSF, mais pour faire évoluer l'application, j'ai intégré du CDI. Dans un premier temps, j'ai simplement injecté des dépendances avec l'annotation @Inject.

@ManagedBean
@RequestScoped
public class FirstBean {
    @Inject private Logger logger;   
    @Inject private SomeEJB someEJB;
    ...
}

samedi 7 avril 2012

Tester des beans en scope Conversation avec Arquillian

Si Arquillian est un outil fantastique pour tester des composants JavaEE 6, il n'en a pas moins quelques faiblesses ou défauts de jeunesse. Dans cette article, je veux vous présenter les difficultés que j'ai rencontrées pour tester des beans CDI, utilisés dans un contexte JSF, en portée Conversation.

dimanche 25 mars 2012

Accéder aux composants remote de JBossAS 7

JBoss AS 7 a changé plein de choses ; il ne ressemble absolument pas aux versions précédentes. Mais ça je l'ai déjà dit sur le site de mon entreprise. Malgré tout, à chaque étape j'en ai une nouvelle confirmation. Ainsi j'ai un peu tâtonné pour établir des connexions distantes entre des clients Java et un serveur JBoss AS 7.1. Mes client doivent appeler des EJBs et échanger des messages JMS.

Pour JMS, les choses sont assez simples ; il suffit de connaitre les bons paramètres JNDI et les bons noms sous lesquels les composants sont enregistrés dans JNDI. La subtilité réside surtout dans la logique des noms exportés. En effet, seuls les noms préfixés par java:jboss/exported/ sont accessibles à distance.

Pour les EJBs, c'est un peu plus complexe. En effet, si le fonctionnement classique par JNDI fonctionne aussi, avec le même principe des noms exportés, il est déprécié au profit d'un fonctionnement par le client d'EJB JBoss, avec comme préfixe JNDI "ejb:".

Tout ceci est détaillé dans JTips, d'une part pour l'accès distant à JMS, d'autre part pour l'accès distant à un EJB.

mardi 24 janvier 2012

Présentation Arquillian

Arquillian est un outil de test pour JavaEE. Je pense que c'est même le maillon manquant entre JavaEE et JUnit. C'est vrai que j'ai longtemps pensé que si JavaEE était devenu un concurrent sérieux pour Spring, il lui restait une lacune importante au niveau des tests. Cette lacune est probablement comblée par Arquillian.

J'ai découvert Arquillian lors d'un atelier à Devoxx 2010. C'était une occasion incroyable de découvrir l'outil, en compagnie d'Aslak Knutsen (actuel lead du projet), Pete Muir et Dan Allen, stars de la Dream Team RedHat/JBoss. Depuis j'utilise l'outil de temps en temps, pas assez souvent à mon goût parce que je fais plus de Spring que de JavaEE sur mes projets.

En 2011, j'ai eu l'occasion de présenter Arquillian à Softshake. C'était une expérience nouvelle pour moi, que j'ai trouvée enrichissante et excitante. J'ai donc saisi les opportunités de la renouveler, d'une part devant les étudiants de l'INSA Lyon, puis chez les parisiens de Ippon. Lors de cette session, j'ai enregistré un screencast que j'ai inséré ci-dessous.

J'espère continuer à présenter ce talk et je pense en proposer d'autres dans le futur. Certes, je n'ai pas la légitimité de certains développeurs, mais j'aime ça et j'ai envie de continuer.


Tests d'intégration avec Arquillian from Alexis Hassler on Vimeo.
Présentation d'Arquillian, l'outil pour les tests d'intégrations JavaEE