Mostrando postagens com marcador Servlet. Mostrar todas as postagens
Mostrando postagens com marcador Servlet. Mostrar todas as postagens

terça-feira, 2 de agosto de 2011

Servlet Listeners - Listeners de Sessão - Parte 1

Olá Javeiros! Continuando a nossa sequência de posts sobre listeners (aqui tá o primeiro e aqui o segundo) hoje vamos começar a falar sobres os listeners de eventos de sessão. Vamos dividir o assunto em duas partes pois nós temos 4 interfaces para os listeners de sessão.

Antes de mais nada é importante que você saiba o que é uma sessão. Como o foco do post não é esse, não espere nenhum compêndio sobre o assunto aqui, quero apenas lembrar o conceito para aqueles que já viram algo sobre isso. Você nunca estudou o que é uma sessão http? Então é melhor você clicar aqui e dar uma estudada primeiro.

O protocolo HTTP é considerado um protocolo stateless, isso significa que cada requisição que é feita ao servidor é sempre uma novidade. Lembra do filme "Como se fosse a primeira vez"? Pois é, depois que o servidor recebe a requisição e envia a resposta ele jamais lembrará o que tinha nessa requisição. Bom, mas isso é porcaria não? É, realmente seria se não fosse o conceito de sessão http. Uma sessão http nada mais é do que a identificação das requisições de um usuário, como o protocolo http não armazena o estado das requisições, os  clientes enviam algo nela para que servidor saiba que aquela requisição foi feita pelo usuário A e não pelo B. Essa informação é o session ID.

Existem basicamente duas maneiras de implementar o controle de Sessão em uma aplicação Web Java:  através de Cookies ou da reescrita de URLs. A API de Servlets suporta as duas formas e o melhor é que o processo de controle é totalmente automático para o desenvolvedor. Cookies podem ser desabilitados pelo cliente, sendo assim, quando não for possível utilizar esta técnica, os Servlets poderão reescrever as URLs adicionando a elas o nosso Session ID.

A criação de uma Sessão pode ser feita a partir da chamada ao método getSession. Este método retornará a sessão que está associada à requisição atual, caso não exista, uma Sessão nova é criada. Você pode passar um booleano como parâmetro caso deseje decidir criar ou não uma nova sessão.

HttpSession session = request.getSession( ); 

Depois que um sessão é criada, toda requisição feita entre cliente e servidor carregará o session ID. A partir daí precisamos definir o tempo de duração de uma sessão e quando destruí-la, já que não há como saber se o cliente não está mais 'ativo'.

Encerrando uma Sessão

Existem duas formas de encerrar uma sessão, através da definição de um tempo máximo de inatividade setMaxInactiveInterval ou através da chamada ao método invalidate, os dois métodos estão presentes na interface HttpSession. É possível também configurar o tempo máximo através de um parâmetro no arquivo web.xml da aplicação, conforme pode ser visto abaixo:

 <session-config>
   <session-timeout>30</session-timeout>
 </session-config>

Vale apenas ressaltar que o tempo definido através do método setMaxInactiveInterval é em segundos, enquanto no web.xml é em minutos.


HttpSessionListener


A API de Servlets permite que interceptemos o momento em que uma sessão é criada ou destruída. Para isso precisamos criar um Listener de Sessão através da implementação da interface javax.servlet.http.HttpSessionListener. Essa interface possui 2 métodos que serão chamados sempre que uma sessão for criada, sessionCreated, ou destruída, sessionDestroyed. Por último a classe precisa ser configurada no web.xml para que o container possa chamá-la. A API 3.0 de Servlets permite a utilização de annotations na classe Listener, eliminando a necessidade do mapeamento no web.xml.
A seguir temos um exemplo de uma classe que implementa HttpSessionListener utilizando anotações.




Caso você não esteja usando a nova versão de Servlets, você deve mapear o listener no arquivo web.xml da aplicação:

 <listener>
   <listener-class>30</listener-class>
 </listener>


