Paramètres d'initialisation du contexte et du servlet

1. Vue d'ensemble

Les servlets sont des classes Java simples qui s'exécutent dans un conteneur de servlet.

Les servlets HTTP (un type spécifique de servlet) sont des citoyens de première classe dans les applications Web Java. L'API des servlets HTTP vise à traiter les requêtes HTTP à travers le cycle typique de requête-traitement-réponse, implémenté dans les protocoles client-serveur .

En outre, les servlets peuvent contrôler l'interaction entre un client (généralement un navigateur Web) et le serveur à l'aide de paires clé-valeur sous la forme de paramètres de demande / réponse.

Ces paramètres peuvent être initialisés et liés à une étendue d'application (paramètres de contexte) et à une étendue spécifique à la servlet (paramètres de servlet).

Dans ce didacticiel, nous allons apprendre à définir et à accéder aux paramètres d'initialisation de contexte et de servlet .

2. Initialisation des paramètres de servlet

Nous pouvons définir et initialiser les paramètres de servlet à l'aide d'annotations et du descripteur de déploiement standard - le fichier «web.xml» . Il convient de noter que ces deux options ne sont pas mutuellement exclusives.

Explorons chacune de ces options en profondeur.

2.1. Utilisation des annotations

L'initialisation des paramètres des servlets avec des annotations nous permet de conserver la configuration et le code source au même endroit .

Dans cette section, nous montrerons comment définir et accéder aux paramètres d'initialisation liés à un servlet spécifique à l'aide d'annotations.

Pour ce faire, nous allons implémenter une classe UserServlet naïve qui collecte les données utilisateur via un formulaire HTML simple.

Tout d'abord, regardons le fichier JSP qui rend notre formulaire:

   Context and Initialization Servlet Parameters    

Please fill the form below:

Name:Email:

