Pourquoi les "filter"s ??

Introduction

Ce tutoriel discute l'utilité des filtres dans le développement en J2EE, mais aussi parle de l'implémentation (sous eclipse) mais aussi ferait démonstration avec des code facile à comprendre et à employer

Que peut-on faire avec un "Filter" ?

Les « filters » peuvent être utilisés pour :

  • Intercepter les requêtes et leur « Headers » ceci avant qu'elles n'arrivent à destination ...
  • Les transformations par exemple du XML en HTML avec XSLT Filter ...
  • Faire un traitement selon la nature de la requêtes ou bien le client ou bien un autre paramètre ...

Donc grosso-modo les filtres sont utiliser pour les cas suivants :

  • Inspecter l'entête de la requête et les données avant qu'ils n'arrivent à l'application pour le traitement final.
  • Inspecter l'entête de la réponse et les données avant qu'ils ne soient envoyées vers le client.
  • Donner une ressource modifier pour l'application selon les cas de traitement.
  • Modifier la réponse avant de l'envoyer.
  • Arrêter une requête d'arriver à un composant.

Ceci montre la puissance des filtres dans une application WEB ou bien une application J2EE en général.

Implémentation de l'interface "javax.servlet.Filter" !

Un « Filter » est simplement une classe qui implémente l'interface « javax.servlet.Filter », celle-ci contient 3 méthodes pour le cycle de vie d'un filtre :

public void init(FilterConfig config) throws ServletException

Le « FilterConfig » qui est initié par le conteneur WEB, est utilisé pour l'initialisation du filtre et donne accés au « ServletContext » associé.

public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain) throws IOException, ServletException

Ici c'est la logique du filtre.

public void destroy()

Lorsque le filtre n'est plus utilisable, le Conteneur appelle cette méthode pour le détruire et l'enlever de la mémoire.

Configuration et Déploiment :S !!

Comme les servlets, les filtres aussi se doivent d'être déclarés dans le fichier « web.xml ». Bon, les IDEs font tout le travail pour nous mais faudrait juste savoir qu'ils sont définis et mappés comme les servlets ...

NB : un filtre peut être utilisé juste pour une partie de l'application (servlet, JSP, groupement de JSP ou de servlet, un package, un chemin dans l'application, des fichiers ...) ou bien pour la totalité de l'application ...

Cycle de vie d'un filtre

Tout filtre bascule entre 4 stages dans leur cycle de vie dans une conteneur WEB après leur instantiation :
1)- instantié,
2)- initié,
3)- exécuté et
4)- détruit.

La méthode init() comme on a déjà vu est utilisé entre la phase (1) et (2), la méthode doFilter() est pour la phase (3) et enfin, la méthode Destroy() est entre la phase (3) et (4).

Enchaînement des filtre : « Filter Chaining » !

L'enchaînement des filtres est le fait de passer les requêtes à travers plusieurs filtres avant d'accéder à l'information souhaitée, ceci pour plus de sécurité et de robustesse.

Tout ceci se fait à travers l'appel de la méthode public void doFilter(ServletRequest req, ServletResponse res) throws IOException, ServletException de l'interface « javax.servlet.FilterChain » : une fois le traitement d'un filtre est terminé, il appelle cette méthode pour passer les arguments de l'objet FilterChain à un autre filtre jusqu'à atteindre le dernier filtre.

Fin de la théorie, notre premier exemple :D !!

Un corps vide auto généré par Eclipse :

package ma.scupper.filters;

import java.io.IOException;
import javax.servlet.DispatcherType;
import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.annotation.WebFilter;
import javax.servlet.annotation.WebInitParam;

/**
* Servlet Filter implementation class HeaderFilter
*/
@WebFilter(

    dispatcherTypes = {
    DispatcherType.REQUEST,
    DispatcherType.FORWARD,
    DispatcherType.INCLUDE,
    DispatcherType.ERROR
    //Les Dispatcher sont choisi à priori par l'utilisateur selon ces besoins
    }
    ,
    urlPatterns = { "/HeaderFilter" },
    initParams = {
    @WebInitParam(name = "Nom", value = "scupper", description = "nom de l'utilisateur"),
    @WebInitParam(name = "Version", value = "1.0", description = "Version du filtre :p")
    //Ici on entre nos paramètre d'initialisation du filtre par le biais des annotations
    })

public class HeaderFilter implements Filter {
    /**
    * Default constructor.
    */
    public HeaderFilter() {
        // TODO Auto-generated constructor stub
    }

    /**
    * @see Filter#destroy()
    */
    public void destroy() {
        // TODO Auto-generated method stub
    }

    /**
    * @see Filter#doFilter(ServletRequest, ServletResponse, FilterChain)
    */
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
        // TODO Auto-generated method stub
        // place your code here
        //retourne au serveur "in SimpleFilter" aux Dbut du traitement
        filterConfig.getServletContext().log("in SimpleFilter");
        // pass the request along the filter chain
        chain.doFilter(request, response);
        //retourne au serveur "Gettin out ov SimpleFilter" à la fin du traitement....
        filterConfig.getServletContext().log("Getting out of SimpleFilter");
    }

    /**
    * @see Filter#init(FilterConfig)
    */
    public void init(FilterConfig fConfig) throws ServletException {
        // TODO Auto-generated method stub
    }
}

Ce document intitulé « Pourquoi les "filter"s ?? » issu de CodeS SourceS (codes-sources.commentcamarche.net) est mis à disposition sous les termes de la licence Creative Commons. Vous pouvez copier, modifier des copies de cette page, dans les conditions fixées par la licence, tant que cette note apparaît clairement.
Rejoignez-nous