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