Déployer un WAR avec Tomcat

Maintenant que le fichier d'archive 'war' est prêt, il va pouvoir être déployé. Le serveur utilisé ici, est Tomcat.

Prérequis:

• base de données mysql de l'application
  
• Pouvoir démarrer le serveur mysql contenant la database de l'application
  
• Pouvoir démarrer le serveur Tomcat (manuellement, service, ou Eclipse)

Le fichier de contexte contient le paramétrage du déploiement de l'application. Il joue donc un rôle important ! Il doit être placé dans le répertoire 'rep_Tomcat/conf/Catalina/localhost'. Il permet de préciser ou se trouvent les fichiers de l'application. Il peut également contenir des paramétrages divers appelés par l'application. Mais surtout, et c'est très important, il contient les ressources associées.
Dans notre cas, il faut configurer la connection à la base mysql dans le fichier de contexte:

• nom de la base
• port d'accès à la base
• utilisateur / mot de passe de connexion
• driver mysql

Ex de contenu de fichier de contexte:

<Context path="mon_appli" reloadable="true" workDir="work" >

<!-- Application parameters -->   
<Parameter name="application_name" value="mon_appli" override="false"/>
<Parameter name="database_name" value="MYSQL" override="false"/>
<Parameter name="mon_param" value="ma_valeur" override="false"/>
<Parameter name="debug_mode" value="false" override="false"/>

<!-- JDBC ressource -->
<Resource name="jdbc/mon_appli" auth="Container" type="javax.sql.DataSource" maxActive="100" maxIdle="30" maxWait="10000"  username="root"
password="root" driverClassName="com.mysql.jdbc.Driver" url="jdbc:mysql://localhost:3306/nom_database?jdbcCompliantTruncation=false" />

</Context>

Avant de déployer l'archive WAR, il est impératif de vérifier que dans le fichier 'rep_Tomcat/conf/server.xml', au niveau de la balise 'host', l'attribut 'autoDeploy' a bien pour valeur 'true'. On peut ensuite copier le fichier war dans le répertoire 'rep_Tomcat/webapps'. Au prochain démarrage du serveur Tomcat, le war sera décompressé automatiquement dans le répertoire 'webapps'.

La connection à l'application se fait avec l'url 'http://localhost:8080/nom_fichier_war/index.htm'

 

Auteur: Euan MATEO

Créer un 'war' avec Eclipse et Ant

Dans la note précédente, il a été vu que l'on peut créer une archive 'jar' à partir d'un fichier de description 'jardesc' avec Eclipse. L'archive 'jar est utilisée pour exécuter une application JAVA sur une machine virtuelle JAVA (commande java sous DOS).

Dans le cas du déploiement d'une application 'web' JAVA, il convient d'exporter le projet Eclipse sous forme de WAR ( Web ARchive). L'archive peut ensuite être copiée dans le répertoire de déploiement d'un serveur Java. Dans le cas présent, la finalité sera de copier l'archive WAR dans le répertoire 'webapps' d'un serveur Tomcat.

Le format 'war' est en fait un 'jar' qui doit contenir un répertoire "WEB-INF" qui lui-même contient:

• un descripteur de déploiement 'web.xml'
• un répertoire 'classes' où sont placés les '.class' du code compilé
• un répertoire 'lib' où se trouvent les librairies externes 'jar'

L'archive 'WAR' peut être générée à l'aide d'ANT. Il existe en effet une tâche ANT dédiée à cette opération. Le nom de cette tâche est 'war'. L'attribut 'destfile' permet de préciser le nom de l'archive war à créer. Et l'attribut 'webxml' permet de spécifier le nom du fichier web.xml à utiliser pour déployer l'application web.

Pour constituer le contenu de l'archive on utilise divers tags:

• <classes> pour préciser où se trouvent le code compilé '.class'
• <lib> pour les libraires '.jar' externes
• <zipfileset> pour grouper des fichiers et des répertoires (dont on peut exclure des éléments)
  

Exemple de cible ANT pour la génération d'un WAR:

