Could anybody explain me what is the difference between this ways of getting the ServletContext
of an HttpServlet
?
doGet( HttpServletRequest request, ... ){ getServletConfig( ).getServletContext( ); request.getSession( ).getServletContext( ); getServletContext( ); }
Is there any difference in performance or in the context itself? If so, which is the best way? Are there any other way of retrieving the context?
ServletConfig object is obtained by getServletConfig() method. ServletContext object is obtained by getServletContext() method. Each servlet has got its own ServletConfig object. ServletContext object is only one and used by different servlets of the application.
Interface ServletContext. Defines a set of methods that a servlet uses to communicate with its servlet container, for example, to get the MIME type of a file, dispatch requests, or write to a log file. There is one context per "web application" per Java Virtual Machine.
There's one more.
request.getServletContext();
There's technically no difference in performance, only the request.getSession()
will implicitly create the HTTP session object if not created yet. So if this is not done yet, then grabbing the servlet context via the session may take a few nanoseconds longer if the session isn't created yet.
There's also no difference in the returned context. Those methods are all just for convenience and which method to obtain the context depends on the context ;) you're currently sitting in.
If you're sitting in a method invoked by servlet's service()
(such as doGet()
, doPost()
, etc), then just use the inherited getServletContext()
method. Other ways only unnecessarily add more characters to the source code.
@Override protected void doGet(HttpServletRequest request, HttpServletResponse response) { ServletContext context = getServletContext(); // ... }
If you're sitting in servlet's init(ServletConfig)
method, then the inherited getServletContext()
isn't available yet as long as you haven't called super.init(config)
. You'd need to grab it from ServletConfig
.
@Override public void init(ServletConfig config) { ServletContext context = config.getServletContext(); // ... }
But much better is to override init()
instead. In a decent servlet you usually never need to override init(ServletConfig)
.
@Override public void init() { ServletContext context = getServletContext(); // ... }
If you're not sitting in a servlet but in e.g. a filter which lacks the inherited getServletContext()
method and you only have ServletRequest
at hands, then you could grab it from there.
@Override public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) { ServletContext context = request.getServletContext(); // ... }
Note that this is new since Servlet 3.0. Previously, you'd have to grab it from the session.
@Override public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) { ServletContext context = request.getSession().getServletContext(); // ... }
This is however not nice if you worry about unnecessary session creation. Hence the introduction of ServletRequest#getServletContext()
— although you could also simply extract it from FilterConfig
(hey, there's yet another way!).
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(); // ... }
And then there are HTTP session listeners where you could listen on a.o. session destroy. There's no other way to obtain the servlet context than via HttpSession#getServletContext()
.
@Override public void sessionDestroyed(HttpSessionEvent event) { ServletContext context = event.getSession().getServletContext(); // ... }
Here you don't need to worry about unnecessary session creation because it's at that point already created for long beforehand. Do note that there's no ServletRequest
anywhere as there's not necessarily means of an active HTTP request during server side session timeout.
As last, there's also ServletContext#getContext()
which returns the ServletContext
of a different web application deployed to same server (this works only if the server is configured to enable cross context access on the target webapp).
ServletContext otherContext = context.getContext("/otherContextPath");
But this already requires the current ServletContext
to start with, for which you should by now already know which way to use to obtain it.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With