Solucionado (ver solução)
Solucionado
(ver solução)
10
respostas

Dúvidas sobre Filters no Servlet

Estou estudando o capítulo de Filter e fique com a seguinte dúvida: porque, dentro do método "doFilter" dentro da implementação do filtro de exemplo, chamamos novamente o método "doFilter" tendo como base o próprio objeto do filtro? Isso é para chamar possíveis outros filtros (mantendo assim a funcionalidades de filtros ativa caso existam outros)? E se eu não colocar essa linha, o que impactaria?

10 respostas

Oi Alessandro, tudo bem ?

A ideia é passarmos para frente esse filtro, ou seja, que possa executar o comportamento padrão que ele tem definido na classe.

Oi Matheus, desculpe mas não ficou claro. Quando você diz "passar pra frente" esse filtro, o que significa? Porque teria que passar pra frente se eu estou já fazendo algo naquele momento? Poderia exemplificar ou detalhar melhor?

Alessandro,

No caso ele vai chamar o super, ou seja, chamar o comportamento que já foi definido na classe padrão.

Matheus, desculpa... Mas ta complicando ainda mais... Se eu estou estou escrevendo algo pra tratar a informação, porque tenho que chamar a Super? Qual o sentido? O que a Super vai fazer de diferente pra eu ter que chamá-la? Ainda está muito confuso pra mim.

A ideia do filtro é também processar requests, mas ele poderá fazer isso de maneira mais genérica para vários tipos de requests. Mas um filtro vai além de um servlet, com um filtro podemos também fechar "a porta". Esse poder vem do argumento FilterChain (a cadeia de filtros). Ele nos permite indicar ao container que o request deve prosseguir seu processamento.

Hummm... Agora está começando a fazer um certo sentido... Quer dizer então que essa chamada indica ao sistema para seguir o fluxo, que pode ser outros filtros ou os requests e etc? Seria mais ou menos essa linha de raciocínio (mesmo que não seja o conceito exato)?

A ideia é ele interceptar vários requests semelhantes, executar algo, mas depois permitir que o processamento normal do request prossiga através das Servlets e JSPs normais

Qualquer código colocado antes da chamada chain.doFilter(request,response) será executado na ida, qualquer código depois na volta. Com isso podemos fazer um verificação de acesso antes da lógica, ou abrir um recurso (conexão ou transação) antes e na volta fechar o mesmo. Um filtro é ideal para fazer tratamento de error ou medir o tempo de execução.

solução!

Boa tarde, Alessandro! Como vai?

Para explicar com um exemplo prático, vamos definir um filtro aqui:

@WebFilter("/*")
public class MeuFiltro implements Filter {

     public void doFilter(ServletRequest request,
          ServletResponse response,
          FilterChain chain) throws IOException, ServletException {

          // processamento ao receber a requisição

          chain.doFilter(request, response);

          // processamento ao devolver a resposta
        }
    }

A ideia dos filtros é simplesmente executar alguma tarefa que desejamos repetir antes ou depois de um grupo de requisições que nossa aplicação recebe (nesse exemplo, nosso filtro irá pegar todas as requisições). Tudo que estiver antes do chain.doFilter(request, response) será executado quando recebemos a requisição e tudo que estiver despois do chain.doFilter(request, response) será executado após a execução das servles e dos JSPs, ou seja, quando a resposta estiver saindo de nossa aplicação e voltando para o usuário. Caso não executemos o chain.doFilter(request, response) isso implica em bloquearmos a requisição e ela retornará imediatamente para o usuário! Ou seja, fazendo chain.doFilter(request, response) vc está informando ao seu filtro que ele pode deixar a requisição seguir o caminho dela. Depois disso, a requisição pode ir para um outro filtro ou ir direto para a servlet que irá processar ela com a sua lógica de negócio.

Com os filtros podemos fazer:

  • Medir o tempo de execução de uma servlet, uma vez que os filtros são executados ao receber uma requisição (antes do chain.doFilter(request, response)) e depois que a resposta já está pronta (após o chain.doFilter(request, response)).
  • Autorização de acesso, verificando se o usuário tem permissão para acessar o recurso pelo qual ele está requisitando.
  • Verificar se a requisição está sendo feita por um usuário autenticado.
  • Log do sistema.

E, novamente, repare que todas essas ações são coisas que queremos repetir em todas as requisições, então não faria sentido ter que copiar e colar os códigos referentes à essas soluções em todas as nossas servlets. A boa notícia foi que criaram os filtros para resolver esse problema para a gente!

Para saber mais sobre filtros:

Grande abraço e bons estudos!

Caraca Gabriel... Parabéns! Agora ficou claro, inclusive consegui entender as citações do Matheus. Muito obrigado mais uma vez!

Por nada, Alessandro!

Qualquer dúvida, estamos sempre por aí no fórum para tirar as dúvidas!

Grande abraço e bons estudos!