Java pour les nuls, ou Tecka va tout planter Options

Sommaire évolutif et approximatif :

1. les installations
2. spécifications de l'application
3. création de la base et des tables
4. création du projet Eclipse, mise en place du log
5. mise en place de l'authentification Tomcat
6. connexion Java-MySQL
7. récupérations d'informations dans la base
8. génération du flux XML des actualités
9. transformation et affichage du flux XML
10. construction du modèle des pages HTML
11. écriture des requêtes de modification/ajout/suppression
12. écriture des pages de modification/ajout/suppression
13. prototype + scriptaculous : le javascript fiable, facile et spectaculaire
14. saisie facile des dates
15. validation des données saisies
16. écriture de la servlet publique
17. génération du flux Atom

Troisième étape : création de la base et des tables

(en passant, les étapes correspondent grosso modo aux étapes que je suis quand je développe une application. Une application même modeste c'est un gros truc (une vingtaine d'heures pour celle là en comptant les recherches sur google et les essais). C'est pour ça qu'il est important de se fixer des petits pas, toujours plus ou moins les mêmes, à réaliser les uns après les autres pour avancer, sinon on a vite fait de partir dans tous les sens sans avancer réellement).


En analysant les spécifications, on peut distinguer plusieurs entités de différentes natures :
- un jeu bien sûr
- un éditeur (Sony, Activision,...)
- un support (Wii, PSP, PS3,...)
- un format (ou territoire) (EU, US, Jap)
- une sortie

Si on s'intéresse aux relations entre ces objets on a d'après les spécifications :
- un jeu a un éditeur unique, mais un éditeur peut produire plusieurs jeux
- un jeu peut sortir sur plusieurs supports, et un support peut accueillir plusieurs jeux
- un jeu, sur un support donné, peut sortir sur plusieurs territoires (une seule fois pour chaque au maximum) et un territoire peut avoir plusieurs jeux différents qui sortent dessus
- une sortie se caractérise donc par un jeu sur un support dans un territoire