<property name="jsp.dir" value="WEB-INF/jsp" />   
<property name="css.dir" value="stylesheet" />   
<property name="xsl.dir" value="WEB-INF/stylesheet" />       
<property name="xml.dir" value="WEB-INF/xml" />   
<property name="tld.dir" value="WEB-INF/tld" />   
<property name="scripts.dir" value="scripts" />
<property name="onlineHelp.dir" value="help" />       
<property name="images.dir" value="images" />   

<target name="War">
<description>
Creates a War file to deploy on Tomcat 
</description>
<echo message="Creation du War" />

<war destfile="rep_destination/mon_appli.war" webxml="WEB-INF/web.xml">    
<classes dir="WEB-INF/classes"/>       
<lib dir="WEB-INF/lib" />
<fileset dir=".">
<include name="*.jsp" />
<include name="*.html" />
<include name="*.htm" />
</fileset>
<zipfileset dir="${jsp.dir}" prefix="WEB-INF/jsp" />                   
<zipfileset dir="${scripts.dir}" prefix="scripts" />
<zipfileset dir="${onlineHelp.dir}" prefix="help" />
<zipfileset dir="${images.dir}" prefix="images" />         
<zipfileset dir="${css.dir}" prefix="stylesheet" />   
<zipfileset dir="${tld.dir}" prefix="WEB-INF/tld" >
<exclude name="CVS" />             
</zipfileset>         
<zipfileset dir="${xsl.dir}" prefix="WEB-INF/stylesheet" />
<zipfileset dir="${xml.dir}" prefix="WEB-INF/xml" />         
</war>
</target>

 

Ressources:

• The J2EE tutorial: http://java.sun.com/j2ee/tutorial/1_3-fcs/doc/WCC3.html
• Ant manual / Core tasks: http://ant.apache.org/manual/CoreTasks/war.html

Auteur: Euan MATEO

Commandes DOS utiles pour JAVA

• Lister le contenu d'une archive jar dans un fichier texte:

C:>jar -tf C:/chemin/jre/lib/rt.jar > rt.txt

Accès aux variables JAVA

Tableau récapitulatif

	private	default	protected	public
même classe	oui	oui	oui	oui
Même package Classe fille	non	oui	oui	oui
Même package Non classe fille	non	oui	oui	oui
Package différent Classe fille	non	non	oui	oui
Package différent Non classe fille	non	non	non	oui

Quelques notions essentielles JAVA

• Variable statique

- La valeur est la même pour toutes les instances de la classe
- Une variable statique est initialisée au chargement de la classe (première instance)

• Méthode statique

- Elle ne s'applique pas sur une instance de classe
- Elle n'utilise pas de variable d'instance
- Elle ne peut pas faire appel à des méthodes non-statiques

• Encapsulation

- Permet de limiter l'accès direct aux variables d'un objet
- Les variables sont déclarées 'private'
- L'accès se fait avec des méthodes 'get' et 'set'

• Polymorphisme (à vos souhaits)

Le type de référence à un objet est la superclasse de l'objet. Par ex:
Animal animal = new girafe()

Le polymorphisme est particulièrement interessant pour créer des listes, qui pourront contenir des objet du type de la classe parent.

• Sérialisation

- Permet de sauvegarder l'état d'un objet
- Une classe sérialisable implémente l'interface 'serializable'
- Le objets 'serializable' peuvent être lus ou écrits dans un flot (fichier ou autre)
- Le flot de traitement doit être chainé à un flot de communication
- Pour exclure une variable de la sérialisation, utiliser le mot clef 'transient'
- Les variables statiques ne sont pas sérialisées

Auteur: Euan MATEO

Ajouter un plugin Eclipse en ligne

La manière la plus propre d'ajouter un plugin pour Eclipse, est d'enregistrer le site distant avec  le gestionnaire de plugins en-ligne d'Eclipse. On peut y accéder par le menu Aide (fr) ou Help (en):

On ouvre alors la fenêtre d'installation qui permet de saisir l'url depuis laquelle il est possible de télécharger et mettre à jour le plugin. Pour enregistrer un nouveau site avec l'interface Eclipse en langue anglaise, il faut cliquer sur 'New Remote Site...'

On peut alors créer une nouvelle entrée dans la liste des sites distants, la nommer, et lui associer une url.

Quelques plugins interessants:

• CSSEditor - url plugin: http://csseditor.sourceforge.net/
• JSEclipse - SITE - url plugin: http://download.macromedia.com/pub/labs/jseclipse/autoins...

