Le serveur Java EE GlassFish

Le connecteur JK utilise donc le protocole AJP13 et nécessite l'installation du module mod_jk pour fonctionner avec Apache. Le connecteur JK permet ainsi d'utiliser le serveur Web en frontal et de déléguer certaines tâches au serveur GlassFish. Les requêtes des clients sont envoyées au serveur Web Apache qui retourne alors directement les contenus statiques comme : les images, le JavaScript, les pages HTML ou autres. Pour les requêtes au contenu dynamique, le module mod_jk du serveur Web est alors sollicité et délègue certaines tâches au serveur d'applications GlassFish.

La configuration de GlassFish avec un serveur Web utilise la notion de worker ou travailleur. Un travailleur est lié à une instance de serveur GlassFish. Un travailleur est caractérisé par un nom d'hôte ou une adresse IP et un numéro de port (comme une socket/prise). Le travailleur AJP13 représente une instance de GlassFish. Le module mod_jk agit alors comme un routeur de requêtes vers le serveur GlassFish.

L'extension d'Apache supportant le connecteur JK est le module mod_jk. Ce module est livré sous forme de binaires (ou code source).

Pour activer le mod_jk avec la version v3 il faut une release au moins supérieure à b53. En effet, l'attribut jk-enabled doit être activé et n'est supporté qu'à partir de cette version.

Les étapes suivantes sont utilisées pour l'installation du module mod_jk :

• Installation du serveur Web Apache 2 au besoin :

$ apt-get install apache2

• Installation du module ainsi que ses dépendances :

apt-get install libapache2-mod-jk

Une fois l'installation réalisée, ce module est présent dans le répertoire /etc/apache2/mods-available/jk.load.

• Activation du module mod_jk en utilisant la commande suivante :

$ a2enmod jk

Il nous reste à configurer le fichier de gestion d'Apache pour que ce dernier charge dynamiquement, lors de son démarrage, le module mod_jk. Pour cela, il est nécessaire d'éditer selon la version d'Apache le fichier apache2.conf et d'ajouter les lignes suivantes en fin de fichier :

#configuration du couplage Apache GlassFish
#définition du worker ou travailleur
JkWorkersFile /etc/apache2/workers.properties
#définition du fichier de log pour le module
JkLogFile /var/log/apache2/mod_jk.log
#définition du fichier de mémoire partagée pour le module
JkShmFile /var/log/apache2/mod_jk.shm
#mise en place du niveau de log
JkLogLevel info
#expression du format des logs
JkLogStampFormat "[%a %b %d %H:%M:%S %Y]"
#options du module pour SSL et la clé
JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories
#précision du format des requêtes pour les traces du module
JkRequestLogFormat "%w %V %T"

La directive JkWorkersFile permet de spécifier l'emplacement du fichier de configuration du module. La directive JkLogFile précise l'emplacement d'un fichier journal réservé au module et la directive JkLogLevel indique le type des messages enregistrés dans ce fichier.

Une fois la configuration terminée, nous pouvons relancer le serveur Web Apache avec la commande suivante :

$ /etc/init.d/apache2 restart

Nous pouvons remarquer que le serveur ne veut pas redémarrer, ce qui est tout à fait normal car le module mod_jk est correctement installé et paramétré, mais le worker ou travailleur n'est pas encore configuré.

Une fois le fichier de configuration d'Apache modifié, il faut ensuite créer le fichier de configuration du travailleur indiqué par la directive JkWorkersFile dans le fichier d'Apache (apache2.conf). Ce fichier permet de gérer la communication entre le serveur Web et le serveur GlassFish. Le fichier utilisé nommé workers.properties porte l'extension .properties, format très utilisé avec les technologies Java. Ces fichiers sont composés d'un ensemble de paires clé/valeur. La syntaxe pour le fichier workers.properties est la suivante :

worker.<nom_du_travailleur>.<directive>=<valeur>

