java - Diferentes maneras de obtener Servlet Context

servlets

Question

¿Podría alguien explicarme cuál es la diferencia entre estas formas de obtener el ServletContext de un HttpServlet ?

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

¿Hay alguna diferencia en el rendimiento o en el propio contexto? Si es así, ¿cuál es la mejor manera? ¿Hay alguna otra forma de recuperar el contexto?

Answer 1

Hay uno más.

request.getServletContext();

Técnicamente no hay diferencia en el rendimiento, solo request.getSession() creará implícitamente el objeto de sesión HTTP si aún no se ha creado. Por lo tanto, si aún no se ha hecho esto, entonces tomar el contexto del servlet a través de la sesión puede demorar unos nanosegundos más si la sesión aún no se ha creado.

Tampoco hay diferencia en el contexto devuelto. Esos métodos son todos solo por conveniencia y el método para obtener el contexto depende del contexto;

Si está sentado en un método invocado por el service() de servlet service() (como doGet() , doPost() , etc.), simplemente use el getServletContext() heredado getServletContext() . Otras formas solo añaden innecesariamente más caracteres al código fuente.

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

Si está sentado en el método init(ServletConfig) del servlet, entonces el getServletContext() heredado getServletContext() no está disponible mientras no haya llamado super.init(config) . Necesitarías agarrarlo desde ServletConfig .

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

Pero mucho mejor es anular init() lugar. En un servlet decente, por lo general, nunca es necesario anular init(ServletConfig) .

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

Si no está sentado en un servlet pero en, por ejemplo, en un filter que carece del getServletContext() heredado getServletContext() y solo tiene ServletRequest en sus manos, puede capturarlo desde allí.

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

Tenga en cuenta que esto es nuevo desde Servlet 3.0. Anteriormente, tendrías que tomarlo de la sesión.

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

Sin embargo, esto no es agradable si te preocupas por la creación de sesiones innecesarias. De ahí la introducción de ServletRequest#getServletContext() , aunque también podría simplemente extraerlo de FilterConfig (hey, ¡hay otra manera!).

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();
    // ...
}

Y luego están los escuchas de sesión HTTP donde puedes escuchar en una sesión de destruir. No hay otra manera de obtener el contexto del servlet que no sea a través de HttpSession#getServletContext() .

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

Aquí no debe preocuparse por la creación de sesiones innecesarias, ya que en ese momento ya se creó con mucha anticipación. Tenga en cuenta que no hay ServletRequest ninguna parte, ya que no hay necesariamente medios para una solicitud HTTP activa durante el tiempo de espera de la sesión del lado del servidor.

Como último, también está ServletContext#getContext() que devuelve el ServletContext de una aplicación web diferente implementada en el mismo servidor (esto solo funciona si el servidor está configurado para permitir el acceso de contexto cruzado en la aplicación web de destino).

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

Pero esto ya requiere el ServletContext actual para comenzar, para el cual ya debería saber qué forma usar para obtenerlo.