Auteur: Euan MATEO

Ecrire dans un fichier texte

Comment écrire dans un fichier texte avec java ?

Tout simplement avec un FileWriter et BufferedWriter. Ci dessous un exemple de code:

Auteur: Euan MATEO

JUnit pour tester son code JAVA

'JUnit' est un utilitaire codé en JAVA pour tester du code JAVA. Chaque test constitue un test 'unitaire'.

• A propos de 'JUnit'

Cette librairie permet de créer un test, ou une suite de test, qui sont exécutés de manière automatique.  Ainsi, les tests appliqués au code de l'application sont identiques à chaque fois. Le développeur n'a pas à exécuter une séquence de test, toujours dans le même ordre, manuellement. JUnit permet de maintenir la qualité du code dans le temps, même si des évolutions sont apportées. JUnit est un outil très apprécié dans la pratique de "l'extreme programming".

Les résultats de l'exécution des tests peuvent être affichés sous la forme textuelle, ou bien présentés par une interface graphique (SWING, ou AWT).

Pour utiliser JUnit, il faut commencer par placer l'archive 'junit.jar' dans le classpath de l'application.

• Rédaction d'une classe de test, avec le 'framework JUnit'

La classe de test doit étendre la classe 'junit.framework.TestCase'. Les tests à effectuer sont regroupés dans les méthodes de cette classe. Pour que JUnit puisse localiser les méthodes de test automatiquement, il faut que leur nom commence par 'test', que la méthode soit 'public' et sans argument.

ex.:
import junit.framework.*;

public class monTest extends TestCase {
 
  public void testQQChose() {
    ...
  }
 
  public void testAutreChose() {
    ...
  }
}

Les comparaisons qui doivent être validées, se font avec les fonctions assertXXX() (cf doc. API JUnit).
Par exemple, pour vérifier l'égalité de deux chaines de caractères, on utilisera la fonction "assertEquals("message d'erreur", chaine1, chaine2)".

Plusieurs tests peuvent être codés dans la même méthode de test. Mais, il faut savoir que l'échec d'un test d'une méthode, entraine l'echec des autres tests de la méthode. Il faut donc faire attention à ne pas 'masquer' des résultats d'autres tests, suite à l'échec d'un test.

Les créations d'objets (fixtures) communes à plusieurs tests peuvent être initialisés et regroupés dans la méthode 'setUp()'.
La méthode 'setUp()' est exécutée avant chaque test (ex: ouvrir une connection). De même, une fonction 'tearDown()' est exécutée après chaque test. Ce qui est utile, pour libérer des ressources (ex: fermer une connection), par exemple.

• Création d'une suite de tests

Les différentes méthodes de test peuvent ensuite être agencées en 'suite'. Une suite permet de définir un ordre, et des conditions d'exécution pour les tests.
ex:
public static Test suite() {
  TestSuite suite = new TestSuite();
  suite.addTest(new monTest("testQQChose"));
  suite.addTest(new monTest("testAutreChose"));
  return suite;
}

• Lancer l'exécution d'une classe de test individuellement par programmation

Pour exécuter les test individuellement par programmation, il faut rajouter une méthode 'main' à la classe de test. ex:
public class TestEmployeeForm extends TestCase {
 ...
 public static void main(String[] args) {
  junit.textui.TestRunner.run(new TestSuite(TestEmployeeForm.class));
 }
}

Suivant que l'on souhaite visualiser les résultats en mode texte, avec une interface graphique 'SWING', ou avec une interface graphique 'AWT', on utilisera la méthode 'run' du package 'junit.textui.TestRunner', 'junit.swingui.TestRunner', ou 'junit.awtui.TestRunner'.

• Execution des tests avec ANT

Il est possible de lancer l'exécution des tests depuis Ant. Il suffit pour cela de rajouter une cible (target) 'junit' correspondante. Celle-ci dépend de la compilation:
ex:
  <target name="junit" depends="compile">
    <junit showoutput="true" outputtoformatters="true" printsummary="yes" haltonerror="true" fork="false" >
      <classpath>
        <pathelement location="${classes.dir}" />
      </classpath>
      <formatter type="plain" usefile="false" />  
      <test name="yoz.form.TestEmployeeForm" fork="false" />
    </junit>
  </target>