Code : /etc/apache2/worker.properties
#liste des travailleurs (il serait possible de placer
#plusieurs travailleurs séparés par des virgules)
worker.list=worker1
#protocole de worker1
worker.worker1.type=ajp13
#nom d'hôte pour worker1
worker.worker1.host=localhost
#port du connecteur JK pour worker1
worker.worker1.port=8009
#le facteur de charge
worker.worker1.lbfactor=50
#nombre de connexions AJP maintenues dans le cache
worker.worker1.cachesize=10
#temps pendant lequel la connexion est maintenue dans le cache
worker.worker1.cache_timeout=600
#ne pas couper les connexions inactives
worker.worker1.socket_keepalive=1
#temps d'expiration lors de la communication entre Apache et GlassFish
worker.worker1.socket_timeout=30

Ce fichier est créé dans le répertoire local d'Apache à savoir : /etc/apache/workers.properties conformément à la directive JkWorkersFile. Les paramètres de configuration du fichier workers.properties sont, entre autres :

• worker.list : spécifie une liste de travailleurs séparés par des virgules.
• type : spécifie le type de travailleur.
• host : précise le nom d'hôte ou l'adresse IP du serveur GlassFish à contacter pour le travail.
• port : indique le numéro de port du connecteur JK.
• retries : positionne le nombre de tentatives de connexion vers GlassFish en cas de non-réponse de ce dernier (3 par défaut).
• lbfactor : gère le facteur de charge d'un travailleur dans le cas où la répartition de la charge est mise en oeuvre par mod_jk. Cette valeur permet de préciser quel pourcentage de requêtes l'instance GlassFish sera amenée à traiter (défaut 1).
• cachesize : précise le nombre de connexions AJP maintenues en cache.
• cache_timeout : spécifie combien de temps une connexion doit être maintenue dans le cache avant d'être fermée par mod_jk, afin de réduire le nombre de processeurs de requêtes actifs sur le serveur GlassFish (défaut 0).
• socket_keepalive : évite que le firewall coupe les connexions inactives (défaut 0).
• recycle_timeout : indique le nombre de secondes au-delà duquel le serveur coupe une connexion AJP en cas d'inactivité (défaut 0, bonne moyenne 300).
• socket_timeout : indique le temps d'expiration de la communication entre Apache et GlassFish. Si le serveur GlassFish ne répond pas dans le délai indiqué, mod_jk génère une erreur et recommence.

La configuration du module mod_jk permettant le dialogue entre le serveur Web Apache et le serveur Java EE GlassFish est maintenant terminée. Il ne reste désormais plus qu'à ajouter un nouvel hôte virtuel correspondant au nouveau site à héberger sur notre machine. Pour ajouter un nouvel hôte virtuel pour Apache, nous allons créer un nouveau fichier nommé jwadg (l'inverse de gdawj pour l'exemple) et ajouter le code suivant, permettant de définir l'URL www.jwadg.com et les fichiers à gérer dans ce cas :

