Logging tomcat et hibernate

Introduction

Dans une application d'un client que je reprends pour de la maintenance, j'ai un problème. Cette application est faite pour Oracle et, sur ma machine de test, je n'ai aucune envie d'installer cette base de données plutôt gourmande en ressources.

Cette application utilise l'ORM hibernate pour abstraire tous les accès à la base de données. C'est donc, normalement, un jeu d'enfant d'utiliser un au SGBD. J'ai donc décidé d'utiliser le MySQL 5.1.36 qui est installé sur ma machine. Ensuite, j'ai modifié le fichier "persistence.xml" pour qu'hibernate se connecte à une nouvelle base de données sous MySQL.

Problème

Alors que tout devrait fonctionner sans problème, en lançant l'application, je n'ai aucune table qui est créée.

Dans le logging de cette application, j'obtiens l'erreur suivante :

ERROR org.hibernate.tool.hbm2ddl.SchemaUpdate - Unsuccessful: alter table nom_de_la_table add index FKCD10932052C35B33 (clé), add constraint FKCD10932052C35B33 foreign key (clé) references preview (id)
ERROR org.hibernate.tool.hbm2ddl.SchemaUpdate - Can't create table 'nom_de_la_table' (errno: 150)

Logging

Bon, le fait d'avoir un message d'erreur ne me pose pas plus de problèmes que ça. Par contre, ce qui m'embête c'est le fait que ce message est plutôt vague. Il me faut donc avoir un logging plus détaillé.

persistence.xml

Pour ce faire, j'ai activé les logging de requêtes dans persistence.xml

 

C'est un bon début, mais je ne vois toujours pas les requêtes de création de tables qui m'intéressent...

log4j.properties

La première chose à faire est d'ajouter un fichier "log4j.properties" au bon endroit dans ce projet qui utilise "Maven" : Voici le contenu du fichier. J'y suis allé franchement en mettant les niveaux de logging à "debug" de manière à récupérer un maximum d'informations.

log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.Target=System.out
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.stdout.layout.ConversionPattern=%d{ABSOLUTE} %5p %c{1}:%L - %m%n
 
log4j.rootLogger=warn, stdout
log4j.logger.org.hibernate=debug, stdout
log4j.logger.org.hibernate.SQL=debug, stdout
log4j.logger.org.hibernate.type=debug, stdout
log4j.logger.org.hibernate.engine.QueryParameters=debug, stdout

Solution

En fouillant dans ce logging très détaillé, je trouve le problème suivant :

09:12:59,704 DEBUG SchemaExport:415 -
    create table NOM_DE_LA_TABLE (
        CLE integer not null,
        ...
        primary key (CLE)
    ) type=InnoDB
Cette requête n'est pas correcte. "type=InnoDB" ne fonctionne pas avec ma version de MySQL, il faudrait "Engine=InnoDB". Je dois donc, simplement, changer le dialecte SQL :
<property name="hibernate.dialect" value="org.hibernate.dialect.MySQLInnoDBDialect"/>
<property name="hibernate.dialect" value="org.hibernate.dialect.MySQL5InnoDBDialect"/>

Conclusion

En fait, j'avais créé moi-même le problème en utilisant le mauvais dialecte MySQL. Mais, sans un bon système de logging, je n'avais aucun moyen de m'en apercevoir. Je me dis que ça peut arriver à n'importe qui...

Serveur Virtuel Slitaz/MySQL

Introduction

Pour les besoins d'un cours sur les bases de données, j'ai créé une machine virtuelle linux contenant le SGBD-R MySQL. Les contraintes sont les suivantes :

  • Minimiser l'espace disque occupé
  • Utiliser le système de virtualisation VirtualBox présent sur les machines (Windows) à disposition
  • Serveur de base de données accessible uniquement en ligne de commande

Création de la machine virtuelle

Sous VirtualBox, créer une nouvelle machine

Avec un disque de 1Gb

Résumé de la machine à créer

Machine virtuelle prête

Paramétrage réseau

Dans un premier temps, le réseau est configuré en NAT. La machine virtuelle va donc se connecter au réseau de l'entreprise et recevoir une adresse IP via DHCP.

CD-ROM

Ajouter un lecteur CD-ROM avec l'image du disque : slitaz-3.0-base.iso

Installation de Slitaz

La distribution Linux choisie pour ce serveur est Slitaz 3.0. Celle-ci à l'avantage d'être très compacte et peu gourmande en ressources.

Démarrage du disque d'installation

Il est important de choisir l'anglais comme langue d'installation, un bug empêche d'utiliser une autre langue.

Le login pour l'installation est root/root

Partitionnement

Le disque dur virtuel de 1Gb créé précédemment est accessible dans /dev/sda

Pour ce faire, il faut utiliser l'antique "fdisk" :

  • Ajouter une partition /dev/sda1 en Linux-Swap de 250Mb
  • Ajouter une partition occupant le reste de l'espace en Linux et rendre cette partition bootable

Formattage

Pour formater les deux partitions, il faut utiliser les commandes suivantes.