A noter, qu'il faut inclure le répertoire contenant la classe de test, dans le 'classpath':
"<classpath><pathelement location="${classes.dir}" /></classpath>"
C'est la racine du répertoire qui doit être spécifiée, afin de conserver l'organisation des packages. Dans le cas contraire, une erreur est lancée par le classloader lors de l'exécution d'ant, car la classe de test reste introuvable.

La tâche Ant à effectuer est 'junit'. Cette tâche est accompagnée de paramètres. L'affichage des résultats des tests, se fait textuellement soit par la console, soit dans un fichier texte.

Références:
- 'Java Extreme programming Cookbook' aux éditions O'Reilly, par Mr Burke, et Mr Coyner
- 'JUnit Test Infected: Programmers Love Writing Tests', doc livrée avec l'archive 'junit'
 - 'Optional Tasks/JUnit', documentation livrée avec l'archive 'ant'

Auteur: Euan MATEO

Data Access Object: un peu de souplesse dans un monde de brutes

Le Data Access Object (Abstract) Factory est ce que l'on appelle un 'Design Patern'.

'DAO Factory' fait le lien entre la couche métier et l'accès aux données d'une application.
Le but de cette technique est de rendre la couche métier indépendante de la manière dont
l'accès aux données se fait. Ainsi, il est plus facile de migrer d'un système de base de
données vers un autre, ou de changer la manière dont on veut accéder aux données.

La couche DAO permet d'instancier des objets d'accès aux données, pour chaque type
de données (utilisateur, commande, facture..). Concrètement, les méthodes proposées
par les objets d'accès aux données, pour la manipulation des données dans la couche métier,
ne dépendent pas du choix de stockage et d'accès aux données.

L'utilisation d'un shéma d'héritage pour la fabrique, fait que la couche métier
ne sait rien de la manière dont est fabriqué l'objet de connection.
Avec l'utilisation d'une interface pour les objets d'accès aux données, la couche métier
appelle les mêmes méthodes pour effectuer des opérations sur les données,
quelque soit la manière dont on accède aux données.


Le diagramme UML d'un DAO se présente ainsi:

(Insérer schema)

+ Chronologie pour une nouvelle DAO +

1) On crée une fabrique abstraite DAOFactory qui pourra être étendue/sous-classée.
Ajout d'une méthode, et de constantes statiques pour proposer le choix de la fabrique
2) Une sous-classe de DAOFactory (=fabrique) est créee pour chaque type de base de données, ou de connection.
Chaque fabrique permet de créer tous les objets DAO nécessaires à la manipulation des données
métier (ex: employé, utilisateur, commande, facture..)
3) Création d'une interface pour chaque classe d'accès aux données, qui regroupe
les opérations/méthodes disponibles (ex: create, update, delete, edit, list..)
4) Création des classes d'accès aux données qui implémentent l'interface (cf 3)
5) Intégration de la DAO dans le code applicatif:
- Nouvelle fabrique
- Nouvel objet DAO
- Appel de méthode sur l'objet DAO


Références:
- http://java.sun.com/blueprints/corej2eepatterns/Patterns/... > Data Access Object
- "Design Patterns: Elements of Reusable Object-Oriented Software" écrit par Gamma, Helm, Johnson, Vlissides

Auteur: Euan MATEO

Log4j: Logging pour Java

Log4J est une API JAVA (bibliothèque logicielle) qui permet de créer et de stocker des messages, pendant l'exécution du code. Cet outil très apprécié des developpeurs JAVA, offre la possibilité de paramétrer finement l'émission des messages. Ainsi, Log4j  permet de choisir la sortie du flot des messages (console, fichier texte..), mais également le niveau d'information donné (info, warn, debug..).

L'archive jar de la bibliothèque Log4J est téléchargeable ICI.

Pour pouvoir être utilisée, la bibliothèque associée à Log4j doit être placée dans le classpath du projet JAVA développé. C'est à dire, soit dans le répertoire 'lib' du projet, soit dans le répertoire 'lib' du serveur (si exécution sur un serveur).

