Filters

Page 1

Agenda

Nessa apresentação, discutiremos:

A definição de filtros

O ciclo de vida dos filtros

Classes Wrappers ou "empacotadores"

Page 2

Filters

Filtros são similares a Servlets, pois:

São definidos no Descritor de Implantação ( arquivo web.xml ).

Eles têm seu próprio ciclo de vida.

Eles têm sua própria API.

Existem 'Request Filters' e 'Response Filters'.

'Request Filters' são usados para executar tarefas antes que a requisição ativa seja enviada ao servlet.

Exemplo: execução de código para checar parâmetros de segurança, reformatar headers de requisição, etc.

'Response Filters' são usados para executar tarefas antes que a resposta seja enviada de volta ao cliente.

Exemplo: checagem de response headers antes que a resposta definitiva seja enviada ao cliente.

Page 3

Filters

São componentes independentes, sendo definidos no Descritor de Implantação ( arquivo web.xml ).

O container decidirá chamar filtros e em quê ordem de acordo com o código do descritor de implantação.

O Descritor de Implantação contém informações de quais URLs estão mapeadas a quais filtros. Exemplo: um padrão de URL chamado whizlabs.do pode estar mapeado para o filtro chamado 'Filter1'

Há apenas uma interface Filter.

Page 4

Chain Filters

Para uma URL particular, filtros podem ser aplicados / estar encadeados um após o outro, em outras palavras, filtros podem estar encadeados, 'Chained', de modo a chamar o próximo filtro um após o outro em sequência.

O próximo filtro em uma cadeia será decidido pelo descritor de implantação.

O container passará os objetos request e response aos filtros.

Na figura abaixo, Filter2 será chamado primeiro que o Filter5 na sequência chain, após o cliente enviar a requisição. Na volta do processo ( resposta da requisição ) antes de ser enviada ao cliente, Será chamado o processo inverso de filtros que no pedido de atendimento de requisição: Filter5 será chamado primeiro e após ele, chamaremos Filter2, após isso a resposta chegará ao cliente.

Page 5

Filter Life Cycle

Filtros são gerenciados pelo container web.

Filtros tem um ciclo de vida ( ditado pelos métodos init(), doFilter() e destroy() ).

Filtros são declarados no descritor de implantação da aplicação web ( arquivo web.xml ).

Page 6

Assinatura dos métodos

Page 7

Declaração do Filtro no DD

No Deployment Descriptor ( web.xml ), o filtro deverá ser primeiramente declarado:

O filtro deve ser mapeado para os recursos que deve filtrar.

< filter-name > será obrigatório, sendo que também podemos ter adicionalmente, < servlet-name > ou < url-pattern > e assim sendo um deles será obrigatório porém não podemos ter os dois juntos.

No exemplo abaixo, todas as urls requisitadas devem ser enviadas ao filtro de nome Filter.

Conforme o que for declarado no DD, a sequência adequada de filtros será criada.

Page 8

Filtros para RequestDispatchers

Filtros podem ser aplicados a RequestDispatchers ( chamadas a manipuladores para forward, include, request e error ).

Como no exemplo anterior:

< filter-name >será obrigatório

< url-pattern > ou < serlvet-name > é obrigatório

Pode haver nenhum ou 4 elementos < dispatcher >, por padrão se não houver nenhum elemento < dispatcher >, então REQUEST será o valor que ativará o filtro.

Page 9

Wrappers ou 'empacotadores'

Podemos criar objetos request e response customizados a partir de wrappers. Ele realizará chamadas aos objetos request e response atuais.

Wrappers empacotam os objetos request e response, realizando chamadas para os objetos request e response reais.

Há 4 classes wrapper que podem ser subclassificadas:

Page 10

Wrappers ou 'empacotadores'

Dessa maneira, podemos realizar outras ações que queremos com nossos objetos request e response ( por exemplo, realizar a compressão da resposta enviada ao cliente ).

Wrappers são exemplos do padrão Decorator.

Page 11

Conclusão

Foram discutidos:

Filtros e Wrappers

Ciclo de vida dos filtros

Filters e RequestDispatcher