Cas d’utilisation pour @WebInitParam

Depuis la spécification de Servlet 3.0, il est possible de déclarer les métadonnées de mappage de servlet comme annotation sur la classe de servlet:

@WebServlet(name="appInfoServlet", urlPatterns ="/appInfo", initParams = @WebInitParam(name="ocwd.deployer.email", value="[email protected]")) public class AppInfoServlet extends HttpServlet { } 

Ce que je ne comprends pas, cependant, c’est le cas pour conserver les parameters init dans la même classe que le servlet. Si je comprends bien, ces parameters doivent être séparés de la classe et placés dans le descripteur de déploiement.

Quels sont les cas d’utilisation pour spécifier les parameters d’initialisation dans l’annotation @WebServlet ?

Les annotations sont utilisées pour donner les valeurs par défaut.

Dans JavaEE, les propriétés de déploiement peuvent également être fournies à l’aide d’annotations. Compte tenu des valeurs des annotations, le descripteur de déploiement, à savoir web.xml, peut toujours être utilisé pour remplacer les valeurs par défaut fournies par les annotations.


Dans l’exemple ci-dessus, init-param peut être remplacé en configurant un servlet avec un nom correspondant dans web.xml :

   appInfoServlet  ocwd.deployer.email [email protected]   

Je peux penser à un, du haut de ma tête: fournir la valeur par défaut (c’est-à-dire par le concepteur de la classe).

Si l’utilisateur de cette classe a bien la valeur par défaut, il n’a pas besoin d’append quoi que ce soit et l’utilise simplement. S’il ne l’est pas, il peut le modifier en utilisant le DD.

Je pense que le cas d’utilisation est similaire à d’autres cas d’utilisation pour d’autres annotations dans différents frameworks où nous avons utilisé du XML séparé avant les annotations.

Vous pouvez en dire autant des annotations JAXB. En réalité, vous pouvez implémenter une classe et utiliser plusieurs stratégies de son mappage vers XML. Mais une fois que vous passez aux annotations, vous créez un lien étroit entre la classe et les métadonnées. Il en va de même pour les annotations de spring. Etc.

En pratique, nous déployons rarement le même servlet deux fois en utilisant une configuration différente ou utilisons deux fois le même EJB ou mappons une classe avec différents schémas XML. Mais dans ce cas, il est très pratique de stocker des métadonnées avec du code. Ce problème est résolu en Java avec des annotations.

Bottom line: utilisez cette définition dans une application concrète où chaque servlet a certaines fonctionnalités et rôles et, par définition, n’est pas réutilisable et étroitement associé à son mappage et sa configuration d’URL. Ne l’utilisez pas si vous créez un environnement tel que Struts ou Spring controller. Dans ce cas, le programmeur d’application doit pouvoir configurer le servlet.