Le comportement de Log4J est précisé dans un fichier de configuration. Deux formats sont disponibles, 'log4j.properties' contient des couples clef/valeur, ou 'log4j.xml' au format xml. Le format xml est préférable car il permet un contrôle plus fin du paramétrage, dont par exemple l'usage de filtres.

Le fichier de configuration de Log4j permet d'indiquer des 'appenders', des 'loggers', et des 'layouts'.

Un 'appender' est le moyen utilisé pour afficher les messages. Autrement dit, un 'appender' est une sortie. Les 'appenders' courants sont la console (ex: la console du serveur Tomcat), ou un fichier texte. Mais, on peut également rediriger les messages vers une base de données. Ainsi, si on veut utiliser la console pour afficher les messages émis par Log4j, la classe 'org.apache.log4j.ConsoleAppender' sera utilisée. Si on souhaite que les messages soient redirigés vers un fichier texte, on pourra se servir de la classe 'org.apache.log4j.RollingFileAppender'. Techniquement, 'appender' est l'interface 'org.apache.log4j.Appender'. Les classes qui définissent les appenders (console, file..) implémentent toutes l'interface 'Appender'.

Le 'logger' est l'objet qui effectue la journalisation. Le niveau minimum des messages émis est défini par le logger. Il peut être: all, no, debug, info, warn, error, fatal. L'appel pour créer un nouveau log se fait par l'usage de la classe 'Logger':

import org.apache.log4j.Logger;

public class uneClasse {

private Logger log = Logger.getLogger(uneClasse.class);

log.info("+ Test de logging +");

}

Le 'layout' définit la présentation utilisée par log4j pour l'écriture des messages. Il existe des layouts prédéfinis comme 'org.apache.log4j.SimpleLayout', ou configurables 'org.apache.log4j.PatternLayout'.

Exemple de fichier de configuration 'log4j.xml' complet:

    <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE log4j:configuration SYSTEM "log4j.dtd" >
    <log4j:configuration xmlns:log4j='http://jakarta.apache.org/log4j/'>
      <appender name="console" class="org.apache.log4j.ConsoleAppender">
        <layout class="org.apache.log4j.SimpleLayout"></layout>
      </appender>
      <appender name="fichier" class="org.apache.log4j.RollingFileAppender">
        <param name="maxFileSize" value="100KB"/>
        <param name="File" value="../webapps/monProjet/log.txt"/>
        <param name="threshold" value="warn"/>
        <layout class="org.apache.log4j.PatternLayout">
          <param name="ConversionPattern" value="%d{ABSOLUTE} %5p %c{1}: message => %m%n" />
        </layout>
      </appender>
      <root>
        <priority value="debug"/>
        <appender-ref ref="console"/>
        <appender-ref ref="fichier"/>
      </root>
    </log4j:configuration>                          

L'exemple va créer une sortie sur la console avec un niveau 'debug', et une sortie dans un fichier du répertoire du projet, avec un niveau 'warn'.

Quelques remarques concernant l'exemple ci-dessus:

• Le fichier 'log4j.xml' doit être placé dans le ClassPath de l'application, 'WEB-INF/classes' par exemple
• Le chemin vers le fichier de log peut être défini de manière relative. La racine du chemin est alors le répertoire d'exécution du serveur (si exécution sur un serveur). Le répertoire 'bin' pour un serveur tomcat.
  
• Le logger racine est contenu par la balise 'root'
• Le niveau de journalisation de log4j peut être défini de manière globale pour tous les appenders associés à un logger. C'est le rôle de la balise <priority> qui est incluse dans la balise <root>
• Le niveau de journalisation peut aussi être redéfini au niveau de chaque appender, avec le paramètre 'threshold' de la balise <param>
• Les conventions pour créer un PatternLayout sont visibles dans la doc de l'API: PatternLayout
  

Vos commentaires sont bienvenus !

Références:

• Tutoriel Log4j sur Developpez.com: http://beuss.developpez.com/tutoriels/java/jakarta/log4j/
• Cours sur Log4j par Labo-Sun: http://www.labo-sun.com/resource-FR-articles-612-0-java-g...
• Tutoriel Log4J avec exemples Tomcat, par Laliluna: http://www.laliluna.de/log4j-tutorial.html
• Encore un bon tutoriel Log4j: http://www.vipan.com/htdocs/log4jhelp.html

Auteur: Euan MATEO