Avec une installation par défaut de GlassFish, l'utilisation de JMS au sein du serveur d'application amène souvent à l'erreur suivante :
DirectConsumer:Caught Exception delivering messagecom.sun.messaging.jmq.io.Packet cannot be cast to com.sun.messaging.jms.ra.DirectPacket

Cette erreur n'est pas fatale, l'application est tout de même déployée et les différents messages sont envoyés et reçus. Cependant, cette erreur est générée à chaque envoi de message, ce qui peut rapidement devenir encombrant dans les fichiers de log de GlassFish.

Cette exception viens du mode de configuration utilisé pour le lancement du service JMS dans GlassFish. Par défaut, le service est lancé en mode EMBEDDED. Le service JMS tourne dans le même processus que le serveur GlassFish, ce qui provoque ce genre d'erreurs.

Il est possible de changer ce mode de lancement du service JMS. Il suffit de lancer ce même service en mode LOCAL pour que le service tourne dans un processus séparé du serveur GlassFish (mais toujours sur la même machine). Le service JMS sera toujours contrôlé par GlassFish (lancement simultanés entre autre). Changer ce mode de fonctionnement du service JMS permet de résoudre ce problème de cast de messages.

Pour effectuer ce changement, il faut se rendre dans la console d'administration de GlassFish :

• Accéder à l'adresse http://localhost:4848/
• Se connecter avec les identifiants d'administration de GlassFish (par défaut : admin /// adminadmin)
• Cliquer sur "Configuration" -> "Java Message Service" dans le menu de navigation de gauche
• Modifier la propriété "Type" et lui donner la valeur de "LOCAL"

Si vous lisez ces quelques lignes, c'est que je ne me serais planté nulle part. Ou du moins que mes erreurs ne sont pas critiques.

La résiliation de l'abonnement Internet étant en cours, mon blog, qui était jusqu'à présent hébergé chez moi, avait devant lui des jours qui lui étaient comptés.

C'est pour cela que j'ai migré mon installation de Roller vers un nouveau serveur, loué pour l'été (voire plus...) chez OVH (un Kimsufi, qui me suffit pour l'instant).

A première vue tout marche, j'essayerais de réparer les éventuels défauts dans les jours à venir... En attendant, bonne lecture :)

Je sais que GlassFish v3tp2 est sorti depuis un petit bout de temps, mais je viens juste de le télécharger...

Ma première impression ?

Ça fait vraiment très bizarre :

viv@Eudoxe:~/Programs/glassfish-v3tp2$ time ./bin/asadmin start-domain
Command start-domain executed successfully.

real	0m0.976s
user	0m0.720s
sys	0m0.056s
viv@Eudoxe:~/Programs/glassfish-v3tp2$ time ./bin/asadmin stop-domain
Command stop-domain executed successfully.

real	0m0.553s
user	0m0.640s
sys	0m0.056s

Temps de démarrage de moins de une seconde, temps d'arrêt d'environ une demi seconde...

Sinon, les premières choses qui changent :