No próximo artigo iremos falar sobre sobre os outros Listeners de Sessão (Activation, Binding e Attribute).
Até o próximo post!

quarta-feira, 30 de junho de 2010

Tomcat 7 foi lançado! Vejas as novidades.

 A apache lançou oficialmente a versão 7 do tomcat, que recentemente completou 10 anos de criação, o que faz dele um projeto bastante maduro, apesar de apenas 7 versões. No mundo open source é comum não termos milhares de versões, afinal de contas esse negócio de mil versões tem um apelo meramente comercial.
Vale a pena conferir a nova versão, que já oferece suporte à especificação de servlets 3.0 e jsp 2.2. Veja aqui tudo que mudou nessa versão e se quiser degustar a versão é só fazer o download aqui.

sábado, 15 de maio de 2010

Servlet API: Utilizando parâmetros de incialização

Olá Javeiros! Dando continuidade ao nosso estudo para a certificação SCWCD veremos neste post rápido como fazer para utilizar parâmetros de inicialização em nossa aplicação e também em um Servlet específico.

É possível adicionar parâmetros que são acessíveis por toda a aplicação. Muitos frameworks web fazem uso desse recurso. Digamos que a aplicação necessite enviar um email para o administrador reportando erros, se colocarmos o email do administrador no código da aplicação e este email sofra alguma mudança, será necessário gerar um novo arquivo de deploy da aplicação. Este problema pode ser resolvido adicionando um parâmetro de inicialização no arquivo descritor (web.xml), e dessa forma ele estará disponível para toda a aplicação.

Digite o trecho a seguir entre as tags web-app do seu arquivo descritor. 


A API de Servlet disponibiliza, através da interface ServletContext, métodos para acessar os parâmetros de inicialização. Existem dois métodos para tal:

  • Enumeration getInitParameterNames: Este método retorna uma enumeration contendo todos os nomes de parâmetros disponíveis no web.xml. Ele é muito útil quando não se sabe o nome do parâmetro.
  • String getInitParameter(String name): Este método retorna o valor (param-value) do parâmetro de inicialização. Vale lembrar que sempre é retornado uma String e nunca outro tipo como Integer, Long, etc.
No trecho de código abaixo podemos ver o uso desses métodos a partir de um servlet.


Quando o servlet for acessado ele irá exibir todos os parâmetros de inicialização disponíveis.
É possível também criar parâmetros de inicialização para Servlets, a diferença é que estes serão visíveis somente para os servlets onde foram declarados. O conceito é basicamente igual ao anterior, porém devemos atentar para as tags que criam cada um deles. No exemplo anterior nós colocamos a tag context-param na raiz do nosso descritor, já para os parâmetros de servlets iremos utilizar a tag init-param e esta deve ser declarada sobre a tag servlet (tag de declaração de um servlet).

O trecho abaixo mostra a criação de um parâmetro para um Servlet.









Veja que a única diferença para o exemplo anterior é a tag init-param. Outra mudança também é na forma como o parâmetro é acessado. Na verdade a mudança é no objeto em que ela é acessado, não mais o ServletContext e sim o próprio Servlet.

Vejamos abaixo o código que acessa os parâmetros do servlet:












Observe que o método getInitiParameterNames é chamado diretamente de Servlet e não mais do contexto como no exemplo anterior.

Então é isso pessoal. Espero que tenham gostado do post! Até o próximo então.

domingo, 9 de maio de 2010

Servlet Listeners - ServletContextAttributeListener

Olá Javeiros! No post anterior começamos a falar sobre servlet listeners. Vamos continuar a série e agora falaremos sobre o listener de atributos de contexto ou ServletContextAttributeListener. Este listener é notificado quando algum atributo é adicionado, removido ou alterado no contexto da aplicação.
A criação deste listener é semelhante ao criamos anteriormente. Teremos que implementar a interface java.servlet.ServletContextAttributeListener e seus três métodos:

  • void attributeAdded(ServletContextAttributeEvent): este método é chamado automaticamente sempre que um atributo for adicionado no ServletContext e através do objeto ServletContextAttributeEvent podemos obter informações como: o nome do atributo adicionado, o seu valor, o objeto em que o evento inicialmente ocorreu e ainda o próprio ServletContext.
  • void attributeRemoved(ServletContextAttributeEvent): este método é chamado sempre que um atributo for removido do contexto.
  • attributeReplaced(ServletContextAttributeEvent): é chamado sempre que um atributo tiver o seu valor alterado.
