LSI2 Programmation Web TP n 5 du 7 janvier 2008

Transcription

1 Page 1 sur 7 LSI2 Programmation Web TP n 5 du 7 janvier 2008 Corrigé des TPs précédents Un premier ensemble de code source est fourni dans un fichier.zip téléchargeable à l adresse Un deuxième ensemble de code source est fourni dans le fichier.zip téléchargeable à l adresse Sessions Le code source est fourni dans le ZIP n 2. Il reste à corriger un bug et à compléter le code Javascript de contrôle de saisie.

2 Page 2 sur 7 Première page JSP Premier servlet Questions du TP n 4 du 17 décembre 2007 sur JSP et servlets Compilation, déploiement, descripteur de déploiement Mapping entre les servlets/jsp et les URLs Package / mapping par défaut Comment faites-vous pour y accéder via une URL sans modifier le fichier web.xml? Il faut activer l appel par défaut via la servlet invoker en décommentant les lignes correspondant à la servlet invoker dans le fichier web.xml par défaut situé dans le répertoire conf de votre installation Tomcat. Mapping multiple Il faut empiler les mappings et utiliser, si besoin, des expressions régulières Accès à la base de données Avant d aller plus loin, on teste la possibilité d accéder à un paramètre statique enregistré dans le fichier de configuration de la WebApp : voir la servlet staticparam Récupérer le driver JDBC pour mysql (dans la bonne version de mysql). => à télécharger sur le web Installer ce driver de manière à pouvoir l utiliser comme ressource depuis vos pages JSP et vos servlets. Plusieurs options possibles : dans le shared/lib du serveur ou dans le lib de la webapp => à vous de voir. Accès sans datasource par servlet Créer un datasource dans le fichier de configuration server.xml et dans le fichier web.xml et modifier le code source de la servlet puis du JSP pour accéder à la base MSR via cette data source. Voir les fichiers joints dans le ZIP

