2016-03-07 18 views
13

Qualcuno potrebbe spiegarmi qual è la differenza tra questo modo di ottenere il ?Diversi modi per ottenere il servlet Contesto

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

C'è qualche differenza nelle prestazioni o nel contesto stesso? Se è così, qual è il modo migliore? Ci sono altri modi per recuperare il contesto?

+2

Non c'è differenza. – EJP

risposta

18

Ce n'è uno in più.

request.getServletContext(); 

Non c'è alcuna differenza tecnicamente in termini di prestazioni, solo il request.getSession() implicitamente creare l'oggetto sessione HTTP se non ancora creato. Quindi, se questo non è ancora fatto, allora l'acquisizione del contesto del servlet tramite la sessione potrebbe richiedere qualche nanosecondo più a lungo se la sessione non è ancora stata creata.

Non c'è alcuna differenza nel contesto restituito. Tali metodi sono tutti solo per convenienza e quale metodo per ottenere il contesto dipende dal contesto;.) Si sta seduti in

Se siete seduti in un metodo invocato da servlet di service() (come doGet(), doPost(), ecc.), quindi utilizzare semplicemente il metodo ereditato getServletContext(). Altri modi aggiungono inutilmente più caratteri al codice sorgente.

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

Se siete seduti nel metodo di servlet init(ServletConfig), poi il ereditata getServletContext() non è ancora disponibile fino a quando non hai chiamato super.init(config). Dovresti prenderlo da ServletConfig.

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

ma molto meglio è per ignorare init() invece. In un servlet decente di solito non è necessario eseguire l'override di init(ServletConfig).

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

Se non si è seduti in una servlet ma in, ad es. un filter che non ha il metodo ereditato getServletContext() e hai solo ServletRequest a portata di mano, quindi potresti prenderlo da lì.

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

Si noti che questo è nuovo dal Servlet 3.0. In precedenza, dovevi prenderlo dalla sessione.

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

Questo tuttavia non è bello se si preoccupa la creazione di sessioni non necessarie. Da qui l'introduzione di ServletRequest#getServletContext() — sebbene si possa anche semplicemente estrarlo da FilterConfig (ehi, c'è un altro modo!).

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

E poi ci sono HTTP session listeners dove si poteva ascoltare sulle A.O. sessione distrugge. Non c'è altro modo per ottenere il contesto servlet che tramite HttpSession#getServletContext().

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

Qui non c'è bisogno di preoccuparsi per la creazione della sessione inutile perché è a quel punto già creato per molto tempo in anticipo.Si noti che non è disponibile lo ServletRequest in quanto non vi è necessariamente una richiesta HTTP attiva durante il timeout della sessione lato server.

Come ultimo, c'è anche ServletContext#getContext() che restituisce il ServletContext di una diversa applicazione web distribuito al server stesso (questo funziona solo se il server è configurato per consentire l'accesso contesto croce sulla webapp di destinazione).

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

Ma questo richiede già la corrente ServletContext per cominciare, per il quale si dovrebbe ormai già sa da che parte da utilizzare per ottenerlo.

Problemi correlati