En terme relationnels on a donc (par convention N signifie ici "nombre quelconque") :
- jeu-éditeur : relation 1-N (un seul éditeur par jeu, N jeux par éditeur)
- jeu-support : relation N-N (N supports par jeu, N jeux par support)
- jeu-format : relation N-N? En fait le format d'un jeu n'est intéressant pour nous que si le jeu est associé à un support (exemple : sur XBox360 Final Fantasy XIII ne sortira pas au Japon, contrairement à la PS3). Donc :
- jeu-format-support : triplet définissant de manière unique une sortie
(il n'y a pas de solution unique, certaines interprétations des spécifications peuvent être fausses, c'est pour ça qu'il est utile de s'assurer auprès du client à chaque étape qu'on comprend bien son besoin. Ici vu que c'est moi le client je suis d'accord avec moi-même )

Une fois qu'on a dégagé ces relations, le plus dur est fait au niveau du design de la base de données.
En effet :
- relation 1-N => l'identifiant de la table unique va se retrouver dans la table N
- relation N-N => une table de liaison intermédiaire entre nos deux tables est nécessaire pour obtenir cette articulation

Ce qui donne :
- une table éditeur toute simple
- une table support toute simple
- une table format toute simple
- une table jeu, comportant l'identifiant de son éditeur
- une table de liaison entre un jeu et un support
- une table de liaison entre un jeu, un support et un format (ce sera notre table "sortie")


Avant d'attaquer nos tables, créons notre base (explications minimales, ne pas hésiter à se manifester si quelque chose bloque !) :
- Vérifier que le démon mysqld est lancé par le prefpane MySQL
- Avec l'application MySQL Administrator, se connecter (root sans mot de passe sur localhost:3306 par défaut)
- Créer un utilisateur (Accounts) videogames (mot de passe videogames)
- Choisir cet utilisateur dans la liste et configurer les hosts (enlever % et ajouter localhost, 127.0.0.1 et le nom de l'ordinateur (mini.local pour moi par exemple) (sur mon image j'ai aussi configuré une plage d'IP (192.168.0.%) pour me connecter à la base depuis mon MacPro pour développer car Eclipse ramait trop sur le mini...)


- Sur l'onglet Catalogs, créer le schéma videogames_db (ne pas tenir compte des tables qu'on voit dans cette image, on va les créer juste après)


- Sur l'ongle users, pour chaque host de l'utilisateur videogames, choisir tous les droits et les ajouter pour le schéma videogames_db


On va ensuite créer les tables par script (en effet graphiquement, par l'application d'administration il y a quelques limitations, en particulier pour la création des dates).
On lance donc l'application MySQL Query Browser et on se connecte comme ceci :


On tape les scripts directement dans un onglet "Query", puis "Execute" pour les exécuter :


En script (My)SQL cela donne :
- table format :

CODE

CREATE TABLE `videogames_db`.`VG_FORMAT` (
`form_id` BIGINT NOT NULL AUTO_INCREMENT,
`form_label` VARCHAR(64) NOT NULL,
PRIMARY KEY (`form_id`)
)
CHARACTER SET utf8;

Explications :
- form_id est l'identifiant de la table, c'est un nombre qui peut être grand (BIGINT), non nul (NOT NULL), qui s'incrémente seul si non spécifié lors d'une insertion de données (AUTO_INCREMENT) et qui sera l'accès privilégié à la table comme moyen de récupération d'une information en particulier (PRIMARY KEY)
- form_label est le nom du format, c'est une chaîne de caractères (64 maximum) qui ne peut être nulle

- table éditeur :

CODE

CREATE TABLE `videogames_db`.`VG_EDITEUR` (
`edit_id` BIGINT NOT NULL AUTO_INCREMENT,
`edit_name` VARCHAR(64) NOT NULL,
PRIMARY KEY (`edit_id`)
)
CHARACTER SET utf8;

Idem format

- jeu :

CODE

CREATE TABLE `videogames_db`.`VG_JEU` (
`jeu_id` BIGINT NOT NULL AUTO_INCREMENT,
`jeu_titre` VARCHAR(128) NOT NULL,
`jeu_editeur_id` BIGINT NOT NULL,
`jeu_description` TEXT,
`jeu_previews` TEXT,
`jeu_tests` TEXT,
`jeu_date_creation` TIMESTAMP NOT NULL,
`jeu_date_modification` TIMESTAMP NOT NULL,
PRIMARY KEY (`jeu_id`)
)
CHARACTER SET utf8;

Explications :
- jeu_id idem
- jeu_titre : le titre du jeu, ne peut être nul
- jeu_editeur_id : notre identifiant caractérisant l'éditeur unique d'un jeu. Ne peut être nul
- jeu_description : texte long (idem pour jeu_previews et jeu_tests qui recevront des liens vers previews et tests)
- jeu_date_creation : date-heure non nulle
- jeu_date_modification : idem jeu_date_creation

- table support :

CODE

CREATE TABLE `videogames_db`.`VG_SUPPORT` (
`supp_id` BIGINT NOT NULL AUTO_INCREMENT,
`supp_label` INT,
PRIMARY KEY (`supp_id`)
)
CHARACTER SET utf8;

Explications : idem tables éditeur et format

- liaison jeu-support :

CODE

CREATE TABLE `videogames_db`.`VG_JEU_SUPP` (
`jesu_jeu_id` BIGINT NOT NULL,
`jesu_supp_id` BIGINT NOT NULL,
`jesu_description` TEXT
)
CHARACTER SET utf8;

Explications :
- jesu_jeu_id : l'identifiant du jeu concerné
- jesu_supp_id : l'identifiant du support concerné
- jesu_description : un petit texte précisant les spécificités du jeu sur le support (ex: compatible Balance Board)

- liaison jeu-support-format :

CODE

CREATE TABLE `videogames_db`.`VG_JEU_SUPP_FORM` (
`jesf_jeu_id` BIGINT NOT NULL,
`jesf_supp_id` BIGINT NOT NULL,
`jesf_form_id` BIGINT NOT NULL,
`jesf_date` TIMESTAMP NULL,
`jesf_description` TEXT
)
CHARACTER SET utf8;

Explications : notre table des sorties
- jesf_jeu_id / jesf_supp_id / jesf_form_id : les identifiants standard
- jesf_date : la date de la sortie, peut-être nulle si la date est encore inconnue
- jesf_description : un petit texte décrivant les spécificités éventuelles de la sortie du jeu sur ce support (ex: pas de sang sur No More Heroes européen)



On va ensuite insérer quelques données pour pouvoir commencer à travailler (commit permet de valider l'insertion de données, rollback permet de les annuler) :
- les formats :

CODE

insert into VG_FORMAT(form_label) values('EU Pal');
insert into VG_FORMAT(form_label) values('US NTSC');
insert into VG_FORMAT(form_label) values('Jap NTSC');
commit;

- les supports :

CODE

insert into vg_support(supp_label) values ('Wii');
insert into vg_support(supp_label) values ('DS');
insert into vg_support(supp_label) values ('Mac');
insert into vg_support(supp_label) values ('PC');
insert into vg_support(supp_label) values ('PS3');
insert into vg_support(supp_label) values ('PS2');
insert into vg_support(supp_label) values ('PSP');
insert into vg_support(supp_label) values ('XBox360');
commit;

- les éditeurs (on ajoutera ultérieurement une page pour administrer cela, pour le moment on se contente d'en mettre quelques uns pour tester tout ça) :

CODE

insert into vg_editeur(edit_name) values('Nintendo');
insert into vg_editeur(edit_name) values('Codemasters');
insert into vg_editeur(edit_name) values('Sega');
insert into vg_editeur(edit_name) values('Konami');
insert into vg_editeur(edit_name) values('Activision');
insert into vg_editeur(edit_name) values('LucasArts');
insert into vg_editeur(edit_name) values('Disney Interactive');
insert into vg_editeur(edit_name) values('505 Games');
insert into vg_editeur(edit_name) values('Square Enix');
insert into vg_editeur(edit_name) values('GOA');
insert into vg_editeur(edit_name) values('Koei');
insert into vg_editeur(edit_name) values('MTV Games');
insert into vg_editeur(edit_name) values('2K Games');
insert into vg_editeur(edit_name) values('EA');
insert into vg_editeur(edit_name) values('Capcom');
insert into vg_editeur(edit_name) values('THQ');
insert into vg_editeur(edit_name) values('Warner Bros. Games');
insert into vg_editeur(edit_name) values('XSeed Games');
insert into vg_editeur(edit_name) values('Microsoft');
insert into vg_editeur(edit_name) values('Sony');
insert into vg_editeur(edit_name) values('Ubisoft');
insert into vg_editeur(edit_name) values('JoWood');
insert into vg_editeur(edit_name) values('Ignition');
insert into vg_editeur(edit_name) values('Bethesda Softworks');
insert into vg_editeur(edit_name) values('Gamecock Media Group');
insert into vg_editeur(edit_name) values('Marvelous');
insert into vg_editeur(edit_name) values('Level5');
insert into vg_editeur(edit_name) values('Atlus');
insert into vg_editeur(edit_name) values('Blizzard');
commit;

[Edit]Un petit mot sur les règles de nommage des tables et colonnes : ça peut sembler chiant ou illisible mais ça fait en fait gagner énormément de temps d'avoir une règle immuable appliquée bêtement. En l'occurrence :
- les tables sont préfixées par un surnom unique pour la base ("vg_")
- les tables d'entités ont un nom lisible, les tables de liaison ont le nom accolé des tables qu'elles lient
- une colonne hérite du nom de la colonne qui la contraint au préfixe de table près (ex : "jesf_jeu_id" pour "jeu_id") (seul contre-exemple : j'aurai du appeler la colonne jeu_editeur_id "jeu_edit_id" pour être cohérent mais ça m'a échappé, tant pis )
- les noms de colonnes sont préfixés par quatre lettres (ou moins, cf "jeu") représentatives du nom de la table. De fait tout nom de colonne est unique dans la base, ça évite de devoir lever soi-même les ambiguïtés dans les requêtes SQL.

Ce message a été modifié par atarxerxes - 7 Oct 2008, 07:31.

Sommaire évolutif et approximatif :

1. les installations
2. spécifications de l'application
3. création de la base et des tables
4. création du projet Eclipse
5. mise en place du log
6. mise en place de l'authentification Tomcat
7. connexion Java-MySQL
8. récupérations d'informations dans la base
9. génération du flux XML des actualités
10. transformation et affichage du flux XML
11. construction du modèle des pages HTML
12. écriture des requêtes de modification/ajout/suppression
13. écriture des pages de modification/ajout/suppression
14. prototype + scriptaculous : le javascript fiable, facile et spectaculaire
15. saisie facile des dates
16. validation des données saisies
17. écriture de la servlet publique
18. génération du flux Atom

Création du projet Eclipse

Dans Eclipse, on va créer notre projet (New -> Dynamic Web Project), on lui choisit un nom intéressant ("vg_actus" par exemple).
Le reste des réglages devraient être corrects (normalement Eclipse choisit comme cible de développement notre serveur Tomcat déjà configuré (Target Runtime)).

On va passer le format du projet en UTF-8 : clic-droit sur le répertoire du projet -> Propriétés -> Resource -> Text file encoding : Other : UTF-8 -> Ok (pour ne pas être embêté ultérieurement par le format Mac (qui est un Unicode trafiqué (= qui ne respecte pas le standard) si je ne me trompe pas) lorsqu'on écrira des messages à afficher dans les classes Java.

Eclipse crée l'arborescence de notre projet :
- les pages à afficher dans un navigateur (et tout ce qui va avec : images, css, scripts,...) iront dans le répertoire WebContent
- les classes Java iront dans le répertoire src (Java Resources: src)
- le répertoire des fichiers de configuration de l'application (WEB-INF) ira ans WebContent

Un fichier important : web.xml dans WebContent/WEB-INF est le fichier principal de configuration de notre application.

----------------------------
Petit point important : qu'est-ce qu'une application J2EE?
En résumé c'est surtout un fichier web.xml. Les autres composants de l'application (scripts, pages html,...) sont communs aux autres applications web, mais c'est vraiment le fichier web.xml qui fait sa spécificité. C'est le document qui décrit le déploiement de l'application.
Plus d'informations sur ce qu'est une application web Java : http://java.sun.com/j2ee/1.4/docs/tutorial/doc/WebApp3.html
----------------------------

----------------------------
Deuxième point important : servlet? JSP?
Historiquement les servlets sont arrivées avant les JSPs. Une servlet est une classe Java, héritant de la classe HttpServlet. Cette classe servlet sera utilisée par le serveur chaque fois que certaines URLs seront demandées sur le serveur.
Quelles URLs? C'est en fait le développeur qui dira lesquelles prendre en compte (on verra ça dans une leçon ultérieure). A ce propos, une chose importante à comprendre : une URL ne représente rien (mais vraiment rien) à partir de la partie à droite du nom de l'application :
- cela ne dit rien sur l'organisation réelle des pages sur le serveur, ni même sur leur existence
- le serveur Java va analyser la partie droite de l'URL et chercher dans une grande table des matières s'il peut appeler une servlet correspondante. Sinon il essaiera de trouver un fichier à l'endroit indiqué à l'intérieur de l'application (par exemple une page HTML)
- par exemple on peut dire au serveur d'utiliser une servlet dès que l'URL se termine par *.html, cette servlet pouvant par exemple se charger de trouver un fichier XML de même nom que la page HTML demandée, pour le transformer en HTML et le renvoyer au client. Le client croit qu'une page HTML statique existe sur le serveur mais en fait la mise en page est générée dynamiquement à partir des fichiers XML de données brutes (c'est ce que fait en autres Cocoon).
Une servlet va écrire le contenu de la réponse à envoyer au client. Cela se fait de manière assez lourde (avec par exemple un println() pour chaque ligne de la réponse). Au début il n'existait que ce moyen pour écrire une réponse HTTP en Java mais rapidement on a trouvé que c'était un peu lourdingue inutilement sauf cas particuliers (en résumé : pour écrire du HTML c'est lourdingue, pour écrire autre chose c'est nickel).

Ensuite sont apparues les JSPs : il s'agit de pages HTML comportant du code Java (exactement le même principe que les pages php). La différence est ici que le code Java de la page JSP peut utiliser d'autres classes Java (qui sont des classes à part entière).
L'écriture de la page réponse consiste juste à renvoyer le code HTML de la page JSP avec le code Java exécuté produisant si besoin des blocs de code HTML supplémentaires. C'est strictement le même principe que les pages php (seule la syntaxe est un peu différente : <%... code Java...%> et <%=String Java%>).
L'écriture de page HTML de réponse est donc bien plus facile et naturelle.
En fait en interne, on a quand même affaire de manière cachée à une servlet qui est installée dans le serveur : si une URL qui finit par JSP/jsp est demandée, et qu'aucune servlet de l'application ne la prend en charge, cette servlet cherche une page JSP à l'endroit indiqué par l'URL, exécute le code Java contenu dedans, récupère le code HTML produit et le renvoie comme réponse.[edit]Ce que je dis n'est pas très clair : il y a un processus côté serveur qui transforme la page JSP utomatiquement en servlet la première fois où elle est appelée et c'est cette servlet qui est exécutée.[/edit]
En passant une notion difficile à comprendre au début :
- le code Java est exécuté côté serveur avant la réponse de celui-ci
- le code Javascript est exécuté au plus tôt lorsque la page HTML réponse a été entièrement chargée côté client
Il y a donc dans la majorité des cas impossibilité de piloter efficacement le Javascript par du Java sans réfléchir un peu à cet ordre de construction de la page (exemple : affichage d'un alert() en cas d'erreur Java).

Aujourd'hui les servlets sont encore utilisées principalement pour toute production de réponse autre que HTML (flux XML, récupération d'images,...), les pages JSP pour produire celles-ci.
----------------------------


On va commencer par créer une page jsp simple dans WebContent, par exemple une page qui n'affiche que "Page d'accueil" : sur le répertoire WebContent, clic-droit -> New -> HTML, on l'appelle index.jsp.

On ajoute ensuite juste le texte "Page d'accueil" entre les balises "body".


Pour tester notre application sur notre serveur, on fait un clic-droit sur le serveur dans l'onglet du même nom, on choisit "Add and Remove projects...", on choisit notre projet.

Notre projet est maintenant automatiquement mis-à-jour sur le serveur par Eclipse (en pratique il peut échouer à remplacer les classes Java déjà utilisées (donc chargées) sur le serveur quand il doit les recompiler, c'est pour cela qu'il est plus sûr de relancer le serveur quand on modifie du code Java).

On lance notre serveur si besoin (clic-droit -> "start" dessus).

On peut vérifier que notre page est désormais accessible en allant à "http://localhost:8080/vg_actus/index.jsp".

Ce message a été modifié par atarxerxes - 12 Oct 2008, 16:48.

Bon, à partir de la prochaine séance on attaque le développement proprement dit. Il ne reste déjà plus personne ou alors aucun des intéressés n'a eu de problème (ou alors vous attendez que ça commence réellement)?

Pour la suite, je mettrai tout le projet en l'état de la fin de la séance correspondante à chaque séance (en plus des indications dans le corps du message).

Ce message a été modifié par atarxerxes - 14 Oct 2008, 11:50.

Je n´ai pas réussi la création de la base et des tables. Je te mettrais les erreurs ce soir car j´ai un RDV maintenant

Alors?

My SQL Query Browser a des problèmes avec la commande commit:
insert into vg_editeur(edit_name) values('Blizzard');
commit;
Il m´indique un erreur code 106, en rentrant les éditeurs de jeu un par un, cela fonctionne

Bizarre, peut-être qu'il est en auto-commit et qu'il accepte pas qu'on le commite à la main

Cela dit erreur 106 c'est une erreur de syntaxe normalement.

Ce message a été modifié par atarxerxes - 15 Oct 2008, 10:35.

Pas le temps en ce moment, mais toujours intéressé. Je rattraperai plus tard, continuez sans moi, je prendrai le train en marche

pareil pour moi

Merde j'ai loupé un cours je fais ça ce week-end

Sommaire évolutif et approximatif :

1. les installations
2. spécifications de l'application
3. création de la base et des tables
4. création du projet Eclipse
5. mise en place du log
6. mise en place de l'authentification Tomcat
7. connexion Java-MySQL
8. récupérations d'informations dans la base
9. génération du flux XML des actualités
10. transformation et affichage du flux XML
11. construction du modèle des pages HTML
12. écriture des requêtes de modification/ajout/suppression
13. écriture des pages de modification/ajout/suppression
14. prototype + scriptaculous : le javascript fiable, facile et spectaculaire
15. saisie facile des dates
16. validation des données saisies
17. écriture de la servlet publique
18. génération du flux Atom

Mise en place du log

Le développement n'est pas un travail linéaire, partant d'un point A vers un point B sans problème. Le mode de travail est plutôt :
- je rajoute ça
- ça marche à peu près
- j'analyse les cas qui ne marchent pas
- je modifie mon code
Et cela boucle jusqu'à obtenir un résultat satisfaisant (marchant parfaitement ou le plus souvent, suffisamment correct c'est-à-dire correct dans suffisamment de cas concrets).
Cela décrit le processus de développement, mais on peut aussi découvrir à l'usage qu'on a oublié un cas qui ne marche pas lorsque l'application est réellement utilisée par les clients.

Il faut donc être capable d'analyser les cas qui ne marchent pas, et cela ne peut-être fait sans avoir des informations précises sur ce que l'application faisait au moment du problème.
C'est pour cela qui faut être capable de mettre en place une stratégie efficace de logging dans une application.
Les contraintes sont :
- traces en développement
- possibilité d'avoir aussi des traces en production
- accessibilité facile aux traces
- les traces doivent contenir des informations pertinentes (localisation, importance de l'anomalie, date)

Ce qui vient à l'esprit des développeurs débutants, de par sa grande facilité de mise en place est l'utilisation de l'écriture directe dans la console Java où s'exécute le programme. Cela se fait par l'utilisation de System.out.println("Mon super message");
Pourquoi c'est nul à l'usage d'utiliser ça?
- les traces sont affichées "à vie", il faut enlever l'appel à la méthode pour les supprimer, ça serait mieux si on pouvait les afficher que quand on cherche à localiser un problème
- on doit insérer nous-mêmes toutes les informations (en particulier cela va être à nous de préciser où (classe, méthode, importance de la trace) se situe cette trace dans le message même de la trace)
- on ne contrôle pas où atterrissent les messages : pour un programme Java standard cela va dans la sortie du terminal (il faut donc avoir lancé le programme par le terminal), pour une application tournant dans un serveur (tomcat par exemple) cela va dans un fichier de traces temporaire, purgé périodiquement ce qui interdit toute analyse trop ancienne

La bonne méthode est en fait d'utiliser une librairie dédiée à la trace. La plus populaire ces temps-ci en Java est log4j.
Je vais juste vous indiquer les points-clés de son utilisation (se référer à la documentation en ligne pour plus de détails) :
- il faut ajouter un jar à notre application (un jar est un zip qui regroupe des classes Java), ce jar contenant les classes de la librairie

- log4j fonctionne avec des niveaux de traces (du plus important au plus bénin) : ERROR, WARNING, INFO, DEBUG pour ne citer que les plus utilisés. On pourra ne tracer que depuis le niveau le plus important jusqu'au niveau voulu (ce qui permet facilement de n'afficher que les informations essentielles niveau ERROR pour une application en production, mais d'afficher tous les messages de ERROR à DEBUG pendant le développement avec le même code)

- on aura un fichier de configuration unique de la trace pour toute notre application dans lequel on indiquera où on veut envoyer les messages de trace, le niveau de trace, les informations à insérer automatiquement dans les messages

- on aura une classe dont le seul but sera d'initialiser la trace pour toute l'application à son lancement


1 - Installation de la librairie
On télécharge log4j, on ouvre notre archive et on récupère le jar qui se trouve au premier niveau (log4j-1.2.15.jar pour la version actuelle) et on le copie dans le répertoire WebContent/WEB-INF/lib de notre application (c'est l'endroit dans notre application où tomcat ira chercher les librairies externes).

Ensuite on va dire à Eclipse que notre projet va utiliser cette librairie : comme on a collé notre librairie dans le répertoire par défaut des librairies pour les applications Web standard, il suffit de faire un clic-droit->Refresh sur le répertoire lib pour que Eclipse se rende compte qu'il comporte ce jar.
Si on ouvre dans notre projet l'élément Java Resources : src -> Libraries -> Web App Libraries on y découvre notre jar. On peut même le parcourir pour voir les classes compilées qu'il comporte.


2 - Fichier de configuration de la trace
log4j peut être configuré grâce à un fichier plat (.properties) ou structuré (.xml). On va utiliser un fichier plat.
On va créer un répertoire config dans WEB-INF, puis créer un fichier log4j.properties dedans.
Le contenu de ce fichier sera :

CODE

# Set root category priority to INFO and appender to CONSOLE and LOGFILE.
log4j.rootCategory=INFO, CONSOLE, LOGFILE

# CONSOLE is set to be a ConsoleAppender using a PatternLayout.
log4j.appender.CONSOLE=org.apache.log4j.ConsoleAppender
log4j.appender.CONSOLE.Threshold=DEBUG
log4j.appender.CONSOLE.layout=org.apache.log4j.PatternLayout
log4j.appender.CONSOLE.layout.ConversionPattern=%d{HH:mm:ss} [%-5p] %C %M [%L]: %m%n

# LOGFILE is set to be a File appender using a PatternLayout.
log4j.appender.LOGFILE=org.apache.log4j.FileAppender
log4j.appender.LOGFILE.File=/Applications/Eclipse/logs/vg_actus.log
log4j.appender.LOGFILE.Append=true
log4j.appender.LOGFILE.Threshold=DEBUG
log4j.appender.LOGFILE.layout=org.apache.log4j.PatternLayout
log4j.appender.LOGFILE.layout.ConversionPattern=%d{HH:mm:ss} [%-5p] %C %M [%L]: %m%n


log4j.logger.fr.iclan=DEBUG

Explications :
- les lignes commençant par # sont des commentaires

- la première ligne indique que le niveau standard de déclenchement de la trace pour l'application sera INFO et que les sorties seront au nombre de deux : CONSOLE et LOGFILE (qui sont configurées juste ensuite)

- le premier bloc de code permet de configurer la sortie CONSOLE : elle écrira dans la console (comme System.out.println), elle acceptera les messages à partir du niveau DEBUG (donc tout ce qu'on lui soumet), et on lui indique le format de chaque ligne de trace (avec en particulier la date+heure et le nom de la classe et de la méthode qui a déclenché la trace)

- le second bloc de code permet de configurer la sortie LOGFILE : ce sera une écriture dans un fichier, on précise où se situera ce fichier, elle acceptera les messages à partir du niveau DEBUG (donc tout ce qu'on lui soumet), et on lui indique le format de chaque ligne de trace (avec en particulier la date+heure et le nom de la classe et de la méthode qui a déclenché la trace)

- enfin la dernière ligne permet de préciser que pour les classes du package fr.iclan (et tous ses sous-packages) on souhaiter un déclenchement au niveau DEBUG (on surpasse ainsi pour notre code le niveau global de trace de l'application)

En pratique pour écrire un tel fichier de configuration, on récupère un exemple sur le site d'Apache, puis une fois qu'on l'a adapté à nos besoins on garde plus ou moins le même pour toutes les applications (seul le chemin du fichier log et les différents niveaux de déclenchement peuvent être à adapter).


3 - Paramétrage du fichier de configuration
Pour pouvoir utilsier plusieurs fichiers de configuration dans notre application, on va rendre l'endroit où le chercher paramétrable.
On ouvre le fichier web.xml de notre application et on ajoute les lignes suivantes après la balise </display-name> (car l'ordre des éléments est important dans le fichier web.xml

CODE

<!-- Configuration du log -->
<context-param>
<param-name>log4jProp</param-name>
<param-value>/WEB-INF/config/log4j.properties</param-value>
</context-param>

4 - Prise en compte de notre fichier de configuration
Pour utiliser notre fichier, il faut configurer au lancement de l'application log4j sur celui-ci.
Pour être sûr de réaliser cela au démarrage de l'application, on va mettre ce code dans une servlet qui sera lancée avant les autres servlets de l'application, au déploiement de l'application.

Dans le fichier web.xml on déclare notre servlet :

CODE

<servlet>
<description>Servlet de l'initialisation de lgo4j</description>
<servlet-name>initServlet</servlet-name>
<servlet-class>fr.iclan.util.servlet.InitServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>

Le paramètre load-on-startup indique à tomcat que cette servlet doit être chargée au lancement de l'application, et avant les autres.
Notre servlet n'a pas vocation à être appelée un utilisateur, il n'y a donc pas besoin d'indiquer l'URL de son appel.

Au final notre web.xml ressemble maintenant à ça :

CODE

<?xml version="1.0" encoding="UTF-8"?>
<web-app id="WebApp_ID" version="2.4"
xmlns="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">
<display-name>vg_actus</display-name>

<!-- Configuration du log -->
<context-param>
<param-name>log4jProp</param-name>
<param-value>/WEB-INF/config/log4j.properties</param-value>
</context-param>

<!-- Les servlets -->
<servlet>
<description>Servlet de l'initialisation de lgo4j</description>
<servlet-name>initServlet</servlet-name>
<servlet-class>fr.iclan.util.servlet.InitServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>

<!-- Page d'accueil -->
<welcome-file-list>
<welcome-file>index.jsp</welcome-file>
</welcome-file-list>
</web-app>

Il ne reste plus qu'à écrire réellement la classe indiquée (fr.iclan.util.servlet.InitServlet) :
sur le répertoire Java Resources : src, on fait clic-droit -> New -> Class.
On indique le pacage fr.iclan.util.servlet.
On indique le nom de l'application InitServlet.

Le contenu de notre classe sera :

CODE

package fr.iclan.util.servlet;

import java.io.File;

import javax.servlet.ServletConfig;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;

import org.apache.log4j.Logger;
import org.apache.log4j.PropertyConfigurator;
/**
* $Id$
*/
public class InitServlet extends HttpServlet {

private static final long serialVersionUID = -2798432253295204073L;

private static Logger log = Logger.getLogger(InitServlet.class);

public static String PARAM_LOG4JPROP = "log4jProp";

public void init(ServletConfig config) throws ServletException {
String log4jProp = null;
try {
log4jProp = config.getServletContext().getInitParameter(PARAM_LOG4JPROP);
File file = new File(log4jProp);
if (!file.exists()) {
log4jProp = config.getServletContext().getRealPath("/")+log4jProp;
}

PropertyConfigurator.configure(log4jProp);

log.debug("log4j ready !");
} catch (Exception e) {
throw new IllegalArgumentException("Configuration log4j ! "+log4jProp+" / "+e.getMessage());
}
}
}

Explications :
- package indique le package de cette classe

- les imports donnent les liens vers les classes utilisées dans celle-ci

- notre classe étend HttpServlet

- serialVersionUID (généré ici automatiquement par tomcat) permet juste de savoir quand la classe a été modifiée (pour les classes Serializable) puisqu'on est censé le modifier quand on modifie la classe (comme un CRC). Il n'est pas obligatoire et le concept de Serializable n'est pas important ici.

- log vous indique comment on récupère une poignée sur un traceur log4j (par classe)

- la méthode init(...) sera celle qui sera appelée par tomcat pour charger notre servlet, elle effectue le travail suivant :
--- récupération de la valeur du paramètre "log4jProp" qu'on a indiqué dans le fichier web.xml
--- détermination si le fichier existe directement (chemin absolu) ou non
--- s'il n'existe pas, on suppose qu'il est en relatif par rapport à la racine de l'application et on le complète avec cette racine pour avoir un chemin absolu (c'est important puisque le chemin absolu du fichier change par exemple suivant l'endroit où se trouve le serveur et on ne veut pas avoir à adapter à chaque fois le chemin. On garde néanmoins la possibilité d'avoir un chemin absolu car en pratique en production on aime bien regrouper tous les fichiers de configuration ensemble, hors des applications concernées)
--- configuration de log4j par appel à PropertyConfigurator.configure(log4jProp)

- log.debug(message) permet de générer un message de niveau DEBUG



On lance/relance notre serveur.
Dans la console du serveur dans Eclipse la ligne suivante apparaît pendant le chargement du serveur :

CODE

12:06:20 [DEBUG] fr.iclan.util.servlet.InitServlet init [33]: log4j ready !

De même dans le répertoire /Applications/Eclipse/logs/ on trouve un fichier vg_actus.log qui contient :

CODE

12:06:20 [DEBUG] fr.iclan.util.servlet.InitServlet init [33]: log4j ready !

On remarque ici les informations qu'on voulait absolument :
- l'heure de la trace (pour bien se repérer temporellement parmi des traces identiques)
- le niveau de la trace
- la classe à l'origine de la trace
- sa méthode
- la ligne dans le fichier de la classe
- le message de la trace


Notre trace est fonctionnelle.

Projet Eclipse à la fin de cette étape : vg_actus-log.zip


Prochaine étape : mettre en place dans notre application l'authentification basique inclue dans tomcat pour protéger les accès à nos pages d'administration.

Ce message a été modifié par atarxerxes - 19 Oct 2008, 11:30.

Powaa, ça se complique et j'ai pas trop le temps en ce moment, je vais être bon pour la session de septembre.

Sommaire évolutif et approximatif :

1. les installations
2. spécifications de l'application
3. création de la base et des tables
4. création du projet Eclipse
5. mise en place du log
6. mise en place de l'authentification Tomcat
7. connexion Java-MySQL
8. récupérations d'informations dans la base
9. génération du flux XML des actualités
10. transformation et affichage du flux XML
11. construction du modèle des pages HTML
12. écriture des requêtes de modification/ajout/suppression
13. écriture des pages de modification/ajout/suppression
14. prototype + scriptaculous : le javascript fiable, facile et spectaculaire
15. saisie facile des dates
16. validation des données saisies
17. écriture de la servlet publique
18. génération du flux Atom

Mise en place de l'authentificaiton Tomcat

Une bonne part du travail dans une application est constituée par la mise en place de la gestion des droits.
En effet en général c'est une partie de l'application extrêmement dépendante du type d'application et du contexte d'utilisation de celle-ci.
La gestion des droits peut se traduire suivant les cas par (du plus basique au plus élaboré) :
- la gestion de l'accès à l'application
- la gestion de l'accès à certaines fonctionnalités de l'application
- la gestion de l'accès à certaines fonctionnalités de l'application en fonction des propriétés des objets sur lesquels s'appliquent celles-ci

Pour notre application, notre besoin est basique : on veut seulement une gestion de l'accès aux pages d'administration de notre application. On va donc pouvoir utiliser l'authentification intégrée dans tomcat.

Ce que sait faire tomcat : restreindre l'accès à certaines URLs (ou à une masque, un pattern d'URLs).
Pour cela, on va regrouper nos pages d'administration dans un même répertoire admin.

1 - Création du répertoire des pages d'administration
Dans Eclipse, dans notre répertoire WebContent, on crée un répertoire "admin".
Dans ce répertoire, on crée une page liste.jsp (qui contiendra plus tard notre liste d'actualités). Pour l'instant son contenu se limitera à cela :

CODE

<%@ page language="java" contentType="text/html; charset=UTF-8"
pageEncoding="UTF-8"%>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>Liste des actualités</title>
</head>
<body>
Liste des actualités
</body>
</html>

Si on va à l'adresse http://localhost:8080/vg_actus/admin/liste.jsp on vérifie bien que notre page existe désormais sur notre serveur et est accessible sans restriction.


2 - Création du droit applicatif
Vous vous souvenez du fichier tomcat-users.xml (situé dans le répertoire conf de tomcat)? C'est dans ce fichier qu'on va ajouter notre droit applicatif propre et configurer notre utilisateur pour y avoir accès.
On modifie donc notre fichier pour qu'il ressemble à ça :

CODE

<?xml version='1.0' encoding='utf-8'?>
<tomcat-users>
<role rolename="vgactusadmin"/>
<role rolename="tomcat"/>
<role rolename="role1"/>
<role rolename="manager"/>
<user username="joan" password="XXXXXXXX" roles="tomcat,manager,vgactusadmin"/>
</tomcat-users>

(vous pouvez bien sûr mettre votre propre utilisateur et mot de passe ).
On a donc ajouté un droit "vgactusadmin" et on a donné ce droit à un de nos utilisateurs.


3 - Restriction des pages applicatives
On va maintenant dire à tomcat de vérifier quand un utilisateur essaie d'accéder à nos pages d'administration qu'il a le droit "vgactusadmin".
On ouvre le fichier web.xml dans Eclipse et on rajoute les lignes :

CODE

<!-- Sécurité -->
<security-constraint>
<display-name>Test d'authentification tomcat</display-name>

<!-- Liste des pages protégées -->
<web-resource-collection>
<web-resource-name>Page sécurisée</web-resource-name>
<url-pattern>/admin/*</url-pattern>
</web-resource-collection>
<!-- Rôles des utilisateurs ayant le droit d'y accéder -->
<auth-constraint>
<role-name>vgactusadmin</role-name>
</auth-constraint>
</security-constraint>
<login-config>
<!-- Type d'authentification -->
<auth-method>BASIC</auth-method>
<realm-name>Espace Membres</realm-name>
</login-config>
<!-- Rôles utilisés dans l'application -->
<security-role>
<description>Administrateur</description>
<role-name>vgactusadmin</role-name>
</security-role>

Explications :
- on ajoute une contrainte de sécurité sur toute URL de la forme "/admin/..." dans notre application

- seuls les utilisateurs ayant le droit "vgactusadmin" pourront y accéder

- la méthode de login sera basique (pas de page de formulaire dédiée, mot de passe qui transite en clair)

- notre application utilisera seulement le rôle "vgactusadmin" parmi les rôles définis dans tomcat-users.xml

Notre web.xml ressemble donc désormais à :

CODE

<?xml version="1.0" encoding="UTF-8"?>
<web-app id="WebApp_ID" version="2.4"
xmlns="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">
<display-name>vg_actus</display-name>

<!-- Configuration du log -->
<context-param>
<param-name>log4jProp</param-name>
<param-value>/WEB-INF/config/log4j.properties</param-value>
</context-param>

<!-- Les servlets -->
<servlet>
<description>Servlet de l'initialisation de lgo4j</description>
<servlet-name>initServlet</servlet-name>
<servlet-class>fr.iclan.util.servlet.InitServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>


<!-- Sécurité -->
<security-constraint>
<display-name>Test d'authentification tomcat</display-name>

<!-- Liste des pages protégées -->
<web-resource-collection>
<web-resource-name>Page sécurisée</web-resource-name>
<url-pattern>/admin/*</url-pattern>
</web-resource-collection>
<!-- Rôles des utilisateurs ayant le droit d'y accéder -->
<auth-constraint>
<role-name>vgactusadmin</role-name>
</auth-constraint>
</security-constraint>
<login-config>
<!-- Type d'authentification -->
<auth-method>BASIC</auth-method>
<realm-name>Espace Membres</realm-name>
</login-config>
<!-- Rôles utilisés dans l'application -->
<security-role>
<description>Administrateur</description>
<role-name>vgactusadmin</role-name>
</security-role>

<!-- Page d'accueil -->
<welcome-file-list>
<welcome-file>index.jsp</welcome-file>
</welcome-file-list>
</web-app>

Vu que par défaut tomcat utilise le fichier tomcat-users.xml comme source de données des droits et utilisateurs, aucune autre manipulation n'est nécessaire (on aurait pu par exemple utiliser une base de données ou un autre fichier pour fournir les utilisateurs et les droits...).

On redémarre notre serveur pour prendre en compte les modifications du fichier tomcat-users.xml.
Si on revient sur notre page http://localhost:8080/vg_actus/admin/liste.jsp, on voit apparaître :


On vérifie bien qu'il n'y a qu'en tapant le nom et le mot de passe de notre utilisateur qu'on arrive bien à se connecter à notre page.
La session d'authentification dure tant que notre navigateur est lancé, il faut le quitter pour qu'au prochain lancement il redemande le mot de passe pour accéder à la page.


Projet en fin de leçon : vg_actus-auth.zip



Prochaine leçon : mise en place de la connexion Java-MySQL

Prochaine leçon : mise en place de la connexion Java-MySQL

Oh grand gourou du SQL Nous attendons avec impatience tes sages enseignements

Je suis en vacances

Cool, ça veut dire que tu auras tout ton temps pour nous faire ça

Comment ça tu ne voyais pas ça comme ça ???

et maintenant, on fait quoi ?

On est pas vendredi !

Sympa ce topic, sachant que je suis en plein apprentissage de ce langage.
Sinon moi j'utilise BlueJ ( obligation de mon prof ) mais existe il une version de Eclipse pour mac en français ?

ça intéresse toujours du monde ?
si atarxerxes n'a plus le temps, je peux essayer de proposer la suite avec son accord.

edit : sympa BlueJ, je ne connaissais pas.
C'est pas mal de passer par ça Louis, tu apprendras plus facilement les concepts qui te seront utiles pour tout autre langage.
Pour Eclipse Mac, aucune idée de la localisation en français, je ne connais personne qui utilise autre chose que la version anglaise.
C'est un vrai problème pour toi ?
Au pire, vois avec le site http://babel.eclipse.org/babel/

Ce message a été modifié par titimoby - 17 Apr 2012, 10:47.

Pas de problème pour que tu prennes la suite

J'espère avoir à la fois le temps nécessaire et ton talent explicatif
Je suis en train de faire les étapes comme n'importe qui d'autre pour être sûr d'avoir saisi ta démarche.

Je signale au passage que l'installation de MySql Tools devrait maintenant être remplacée par Mysql Workbench :
http://dev.mysql.com/downloads/workbench/

Les Mysql Tools sont en fin de vie mais peuvent encore convenir.

Pour le permier lancement d'Eclipse (pfff Ganymède ) il y a une petite typo:
On peut ne profiter pour rajouter notre serveur Tomcat dans l'onglet Serveur
au lieu de
On peut en profiter pour rajouter notre serveur Tomcat dans l'onglet Serveur

la table VG_SUPPORT a un souci.
La colonne supp_label est créée en INT mais utilisée comme une chaine.
Je l'ai remplacée par un CHAR(11)

Pour le logger, le fichier log4j.properties est erronné.
il faut écrire
log4j.logger.fr.iclan=DEBUG, LOGFILE

pour que le logger LOGFILE créé soit utilisé.

Ce message a été modifié par titimoby - 1 May 2012, 21:54.

Anecdote qui m'enquiquine :

jusqu'à mon changement de mac, j'utilisait un clavier DiNovo dont je réglai les touches de fonctions sur "utilisation standard" ce qui me permettait l'utilisation de F5 ou F6 pour débug.
le même réglage sur mon clavier apple bluetooth continue de m'afficher Mission Control par exemple...

Une idée ?

Tu dois appuyer en bas à gauche sur la touche "fn" ce qui te permet d'utiliser réellement les touches F1, F2, F3....

Sinon dans Préférence système, tu as moyen de changer les réglages des touches "fonctions" pour qu'elles soient directement actives et non pas les applications liées.

J'ai renoncé, j'ai enlevé mes réglages de raccourcis que j'avais mis et récupéré mes F5 et F6.

Je connais l'utilisation de Fn+touche fonction puisque ça marche avec F8 mais j'ai cru à une feature trop évoluée, on dira que c'est de ma faute, pas de souci.

allez, je continue de faire chaque étape, voire ce qui peut être erronné dans le tuto.
D'ailleurs je suis étonné de ne pas avoir vu qui que ce soit rencontrer les petits soucis que j'ai eu et en parler ici à l'époque.

Le tuto branche encore du monde ?
Parce que c'est intéressant de refaire une webapp un peu à l'ancienne, ça permet de comprendre des mécanismes importants.
Après, tout ça est très souvent masqués dans des frameworks mais ça reste à connaitre.

Accessoirement, je n'avais pas mis en place de sécurité de ce type depuis des lustres... et je n'y parvient plus
J'ai l'authentification qui est active, le user/pass est demandé mais visiblement pas ceux que j'ai définis puisque ça tourne en boucle

Ce message a été modifié par titimoby - 2 May 2012, 11:25.