Is it safe to use static methods in J2EE WebFilter filters?

Question

I wonder if its safe ( no probability for deadlock ) to use static method inside J2ee web filters or I should use instance methods ? I have the following doFilter Method

 public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
     HttpServletRequest httpServletRequest = (HttpServletRequest) request;
     HttpServletResponse httpServletResponse = (HttpServletResponse) response;
     String contextPath = httpServletRequest.getContextPath();
     if ((httpServletRequest.getRequestedSessionId() != null &&
             !httpServletRequest.isRequestedSessionIdValid()) || (loginBean == null || loginBean.getUserId() == -1)) {
         httpServletResponse.sendRedirect(contextPath + Navigation.getLoginURL());


     } else {
         chain.doFilter(request, response);
     }
 }

Where

Navigation.getLoginURL()

is a static method. Could this possibly lead to deadlock ?

Answer 1

The point of this being a static method is there's no dependency on the state of the Filter instance; the login url is the same across the application. Since there is no state to protect there is no reason to lock anything.

Having a call in a static method to some thing that locks (like System.out.println) doesn't mean your code will deadlock. Java EE code implementing the api servlets and filters should avoid doing a lot of locking because it needs to support a high level of concurrency.

Looking at this from the implementer's point of view should help you decide what you can call safely, see this quote from Java Concurrency in Practice, section 4.5.1 (Interpreting Vague Documentation):

You are going to have to guess. One way to improve the quality of your guess is to interpret the specification from the perspective of someone who will implement it (such as a container or database vendor), as opposed to someone who will merely use it. Servlets are always called from a container-managed thread, and it is safe to assume that if there is more than one such thread, the container knows this. The servlet container makes available certain objects that provide service to multiple servlets, such as HttpSession or ServletContext. So the servlet container should expect to have these objects accessed concurrently, since it has created multiple threads and called methods like Servlet.service from them that could reasonably be expected to access the ServletContext.

Since it is impossible to imagine a single-threaded context in which these objects would be useful, one has to assume that they have been made thread-safe, even though the specification does not explicitly require this. Besides, if they required client-side locking, on what lock should the client code synchronize? The documentation doesn't say, and it seems absurd to guess. This “reasonable assumption” is further bolstered by the examples in the specification and official tutorials that show how to access ServletContext or HttpSession and do not use any client-side synchronization.