• 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.

  • 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.

  • 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…​

  • 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;
        ...
    }
  • 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.