root@slitaz:~# mkfs.ext3 /dev/sda2
root@slitaz:~# mkswap /dev/sda1

Téléchargement et montage du CD-ROM d'installation

Malheureusement, un bug dans la routine d'installation empêche d'utiliser l'image du disque utilisée comme disque de boot comme source de données (unable to find rootfs.gz). Pour contourner ce problème, il faut télécharger le disque une nouvelle fois et le monter manuellement.

 Installation de slitaz

Seuls les paramètres nécessitant une configuration sont présentés.

Voilà, l'installation est terminée.

Il faut maintenant éteindre cette machine avant de passer à la suite.

 

Installation des outils

Il faut commencer par retirer l'image du CD-ROM utilisée pour l'installation

Ensuite, il faut redémarrer le système

Après avoir choisi la langue et le clavier, nous sommes prêts pour l'installation des outils

Nano

Installer un éditeur plus confortable que vi.

 

Serveur sftp

Pour pouvoir transmettre des fichiers à la machine virtuelle via SSH

Serveur MySQL

Toute cette installation vise justement à déployer un serveur de base de données MySQL.

Mise en oeuvre des outils

Une fois les outils installés, une petite configuration s'impose pour en avoir une utilisation confortable.

Démarrage automatique de SSH et MySQL

Il s'agit maintenant d'ajouter dropbear et mysql à la liste des daemons à démarrer (variable RUN_DAEMONS)

# /etc/rcS.conf - Initial boot script configuration for SliTaz GNU/Linux.
# Config file used by /etc/init.d/rcS
#
 
# Use udev to populate /dev and handle hotplug events.
UDEV="yes"
 
# Clean up the system removing all tmp and pid files.
CLEAN_UP_SYSTEM="yes"
 
# Filesystems to check integrity of at boot time. You should check the
# rootfs (where SliTaz is installed) and all partitions listed in
# /etc/fstab. Example : CHECK_FS="/dev/hda5 /dev/hdb1"
CHECK_FS="/dev/sda2"
 
# Fast boot into X by setting the system keymap-locale and starting
# the Slim login manager earlier at boot time. If fast X is enabled
# then dbus, hald and slim can be removed from RUN_DAEMONS.
FAST_BOOT_X="no"
 
# Start Kernel log daemons (syslogd and klogd).
KERNEL_LOG_DAEMONS="yes"
SYSLOGD_ROTATED_SIZE="60"
 
# Kernel modules to automatically load at boot time. You can use 'modprobe -l'
# to get a list of all kernel modules available.
#
# For Intel and some Nvidia sound cards : snd_intel8x0 snd_intel8x0m snd_hda_intel
#
LOAD_MODULES="  e1000"
 
# Initialization scripts to run at boot time. Boot order is important,
# bootopts.sh (boot options) must start first, hwconf after network (tazx
# needs an active connection to install Xorg), then you are free to choose.
# Note that the local.sh script exists to let you quickly add some local startup
# commands.
RUN_SCRIPTS="bootopts.sh network.sh i18n.sh hwconf.sh local.sh"
 
# Daemons to start at boot time. SliTaz only provides a few daemons: firewall,
# Web server (lighttpd), SSH server (dropbear) and rsyncd, so boot order is
# not really important, but dbus/hald should be started before slim.
RUN_DAEMONS="dbus hald firewall slim dropbear mysql"
 
# Pre login bold message.
MESSAGE="Welcome to your box."

Démarrage automatique de SFTP

Réseau local virtuel

Il s'agit maintenant de mettre la machine virtuelle dans le réseau virtuel créé par VirtualBox.

Connexion SSH

Dans cette partie, nous allons utiliser la connexion SSH pour administrer le serveur en ligne de commande. Pour plus d'informations à ce sujet, je vous invite à consulter le site du zéro

Accès root

Par défaut, la configuration de Slitaz empêche la connexion en "root". Cette machine virtuelle étant une simple machine de test, nous n'avons pas besoin d'un bon niveau de sécurité. Nous allons donc autoriser l'accès "root".

Ensuite, il s'agit d'enlever les paramètres -w et -g pour le démarrage de dropbear.

Une fois cette configuration terminée, un redémarrage de la machine virtuelle redémarrera aussi le daemon "dropbear" dans le mode qui nous intéresse.

PuTTY, le client Windows

Pour se connecter via SHH au serveur, il existe, par exemple, le logiciel PuTTY.

Transfert de fichiers via SSH

Etant donné que nous avons installé un serveur SFTP, il s'agit maintenant d'utiliser un client Windows pour transférer des fichiers. Il y a, par exemple le  logiciel WinSCP qui permet de le faire.

Ce logiciel fonctionne comme la plupart des clients FTP, la partie gauche présente les fichiers du disque de la machine cliente et la partie droite, le disque du serveur.

Conclusion

Ca y est, nous disposons maintenant d'une machine virtuelle de test pour travailler avec MySQL en ligne de commande. Pour conclure, vous une dernière capture présentant l'occupation disque de toute notre installation :

L'installation est plutôt compacte. 61Mb pour l'OS, les serveurs SSH et SFTP ainsi que le moteur de base de données MySQL.