Precedência de restrição de segurança em filtros em Servlets

Ao estudar sobre restrições de segurança e filtros em servlets, fiz as seguintes declarações no arquivo web.xml, que não funcionaram como eu esperava:

<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>

De acordo com o que eu li: filtros devem ser encontradosantes a solicitação atinge um determinado URL, então como a restrição de segurança é invocada primeiro?

Eu sei que faz sentido a partir de uma segurança (para alcançar o filtro você pode ser autenticado), mas eu gostaria de saber osequência desencadeada pelo pedido.

O contêiner pesquisa primeiro os recursos protegidos e, portanto, aciona a restrição de segurança?

Mas isso vai contradizer o seguinte parágrafo citado de Head First Servlets and Jsp "

Lembre-se que no DD, é sobre o que acontecedepois de o pedido. Em outras palavras, o cliente já fez a solicitação quando o Container começa a examinar os elementos para decidir como responder. Os dados da solicitação já foram enviados pelo fio

ou talvez o pedido apenas acione ambos: filtro e restrição de segurança, mas a restrição de segurança é favorecida pelo filtro?

questionAnswers(2)

yourAnswerToTheQuestion