JBoss EAP est-il Open Source ?

JBoss EAP est un serveur d'applications dérivé de JBoss AS. Plus précisément, c'est ce que RedHat fournit lorsque vous souscrivez à leur support technique. Mais ça, vous le savez probablement, du moins j'en ai déjà parlé. Je voulais revenir ici sur l'aspect Open Source de JBoss EAP, parce que le cas est étrange : les binaires de JBoss EAP ne sont accessibles qu'aux clients de RedHat, sur leur portail client. Si vous n'êtes pas client, vous pouvez télécharger une version d'évaluation, utilisable pendant 30 jours seulement. Ça ressemble très peu à du logiciel Open Source et pourtant le code est sous licence LPGL. Je ne vais pas revenir sur le montage qui permet à un logiciel LGPL de ne pas être redistribuable, c'est plus une affaire de juriste que de développeur. Je ne vais pas non plus contester la légitimité de RedHat à gagner de l'argent grâce à JBoss. Je vais plutôt me concentrer sur le code.

Dans un billet récent, Henk (je ne connais pas son nom complet) est revenu sur les différences entre JBoss AS et EAP et a rappelé l'impossibilité de faire un build de JBoss EAP 6. Pourtant, on a presque tout ce qu'il faut :
- le code source peut être téléchargé sur un FTP dédié,
- un repository Maven des artéfact utilisés dans EAP 6 est sur le portail client de RedHat et sur un site dédié.

Rappelons que la disponibilité du code source n'est pas suffisante pour être Open Source, il faut avoir le droit de le modifier, ce qui est garanti par la licence LGPL, mais aussi la possibilité de le compiler. La licence précise bien, mais avec d'autres termes, que sans build, le code n'est rien. Le build de JBoss EAP utilise Maven, comme pour JBoss AS 7. La différence, c'est que tous les artéfacts construits ou utilisés par le build sont suffixés par "-redhat-n" (variant de 1 à 4), et que ces artéfacts renommés ne sont présents que dans les repositories EAP, internes à RedHat. Cet état de fait pose évidemment problème pour recompiler JBoss EAP, mais pose aussi problème à ceux qui veulent développer des applications qui doivent y être déployées. Pour assurer une meilleure qualité, celles-ci doivent être construite, et testées, avec le même artéfacts que ceux de l'environnement de déploiement. RedHat a bien compris ce problème et c'est pour cela qu'ils proposent aux développeurs de télécharger une repository Maven dédié à JBoss EAP 6. Malheureusement, ce repository est incomplet : il manque tous les plugins Maven, inutiles au développeur d'applications mais nécessaires au build de JBoss EAP, et quelques artéfacts (Hibernate 3, PowerMock, SLF4J,...). Donc il est impossible de compiler JBoss EAP 6.

Par contre, avec un peu de patience, en tâtonnant, on peut construire quelque chose s'approchant de JBoss EAP 6 en remplaçant les artéfacts suffixés "-redhat" par des artéfacts présents dans des repositories publics. Ainsi, j'ai réussi à faire un build de quelque chose qui n'est pas JBoss EAP 6 mais qui y ressemble, il me reste à tester le résultat... Si de votre coté vous voulez aussi tester ce que ça donne, j'ai partagé le script sur GitHub. Vous pouvez essayer :

  git clone git://github.com/hasalex/eap-build.git
  cd eap-build
  ./build.sh

Testez, forkez et racontez-moi...

Si le sujet vous intéresse, un fil de discussion Building EAP6 from source est ouvert sur le forum de JBoss. Venez donner votre avis.

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

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.

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 !