<VirtualHost *:80>
ServerName www.jwadg.com
ServerAlias jwadg.com
ServerAdmin info@gdawj.com
DocumentRoot /usr/local/glassfishv3/glassfish/domains/domain1/applications/gdawj/
CustomLog /var/log/apache2/jwadg-access_log combined
Alias /css /usr/local/glassfishv3/glassfish/domains/domain1/applications/gdawj/css
JkUnMount /css/* worker1
Alias /images /usr/local/glassfishv3/glassfish/domains/domain1/applications/gdawj/images
JkUnMount /images/* worker1
<Location "/*">
JkMount worker1
</Location>
</VirtualHost>

La configuration de l'hôte virtuel permet de gérer le nom de domaine www.jwadg.com et de fournir, pour cela, l'application précisée par la directive DocumentRoot. Les logs Apache pour cette application sont précisés par la directive CustomLog. La directive Alias permet de réaliser un alias de nom sur les répertoires statiques que sont /css et /images. La directive JkUnMount permet de préciser que le travailleur worker1 n'est pas utilisé pour les alias /css et /images et qu'Apache est suffisant pour renvoyer tous ces contenus statiques.

Enfin, la directive JkMount, présente dans la balise <Location/>, permet de préciser que pour toutes les autres demandes (hors JkUnMount), le travailleur worker1 devra pouvoir les satisfaire, c'est-à-dire pour les fichiers JavaServer Pages, Servlets ou encore JavaServer Faces.

La directive JkMount est très importante car c'est elle qui permet au serveur Apache d'accéder aux applications GlassFish. Elle permet en effet de spécifier un travailleur pour l'accès au contexte. Il y aura donc une redirection de requêtes utilisateur à destination du travailleur.

La directive JkUnMount permet de réaliser l'inverse et donc de ne pas rediriger les requêtes utilisateur à destination de ressources particulières.

JkUnMount
/usr/local/glassfishv3/glassfish/domains/domain1/application/monapplication/
mescss/*.css

D'autres directives d'Apache sont utilisables avec le mod_jk. La directive JkAutoAlias permet de réaliser un alias du répertoire de GlassFish sur le répertoire de données Apache, JkLogStampFormat permet de gérer le format de la date dans le fichier journal du module, JkExtractSSL permet de transmettre les informations SSL vers le serveur GlassFish (état on par défaut).

La configuration de l'hôte virtuel étant terminée nous pouvons l'activer et recharger le serveur Web Apache :

$ a2ensite jwadg
$ /etc/init.d/apache2 reload

Le connecteur Apache GlassFish est activé, l'hôte virtuel également, il ne reste plus qu'à créer le faux nom de domaine www.jwadg.com pour simuler un domaine acheté. Pour cela, sous Windows, il est possible d'éditer le fichier C:\WINDOWS\system32\drivers\etc\hosts et d'ajouter le nom de l'hôte virtuel.

127.0.0.1 www.jwadg.com
127.0.0.1 jwadg.com

Sous Linux, nous pouvons réaliser la même opération en éditant le fichier /etc/hosts :

127.0.0.1 www.jwadg.com
127.0.0.1 jwadg.com

Désormais, lorsqu'une des URL suivantes : http://www.jwadg.com ou http://jwadg.com sera appelée dans un navigateur, c'est la machine locale (127.0.0.1) qui répondra aux requêtes du client. Cela évite d'acheter les deux noms de domaine pour nos tests. Nous pouvons désormais tester la configuration du connecteur Apache GlassFish en ouvrant un navigateur Web et en saisissant l'URL de notre hôte http://www.jwadg.com.

Comme nous pouvons le voir dans la figure précédente, la configuration Apache est correcte mais le serveur GlassFish est incapable de répondre à la demande. En effet, il manque une dernière étape, la configuration du module mod_jk pour GlassFish.

La configuration du module mod_jk pour GlassFish passe par la mise en place d'un écouteur sur le port 8009 et l'activation du module mod_jk pour ce port. En effet, comme précisé précédemment, le dialogue entre le serveur Apache et le serveur GlassFish est réalisé sur le port 8009.

Pour cela, nous pouvons utiliser l'interface d'administration du serveur et le menu Network Config - New... et ajouter un nouveau listener en plus de celui par défaut pour les sites (http-listener-1 port 8080), de celui de l'interface d'administration (admin-listener port 4848) et de celui pour SSL (http-listener-2 port 8181).

Sinon, nous pouvons utiliser la configuration en ligne de commande avec les deux lignes ci-dessous. Cette première ligne permet de créer un écouteur sur le port 8009 (listenerport) pour toutes les interfaces (listeneraddress) en correspondance avec l'hôte virtuel par défaut (server) et de le nommer jk-connector :

$ asadmin create-http-listener --listenerport 8009 --listeneraddress 0.0.0.0 --defaultvs server jk-connector

Cet écouteur HTTP est correctement configuré, nous devons maintenant activer le connecteur jk pour qu'il puisse dialoguer avec Apache en précisant son nom et l'activation du module (jk-enabled) :

$ asadmin set configs.config.server-config.network-config.networklisteners.network-listener.jk-connector.jk-enabled=true

Nous pouvons vérifier la création du connecteur en utilisant l'interface Web et en éditant l'écouteur nommé jk-connector. Nous pouvons observer que la case JK Listener est activée.

La configuration du module mod_jk est terminée pour GlassFish, la dernière étape consiste à créer un hôte virtuel pour GlassFish en association de l'hôte virtuel Apache.

En cas de problème lors du test du connecteur, les fichiers journaux d'Apache et de mod_jk peuvent nous aider en indiquant les raisons des dysfonctionnements.

La mise en place d'un hébergement professionnel nécessite la création d'un hôte virtuel avec Apache et selon le même principe qu'avec GlassFish. La création d'hôte virtuel est réalisable avec l'interface Web par le menu Configuration - Virtual Servers - New...

Nous pouvons commencer par afficher la liste des serveurs virtuels disponibles sur la machine serveur GlassFish :

$ asadmin list-virtual-servers

Il existe par défaut deux serveurs, server et __asadmin. Nous allons créer, par l'intermédiaire de l'interface en ligne de commande, un nouveau serveur virtuel pour notre projet jwadg :

$ ./asadmin create-virtual-server --hosts www.jwadg.com,jwadg.com –-httplisteners jk-connector --defaultwebmodule gdawj jwadg

La ligne de commande ci-dessus permet de créer un hôte virtuel nommé jwadg pour les noms de domaine www.jwadg.com et jwadg.com avec pour connecteur ou écouteur associé jk-connector et comme application Java EE associée, gdawj.

La syntaxe de création d'un hôte virtuel en ligne de commande est la suivante :

create-virtual-server
--hosts hosts
--httplisteners httplisteners
--defaultwebmodule web_module
virtual_server_id

Nous pouvons utiliser l'interface d'administration Internet pour vérifier que l'hôte virtuel est correctement configuré.

L'application (ou module) gdawj est maintenant associée à l'hôte virtuel jwadg utilisant le connecteur jk sur le port 8009. Nous pouvons d'ailleurs remarquer que le lanceur d'applications présent dans le menu Applications - gdawj indique désormais l'adresse http://localhost:8009/gdawj pour accéder à l'application à la place de http://localhost:8080/gdawj.

La suppression du serveur virtuel peut être réalisée avec la commande suivante :

$ ./asadmin delete-virtual-server jdawg

La configuration est maintenant terminée, nous pouvons redémarrer le serveur GlassFish pour activer le serveur virtuel et tester la configuration.

Le déploiement du projet gdawj pour le domaine www.jwadg.com et son alias jwadg.com est désormais totalement opérationnel. L'application est déployée dans un contexte professionnel, avec le serveur Web Apache en frontal et le serveur GlassFish pour les services Java EE.

Les explications sur la configuration d'un hôte virtuel sont correctes mais l'application doit alors être déployée AVANT la configuration de l'hôte et, en cas de suppression de l'application, l'hôte ne sera plus relié avec une application spécifique. Pour nous en convaincre, nous pouvons supprimer l'application précédemment déployée et la déployer à nouveau :

$ asadmin undeploy gdawj
$ asadmin deploy /home/lafosse/gdawj.war

Lors du déploiement nous ne précisons pas d'hôte virtuel associé, l'application sera donc accessible avec l'URL http://localhost:8080/gdawj mais nous serons gratifiés d'une erreur 404 si nous accédons à l'URL http://www.jwadg.com. Pour éviter ce problème, GlassFish permet de déployer une application et de préciser directement en ligne de commande un hôte virtuel associé :

$ asadmin deploy –-virtualservers jwadg --enabled=true /home/lafosse/gdawj.war

Le serveur GlassFish offre également la possibilité de précompiler les pages JSP pour faciliter la mise en ligne et vérifier la syntaxe de l'ensemble de l'archive :

$ asadmin deploy -–virtualservers jwadg --precompilejsp=true --verify=true --enabled=true /home/lafosse/gdawj.war

Toutes les étapes en relation avec des actions sur les serveurs virtuels nécessitent des redémarrages du serveur. Les actions sur les applications, quant à elles, ne nécessitent aucun redémarrage et sont directement actives.