3 Page 3 sur 7 Remarque 1 A database connection pool creates and manages a pool of connections to a database. Recycling and reusing already existing connections to a db is more efficient than opening a new connection. There is one problem with connection pooling. A web application has to explicetely close ResultSet's, Statement's, and Connection's. Failure of a web application to close these resources can result in them never being available again for reuse, a db connection pool "leak". This can eventually result in your web application db connections failing if there are no more available connections. There is a solution to this problem. The Jakarta-Commons DBCP can be configured to track and recover these abandoned db connections. Not only can it recover them, but also generate a stack trace for the code which opened these resources and never closed them. Remarque 2 The Context element represents a web application, which is run within a particular virtual host. Each web application is based on a Web Application Archive (WAR) file, or a corresponding directory containing the corresponding unpacked contents, as described in the Servlet Specification (version 2.2 or later). For more information about web application archives, you can download the Servlet Specification, and review the Tomcat Application Developer's Guide. The web application used to process each HTTP request is selected by Catalina based on matching the longest possible prefix of the Request URI against the context path of each defined Context. Once selected, that Context will select an appropriate servlet to process the incoming request, according to the servlet mappings defined in the web application deployment descriptor file (which MUST be located at /WEB-INF/web.xml within the web app's directory hierarchy). You may define as many Context elements as you wish. Each such Context MUST have a unique context path. In addition, a Context must be present with a context path equal to a zero-length string. This Context becomes the default web application for this virtual host, and is used to process all requests that do not match any other Context's context path. For Tomcat 5, unlike Tomcat 4.x, it is NOT recommended to place <Context> elements directly in the server.xml file. This is because it makes modifing the Context configuration more invasive since the main conf/server.xml file cannot be reloaded without restarting Tomcat. Context elements may be explicitly defined: * in the $CATALINA_HOME/conf/context.xml file: the Context element information will be loaded by all webapps * in the $CATALINA_HOME/conf/[enginename]/[hostname]/context.xml.default file: the Context element information will be loaded by all webapps of that host * in individual files (with a ".xml" extension) in the $CATALINA_HOME/conf/[enginename]/[hostname]/ directory. The name of the file (less the

4 Page 4 sur 7.xml) extension will be used as the context path. Multi-level context paths may be defined using #, e.g. context#path.xml. The default web application may be defined by using a file called ROOT.xml. * if the previous file was not found for this application, in an individual file at /META- INF/context.xml inside the application files * inside a Host element in the main conf/server.xml In addition to explicitly specified Context elements, there are several techniques by which Context elements can be created automatically for you. See Automatic Application Deployment and User Web Applications for more information. The description below uses the variable name $CATALINA_HOME to refer to the directory into which you have installed Tomcat 5, and is the base directory against which most relative paths are resolved. However, if you have configured Tomcat 5 for multiple instances by setting a CATALINA_BASE directory, you should use $CATALINA_BASE instead of $CATALINA_HOME for each of these references. Remarque 3 Pour que cela fonctionne, il est nécessaire de déposer une copie du driver Mysql dans le common/lib du serveur. Créer une servlet qui affiche la liste des régions de la base MSR Voir Voir les fichiers joints dans le ZIP Créer une page JSP qui affiche la liste des régions de la base MSR Voir les fichiers joints dans le ZIP Traitement des formulaires Créer un formulaire html permettant de saisir un numéro de département que vous inclurez dans le fichier.war Voir fichiers joints dans ZIP Créer une servlet récupérant la valeur saisie dans ce formulaire, testant sa validité et affichant la liste des établissements présents dans le département considéré. Voir fichiers joints dans ZIP Authentification des utilisateurs Restreindre l accès au formulaire et à la servlet de la question précédent en : - Ajoutant un fichier de login/mot de passe (.xml) - Modifiant les fichiers de configuration server.xml et web.xml pour interdire l accès à ces ressources aux identifiants ne se trouvant pas dans ce fichier. La solution se trouve sur et sur L implémentation réalisée dans le corrigé utilise une table créée dans la base msr pour accéder à la table des utilisateurs et des mots de passe.

5 Page 5 sur 7 L authentification est réalisée via JDBC (je n ai pas réussi à m authentifier par la datasource déclarée dans le fichier context.xml => avis aux amateurs) Trois utilisateurs ont été créés : Login : toto / pwd : titi Login : momo / pwd : mimi Login : koko / pwd : kiki Les rôles des trois utilisateurs sont : toto/admin mimi/user kiki/guess Le script sql de création des tables, livré dans le ZIP, est le suivant : create table users ( user_name varchar(15) not null primary key, user_pass varchar(15) not null ); create table user_roles ( user_name varchar(15) not null, role_name varchar(15) not null, primary key (user_name, role_name) ); insert into users(user_name, user_pass) values('toto', 'titi'); insert into users(user_name, user_pass) values('momo', 'mimi'); insert into users(user_name, user_pass) values('koko', 'kiki'); insert into user_roles(user_name, role_name) values('toto', 'admin'); insert into user_roles(user_name, role_name) values('momo', 'user'); insert into user_roles(user_name, role_name) values('koko', 'guess'); Le realm est déclaré dans le fichier context.xml de l application. On ajoute ensuite la contrainte de sécurité dans le fichier web.xml de l application. Deux solutions d authentification sont proposées, la première basic a été testée mais est mise en commentaire. La seconde utilise un formulaire et reprend directement la configuration proposée dans les exemples de pages JSP livrés avec Tomcat, comme proposé dans la documentation. Script Ant Ant est un outil permettant l automatisation des builds et du déploiement d une application (web ou autre). Ant s appuie sur XML pour décrire les opérations à réaliser et sur Java, pour réaliser les opérations. Un exemple de script, permettant de déployer automatiquement l application développée dans le cadre du TP vous est donné dans le fichier.zip du corrigé du TP. Ant comporte : Un ou des fichiers XML définissant les opérations à réaliser pour construire l application (ici, il s agit du fichier apprentiweb.xml) Un fichier.properties précisant les paramètres utilisés pour la construction de l application. Les paramètres définis dans le fichier.properties sont accessibles depuis le fichier.xml de construction.

6 Page 6 sur 7 Une application (ant) et des classes java (fichiers.jar attachés) qui s exécutent. L application principale, ant, lançant divers outils (parsing du document xml, etc) qui sont généralement des classes java contenues dans des fichiers.jar Sujets complémentaires (vus dans le cadre du projet) Googlewebtoolkit Ajax et les webservices Autres sujets intéressants (à approfondir par ceux qui le souhaitent) Le filtering dans tomcat La gestion des exceptions Les custom tag lib JSTL La validation des formulaires et la liaison formulaires / beans Les logs Les beans Le MVC pour le web Conclusion La programmation Web constitue un sujet vaste. Les technologies possibles sont nombreuses. Plusieurs pages seraient nécessaires pour simplement les citer toutes. Nous espérons que les quelques exercices traités en projet ainsi que le mini-projet de fin de module vous permettront d en appréhender la diversité, la richesse et les particularités : On travaille toujours dans un environnement hétérogène nécessitant la maîtrise de plusieurs technologies (côté client comme côté serveur). C est ce qui fait la richesse de la matière mais aussi sa difficulté. Pour répondre à un besoin, plusieurs solutions sont possibles. Vous trouverez toujours, quel que soit le projet, le développeur fou de la technologie ZZ que vous ne connaissez absolument pas. Parmi ces solutions, certaines sont sans doute meilleures que d autre mais il n y a pas, non plus, une solution unique qui surpasse toutes les autres. Toutes les solutions pérennes reposent cependant sur des schémas communs (structuration du code, etc). Le choix de telle ou telle technologie, d un schéma d architecture, va dépendre des compétences de l équipe, de ses habitudes, de la charge de travail prévu pour développer, des objectifs en termes de pérennité, maintenabilité, etc Le code garde une grande importance mais sa position évolue dans un domaine où l on utilise de plus en plus des bibliothèques ou des frameworks existants. Des problématiques nouvelles occupent une place aussi importante, voire plus, que le code : a. Intégration : la définition et la mise en place des environnements prend beaucoup de temps et revêt une grande importance b. Déploiement : le code est de plus en plus distribué. Il est accompagné d éléments externes, frameworks, librairies, dont la mise en place constitue une charge importante des projets c. Portabilité entre les environnements : la capacité à déployer une même application sur divers environnements devient également une problématique forte qu il convient d adresse dès le début des développements

7 Page 7 sur 7 d. Maintenabilité : la maintenance des applications constitue un poste de coût important. Il convient donc de prévoir une architecture simple à maintenir (évolution fonctionnelle, montée de version de frameworks, etc) e. Exploitabilité : les applications sont fréquemment hébergées. Il convient donc de prévoir les outils pour faciliter leur exploitation par des tiers (backup/recovery, gestion des logs, alertes, arrêt/démarrage, etc) f. Outillage : le concepteur, le développpeur, l intégrateur, le testeur travaillent de plus en plus avec des outils (IDE, SDK, Outil de gestion de version, etc). La mise en place d un environnement de développement performant constitue une tâche préalable incontournable au succès d un projet. g. Documentation : elle intervient à deux niveaux. 1/ Documentation pour aider le développeur dans son travail : compte tenu de la piètre qualité des forums et autres sites web qui nous innondent d information souvent incomplète voire fausses, il est de plus en plus recommandé de se référer à la documentation de REFERENCE des outils que l on utilise (sites OFFICIELS des différents fournisseurs, SUN, APACHE, etc). 2/ Documentation des développements : c est important d en produire un minimum, commentaires dans le code, notes de conception, etc, en pensant, si possible, aux éventuels futurs mainteneurs de vos développements