Можно ли использовать статические методы в фильтрах J2EE WebFilter?

Question

Интересно, может ли его безопасный (без вероятности тупика) использовать статический метод внутри веб-фильтров J2ee или я должен использовать методы экземпляра? У меня есть следующий метод doFilter

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); 
    } 
} 

Где

Navigation.getLoginURL()

является статическим методом. Может ли это привести к тупиковой ситуации?

Answer 1

Точка этого статического метода заключается в отсутствии зависимости от состояния экземпляра фильтра; URL-адрес входа в приложение одинаковый. Поскольку нет защищенного состояния, нет причин блокировать что-либо.

Наличие вызова в статическом методе для того, что блокирует (например, System.out.println), не означает, что ваш код будет блокироваться. Java EE-код, реализующий сервлеты и фильтры api, должен избегать много блокировки, потому что он должен поддерживать высокий уровень параллелизма.

Глядя на это с точки реализатор зрения должно помочь вам решить, что вы можете позвонить безопасно, увидеть эту цитату из Java Параллелизм на практике, раздел 4.5.1 (Устный Смутное Документация):

Вы придется угадать. Один из способов улучшить качество вашей догадки - интерпретировать спецификацию с точки зрения того, кто ее реализует (например, поставщик контейнера или базы данных), в отличие от того, кто просто ее использует. Сервлеты всегда вызываются из потока, управляемого контейнером, и можно с уверенностью предположить, что если есть более одного такого потока, контейнер знает об этом. Контейнер сервлета предоставляет определенные объекты, которые обеспечивают обслуживание нескольких сервлетов, таких как HttpSession или ServletContext. Таким образом, контейнер сервлетов должен ожидать одновременного доступа к этим объектам, поскольку он создал несколько потоков и вызвал из них такие методы, как Servlet.service, из которых можно было бы разумно ожидать доступа к ServletContext.

Поскольку невозможно представить однопоточный контекст, в котором эти объекты были бы полезны, следует предположить, что они были созданы в потоковом режиме, хотя спецификация явно не требует этого. Кроме того, если им требуется блокировка на стороне клиента, на какой блокировке должен быть синхронизирован код клиента? Документация не говорит, и это кажется абсурдным догадываться. Это «разумное предположение» дополнительно подкрепляется примерами в спецификациях и официальными учебными пособиями, в которых показано, как получить доступ к ServletContext или HttpSession и не использовать какую-либо клиентскую синхронизацию.