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

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