• L'URL de l'interface d'administration. Ça paraît bête, mais j'ai mit bien 5 minutes à trouver la nouvelle (http://localhost:8080/admin)
• Un déploiement d'applications bien plus rapide qu'avant
• Le changement de fournisseur de persistance. GlassFish est passé de Toplink à EclipseLink, donc quelques petites modifications sont à faire dans les fichiers de configuration des applications spécifiques.

Le temps de tester un peu plus en profondeur et je pourrais donner un avis un peu plus complet, mais pour l'instant, je suis plutôt enthousiaste :)

Après de nombreuses tentatives, c'est enfin fait ! Le certificat SSL de *.aperigeek.com est valide.

Voici les différentes étapes de mon aventure :
Pour information, mon serveur GlassFish utilise JKS en tant que KeyStore. Il s'agit du KeyStore par défaut sur une installation basique de GlassFish.

Générer une paire de clés

Le JDK embarque un outil permettant de gérer les KeyStore de type JKS. Cet outil porte le doux nom de keytool.

La première étape est donc de générer une paire de clés. Ces clés seront utilisées pour chiffrer les données entre le client et le serveur.

Pour générer une paire de clés, la commande magique est :

$ keytool -genkeypair -keyalg <algorithm> -keystore <keystore> -validity <validity> -alias <alias>

Petite note : Pour les utilisateurs du JDK 5, l'option -genkeypair est à remplacer par -genkey.

Les options à fournir :

• <algorithm> corresponds à l'algorithme utilisé pour générer les clés (RSA, par exemple).
• <keystore> corresponds au fichier contenant les clés du serveur. Par défault, ce fichier s'appelle keystore.pks et est stocké dans domains/domain/config.
• <validity> corresponds au temps de validité du certificat, en jour (365 pour un an, par exemple).
• <alias> corresponds au nom que vous souhaitez donner au certificat. Ce nom sera réutilisé par la suite pour désigner ce certificat à l'intérieur du serveur d'application.

keytool vous posera plusieurs questions, notamment :

• Le mot de passe du KeyStore (par défaut, le mot de passe du KeyStore est changeit).
• Un CN (Common Name). Mettez le nom de domaine pour lequel vous souhaitez créer un certificat (il est possible d'utiliser un wildcard, comme par exemple *.aperigeek.com pour tous les sous domaines aperigeek.com).
• Les autres informations n'influent pas sur le certificat en lui même.

Générer une demande de certificat (CSR : Certificate Signing Request)

Ce fichier CSR va permettre d'effectuer une demande de certificat auprès d'une autorité de certification. Ce certificat permettra de justifier de l'identité du serveur auprès du client (afin d'éviter certaines attaques de type Man in the Middle, par exemple).

keytool permet de générer cette demande de certificat. La commande est :

keytool -certreq -alias <alias> -file <file> -keystore <keystore>

Avec les options :

• <alias> corresponds au nom de votre certificat, celui que vous avez choisi dans la première étape.
• <file> corresponds au fichier qui contiendra votre demande de certificat.
• <keystore> à votre KeyStore, le même que dans la première étape.

Grâce à cette demande de certificat, nous allons pouvoir maintenant demander un certificat à une autorité de certification.

Demander un certificat à une CA

Libre à vous de choisir une autorité de certification (CA). J'ai choisi CAcert.org, car il s'agit d'une des rares autorité de certifications fournissant des certificats gratuitement.

La demande du certificat dépend ensuite de l'autorité que vous avez choisi. Il se peut que l'autorité de certification vous demande de la rajouter dans en tant que telle dans votre navigateur. Une fois votre certificat créé, vous allez pouvoir le récupérer sois sous la forme d'un fichier .cert, sois sous sa forme textuelle. Dans le deuxième cas, nous allons devoir copier le texte du certificat (y compris les balises -----BEGIN CERTIFICATE----- et -----END CERTIFICATE-----).

Insérer le certificat dans le KeyStore du serveur

Cette étape est assez complexe à réaliser avec keytool, j'ai donc pour ma part utilisé ce code Java :

public class InsertCert {
    public static void main(String[] args) {
        try {
            String certFile = "aperigeek.cert";
            String certName = "*.aperigeek.com";
            String keyStoreFile = "keystore.pks";
            String keyStorePassword = "changeit";
            
            CertificateFactory certFactory = CertificateFactory.getInstance("X.509");
            Certificate cert = certFactory.generateCertificate(new FileInputStream(certFile));
            KeyStore keyStore = KeyStore.getInstance("JKS");
            keyStore.load(new FileInputStream(keyStoreFile), keyStorePassword.toCharArray());
            Key key = keyStore.getKey(certName, keyStorePassword.toCharArray());
            keyStore.setKeyEntry(certName, key, keyStorePassword.toCharArray(), new Certificate[]{cert});
            keyStore.store(new FileOutputStream(keyStoreFile), keyStorePassword.toCharArray());
        } catch (Exception ex) {
            Logger.getLogger(InsertCert.class.getName()).log(Level.SEVERE, null, ex);
        }
    }
}

(inspiré de Using SSL with GlassFish v2 : Enterprise Tech Tips)

Les variables à remplacer :

• certFile : le nom du fichier contenant le certificat, fourni par l'autorité de certification.
• certName : le nom du certificat, que vous lui avez donné à l'étape 1
• keyStoreFile : le nom du KeyStore
• keyStorePassword : le mot de passe du KeyStore

Après exécution de ce morceau de code, voilà votre nouveau certificat entré dans la base de certificats de votre serveur d'applications. Il ne reste plus qu'à configurer GlassFish pour utiliser ce nouveau certificat !

Configuration du service HTTP

Dans la console d'administration de GlassFish :

• Dans l'arbre : Configuration, Service HTTP, Listeners HTTP, nom-du-listeneur
• Onglet SSL :
  • Certificate Nickname : nom du certificat (que vous lui avez donné à l'étape 1)
  • Cocher SSL3 et TLS
• Onglet HTTP Listener :
  • Cocher Security Enabled
• Redémarrer GlassFish

Et voilà le résultat. Vous pouvez maintenant consulter mon blog en HTTPS avec un certificat valide, si le cœur vous en dit.

Nous sommes dans une période de sortie ! Hier, NetBeans 6.1 pointait le bout de son nez. Aujourd'hui, c'est GlassFish v2ur2 qui fait son entrée. Période idéale pour faire un point sur ces deux nouvelles versions, puis pour regarder un peu en avant afin de voir ce que l'avenir nous réserve...

NetBeans

La version 6.1 apporte son lot de fonctionnalités. J'en avais déjà parlé, les améliorations sont au rendez vous.

Parmi toutes les nouvelles fonctionnalités, mes préférées :

• Amélioration des performances
  • Démarrage (beaucoup) plus rapide
  • Consomme moins de mémoire
  • Beaucoup plus réactif
• Support de MySQL
  • Administration de serveur MySQL intégré
• Partage de projets
  • Les librairies sont directement inclues dans votre projet
  • Les chemins pour accéder aux librairies sont relatifs

La liste complète est disponible sur le site de NetBeans.

Quelques nouvelles fonctionnalités qui viendront après la version 6.1 sont déjà prévues :

• Support de PHP
  • Auto-complétion, coloration syntaxique, ...
  • Débuggeur de JavaScript
• Amélioration de l'éditeur SQL
  • L'éditeur SQL devrait fonctionner main dans la main avec l'éditeur PHP
  • L'auto-complétion de requêtes SQL devrait apparaître
• Amélioration des performances (encore)
  • Voir : la liste complète des améliorations au sujet de la performance

GlassFish

La version 2ur2 n'est qu'une mise à jour de maintenance. Les nouveautés ne sont donc pas très nombreuses.

Cependant, GlassFish 3 se prépare, et nous réserve d'ores et déjà de belles surprises.

La première amélioration, et pas des moindres, GlassFish v3 sera beaucoup plus rapide à lancer. Les premiers tests tendent vers un temps démarrage du serveur d'application inférieur à une seconde. Comme quoi beaucoup de progrès ont été faits.

De plus, GlassFish devrait être embarquable dans n'importe quelle autre application Java. Un petit exemple de ce qui pourrait être fait grâce à GlassFish v3 (via Bistro !) :

GlassFish glassfish = new GlassFish();
glassfish.minimallyConfigure(8080);

GFApplication app = glassfish.deploy(new File("mon_appli.war"));

// ...

app.undeploy();
glassfish.stop(); 

Une fonctionnalité assez pratique. Tomcat était déjà assez souvent utilisé en tant que conteneur de Servlet embarqué. C'est maintenant tout un serveur d'application qui pourra être embarqué dans une application.

Pour résumer, les futures version de NetBeans et de GlassFish tendent toutes les deux vers une amélioration des performances, mais réservent elles aussi leur lot de surprises.