Différentes manières d'obtenir le contexte de servlet

Quelqu'un pourrait-il m'expliquer quelle est la différence entre cette façons de faire de l' ServletContext d'un HttpServlet?

doGet( HttpServletRequest request, ... ){
    getServletConfig( ).getServletContext( );
    request.getSession( ).getServletContext( );
    getServletContext( );
}

Est il une différence de performance ou dans le contexte lui-même? Si oui, quelle est la meilleure façon? Il n'existe aucun autre moyen de récupérer le contexte?

source d'informationauteur McSonk

  1. 21

    Il y a plus d'.

    request.getServletContext();

    Il n'y a techniquement aucune différence dans la performance du request.getSession() créera implicitement la session HTTP objet si pas encore créé. Donc, si ce n'est pas encore fait, puis de saisir le contexte de servlet via la session peut prendre quelques nanosecondes plus si la session n'est pas encore créé.

    Il n'y a également pas de différence dans le retour de contexte. Ces méthodes sont tout simplement pour des raisons de commodité et de la méthode pour obtenir le contexte dépend du contexte 😉 vous êtes actuellement assis dans.

    Si vous êtes assis dans une méthode appelée par la servlet () (comme doGet()doPost()etc), alors il suffit d'utiliser l'héritage getServletContext() méthode. D'autres moyens ne inutilement ajouter plus de caractères pour le code source.

    @Override
protected void doGet(HttpServletRequest request, HttpServletResponse response) {
    ServletContext context = getServletContext();
    //...
}

    Si vous êtes assis dans le servlet de init(ServletConfig) méthode, puis l'a hérité de getServletContext() n'est pas encore disponible tant que vous n'avez pas appelé super.init(config). Vous auriez besoin de saisir de ServletConfig.

    @Override
public void init(ServletConfig config) {
    ServletContext context = config.getServletContext();
    //...
}

    Mais beaucoup mieux est de remplacer init() à la place. Dans un décent servlet vous ne devez remplacer init(ServletConfig).

    @Override
public void init() {
    ServletContext context = getServletContext();
    //...
}

    Si vous n'êtes pas assis dans une servlet, mais, par exemple filtre ce qui manque le héritée getServletContext() méthode et vous n'avez ServletRequest à mains, alors vous pouvez prendre à partir de là.

    @Override
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) {
    ServletContext context = request.getServletContext();
    //...
}

    Noter que ce qui est nouveau depuis Servlet 3.0. Auparavant, vous auriez à le saisir à partir de la session.

    @Override
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) {
    ServletContext context = request.getSession().getServletContext();
    //...
}

    Toutefois, ce n'est pas agréable si vous vous inquiétez au sujet inutile de création de session. D'où l'introduction de ServletRequest#getServletContext() — bien que vous pouvez aussi tout simplement extraire à partir de FilterConfig (hey, il y a encore une autre façon!).

    private FilterConfig config;

@Override
public void init(FilterConfig config) {
    this.config = config;
}

@Override
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) {
    ServletContext context = config.getServletContext();
    //...
}

    Et puis il y a Session HTTP auditeurs où l'on pouvait écouter sur un.o. session détruire. Il n'y a pas d'autre moyen d'obtenir la servlet contexte que via HttpSession#getServletContext().

    @Override
public void sessionDestroyed(HttpSessionEvent event) {
    ServletContext context = event.getSession().getServletContext();
    //...
}

    Ici, vous n'avez pas besoin de vous inquiéter inutilement session de la création, parce que c'est à ce point ont déjà été créés pour longtemps à l'avance. Notez qu'il n'y a pas ServletRequest n'importe où, il n'y a pas nécessairement les moyens d'une requête HTTP au cours côté serveur d'expiration de la session.

    En dernier, il y a aussi ServletContext#getContext() qui renvoie le ServletContext d'une autre application web déployée à même serveur (cela ne fonctionne que si le serveur est configuré pour permettre à la croix-contexte de l'accès sur la cible webapp). 

    ServletContext otherContext = context.getContext("/otherContextPath");

    Mais cela nécessite d'ores et déjà l'actuel ServletContext pour commencer, pour laquelle vous devez maintenant déjà savoir quel chemin à utiliser pour l'obtenir.