Notez que nous avons codé l' attribut d' action du formulaire en utilisant EL (le langage d'expression). Cela lui permet de toujours pointer vers le chemin «/ userServlet» , quel que soit l'emplacement des fichiers d'application sur le serveur.

L' expression «$ {pageContext.request.contextPath}» définit une URL dynamique pour le formulaire, qui est toujours relative au chemin de contexte de l'application .

Voici notre implémentation initiale de servlet:

@WebServlet(name = "UserServlet", urlPatterns = {"/userServlet"}, initParams={ @WebInitParam(name="name", value="Not provided"), @WebInitParam(name="email", value="Not provided")})) public class UserServlet extends HttpServlet { // ... @Override protected void doPost( HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { processRequest(request, response); forwardRequest(request, response, "/WEB-INF/jsp/result.jsp"); } protected void processRequest( HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { request.setAttribute("name", getRequestParameter(request, "name")); request.setAttribute("email", getRequestParameter(request, "email")); } protected void forwardRequest( HttpServletRequest request, HttpServletResponse response, String path) throws ServletException, IOException { request.getRequestDispatcher(path).forward(request, response); } protected String getRequestParameter( HttpServletRequest request, String name) { String param = request.getParameter(name); return !param.isEmpty() ? param : getInitParameter(name); } } 

Dans ce cas, nous avons défini deux paramètres d'initialisation de servlet, le nom et l' adresse e - mail , en utilisant initParams et les annotations @WebInitParam .

Veuillez noter que nous avons utilisé la méthode getParameter () de HttpServletRequest pour récupérer les données du formulaire HTML et la méthode getInitParameter () pour accéder aux paramètres d'initialisation du servlet.

La méthode getRequestParameter () vérifie si le nom et les paramètres de demande d' e - mail sont des chaînes vides.

S'il s'agit de chaînes vides, les valeurs par défaut des paramètres d'initialisation correspondants leur sont attribuées.

La méthode doPost () récupère d'abord le nom et l'adresse e-mail que l'utilisateur a saisis dans le formulaire HTML (le cas échéant). Ensuite, il traite les paramètres de la requête et transmet la requête à un fichier «result.jsp» :

    User Data   

User Information

Name: ${name}

Email: ${email}

Si nous déployons notre exemple d'application Web sur un serveur d'applications, tel qu'Apache Tomcat, Oracle GlassFish ou JBoss WidlFly, et que nous l'exécutons, il doit d'abord afficher la page du formulaire HTML.

Une fois que l'utilisateur a rempli les champs de nom et d' e - mail et soumis le formulaire, il affichera les données:

User Information Name: the user's name Email: the user's email 

Si le formulaire est juste vide, il affichera les paramètres d'initialisation du servlet:

User Information Name: Not provided Email: Not provided 

Dans cet exemple, nous avons montré comment définir les paramètres d'initialisation servlet à l'aide d' annotations, et comment y accéder avec la g etInitParameter () méthode .

2.2. Utilisation du descripteur de déploiement standard

Cette approche diffère de celle qui utilise des annotations, car elle nous permet de garder la configuration et le code source isolés les uns des autres .

Pour montrer comment définir les paramètres de servlet d'initialisation avec le fichier «web.xml» , supprimons d' abord les annotations initParam et @WebInitParam de la classe UserServlet :

@WebServlet(name = "UserServlet", urlPatterns = {"/userServlet"}) public class UserServlet extends HttpServlet { ... } 

Ensuite, définissons les paramètres d'initialisation du servlet dans le fichier «web.xml» :

   UserServlet UserServlet  name Not provided   email Not provided    

Comme indiqué ci-dessus, la définition des paramètres d'initialisation du servlet à l'aide du fichier «web.xml» revient simplement à utiliser le , et Mots clés.

De plus, il est possible de définir autant de paramètres de servlet que nécessaire, tant que nous nous en tenons à la structure standard ci-dessus.

Lorsque nous redéployons l'application sur le serveur et que nous la réexécutons, elle doit se comporter de la même manière que la version qui utilise des annotations.

3. Initialisation des paramètres de contexte

Parfois, nous devons définir des données immuables qui doivent être partagées globalement et accessibles via une application Web.

En raison de la nature globale des données, nous devrions utiliser des paramètres d'initialisation de contexte à l'échelle de l'application pour stocker les données, plutôt que de recourir aux équivalents de servlet .

Even though it's not possible to define context initialization parameters using annotations, we can do this in the “web.xml” file.

Let's suppose that we want to provide some default global values for the country and province where our application is running.

We can accomplish this with a couple of context parameters.

Let's refactor the “web.xml” file accordingly:

  province Mendoza   country Argentina   

This time, we've used the , , and tags to define the province and country context parameters.

Of course, we need to refactor the UserServlet class so that it can fetch these parameters and pass them on to the result page.

Here are the servlet's relevant sections:

@WebServlet(name = "UserServlet", urlPatterns = {"/userServlet"}) public class UserServlet extends HttpServlet { // ... protected void processRequest( HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { request.setAttribute("name", getRequestParameter(request, "name")); request.setAttribute("email", getRequestParameter(request, "email")); request.setAttribute("province", getContextParameter("province")); request.setAttribute("country", getContextParameter("country")); } protected String getContextParameter(String name) {- return getServletContext().getInitParameter(name); } } 

Please notice the getContextParameter() method implementation, which first gets the servlet context through getServletContext(), and then fetches the context parameter with the getInitParameter() method.

Next, we need to refactor the “result.jsp” file so that it can display the context parameters along with the servlet-specific parameters:

Name: ${name}

Email: ${email}

Province: ${province}

Country: ${country}

Lastly, we can redeploy the application and execute it once again.

If the user fills the HTML form with a name and an email, then it will display this data along with the context parameters:

User Information Name: the user's name Email: the user's email Province: Mendoza Country: Argentina 

Otherwise, it would output the servlet and context initialization parameters:

User Information Name: Not provided Email: Not provided Province: Mendoza Country: Argentina 

While the example is contrived, it shows how to use context initialization parameters to store immutable global data.

As the data is bound to the application context, rather than to a particular servlet, we can access them from one or multiple servlets, using the getServletContext() and getInitParameter() methods.

4. Conclusion

In this article, we learned the key concepts of context and servlet initialization parameters and how to define them and access them using annotations and the “web.xml” file.

For quite some time, there has been a strong tendency in Java to get rid of XML configuration files and migrate to annotations whenever possible.

CDI, Spring, Hibernate, to name a few, are glaring examples of this.

Néanmoins, il n'y a rien de mal en soi à utiliser le fichier «web.xml» pour définir les paramètres d'initialisation de contexte et de servlet.

Même si l'API Servlet a évolué à un rythme assez rapide vers cette tendance, nous devons toujours utiliser le descripteur de déploiement pour définir les paramètres d'initialisation du contexte .

Comme d'habitude, tous les exemples de code présentés dans cet article sont disponibles à l'adresse over sur GitHub.