Precedencia de la restricción de seguridad sobre los filtros en Servlets

Mientras estudiaba sobre las restricciones de seguridad y los filtros en los servlets, hice las siguientes declaraciones en el archivo web.xml, que no funcionaron como esperaba:

<security-constraint>
    <web-resource-collection>
      <web-resource-name>BeerSelector</web-resource-name>
        <url-pattern>/SelectBeer.do</url-pattern>
        <http-method>GET</http-method>
        <http-method>POST</http-method>
      </web-resource-collection>
     <auth-constraint>
        <role-name>Admin</role-name>
     </auth-constraint>
 </security-constraint>


  <filter>
   <filter-name>LoginFilter</filter-name>
   <filter-class>model.MyFilter</filter-class>
  </filter>


  <filter-mapping>
  <filter-name>LoginFilter</filter-name>
  <url-pattern>/SelectBeer.do</url-pattern>
  </filter-mapping>

Según lo que leí: los filtros deben encontrarseantes de la solicitud llega a una determinada url, entonces, ¿por qué se invoca primero la restricción de seguridad?

Sé que tiene sentido desde el punto de vista de la seguridad (para llegar al filtro que debe estar autenticado), pero me gustaría saber elsecuencia activada por la solicitud.

¿El contenedor busca primero los recursos seguros y, por lo tanto, activa la restricción de seguridad?

Pero esto contradecirá con el siguiente párrafo citado de Head First Servlets y Jsp "

Recuerda que en el DD, se trata de lo que sucede.después la solicitud. En otras palabras, el cliente ya ha realizado la solicitud cuando el Contenedor comienza a mirar los elementos para decidir cómo responder. Los datos de solicitud ya han sido enviados por el cable.

o tal vez la solicitud solo active ambos: filtro y restricción de seguridad, pero ¿la restricción de seguridad se favorece sobre el filtro?