Vejamos um exemplo prático onde exibimos o nome de atributo e o seu valor para cada evento.















A configuração do listener é feita da mesma forma que anterior. Vale lembrar que não é possível declarar várias classes listener dentro da tag , é preciso criar um conjunto pra cada listener, como vemos abaixo:










Aprendemos mais um listener hoje! Boa sorte nos estudos e até o próximo post!

sábado, 8 de maio de 2010

Servlet Listeners - ServletContextListener

Olá Javeiros de plantão! Continuando nossa sequência de posts sobre o exame para SCWCD vamos falar hoje sobre Servlet Listeners. O exame requer que o candidato saiba criar e configurar listeners para os escopos do ciclo de vida de uma aplicação, listeners de atributos e também serem capazes de escolher um filtro apropriado para um determinado cenário. Iremos ver como funcionam os listeners cobrados no exame. Neste artigo falaremos especificamente do listener de contexto (criação ou destruição).

Suponhamos que uma aplicação web necessite de alguns recursos para que esta possa funcionar corretamente. É importante que estes recursos esteja disponíveis assim que a aplicação esteja no "ar", mas como saber se aplicação já foi carregada pelo container? E como garantir que os recursos serão liberados após a aplicação ser desativada? Para resolver o problema descrito neste cenário a API de Servlet disponibiliza um listener de contexto. Através dele e possível sabermos o momento em que a aplicação está sendo carregada ou destruída.

O processo de criação de um listener resume-se basicamente em implementar a interface do listener desejado e fazer a configuração do mesmo no descritor da aplicação (web.xml). Para esse primeiro post iremos utilizar a interface javax.servlet.ServletContextListener. Esta interface deve ser utilizada para a criação de listeners de contexto e ela possui dois métodos que devem ser sobrescritos pela classe implementadora. Os dois métodos são:
  • void contextInitialized (ServletContextEvent): Este método é executado no momento em que a aplicação é carregada pelo container, através do parâmetro ServletContextEvent, que é injetado automaticamente pelo container, é possível obter o objeto ServletContext, onde poderemos adicionar, remover ou capturar atributos ou fazer a leitura de parâmetros de inicialização. ATENÇÃO: este método só é chamado UMA ÚNICA vez durante o toda a vida da aplicação.
  • void contextDestroyed (ServletContextEvent): Este método é executado no momento em que aplicação está sendo destruída (parada) pelo container. Assim como o método de inicialização este método também só é executado uma vez.
Abaixo temos um exemplo simples de como criar um listener de contexto. No nosso exemplo apenas adicionamos um atributo contendo o momento em que aplicação subiu e podemos usar este atributo para saber quanto tempo a aplicação ficou ativa. O exemplo não é dos melhores, mas você aprenderá com ele que é capaz adicionar atributos que serão visíveis por toda a aplicação no momento seguinte à subida da mesma. Quando a aplicação for destruída o sistema irá exibir uma mensagem contendo o tempo total em segundos que a aplicação ficou no ar.

Primeiramente vamos criar a classe que irá implementar a interface ServletContextListener e vamos também implementar seus dois métodos:












Agora precisamos configurar o nosso listener no arquivo descritor da aplicação, que é o arquivo web.xml da aplicação. Vejamos abaixo como configurar o nosso listener.









A configuração de um listener é bastante simples e resume-se em declarar a classe que implementa a interface de listener. A aplicação irá carregar os listeners na ordem em que eles aparecerem no arquivo web.xml.
Espero que este post seja útil de alguma forma pra você! Até o próximo post!