Servlets API. Aplicações web usando recursos da Servlets API no desenvolvimento de aplicações web. Professor J. c o l u n a

Transcrição

1 c o l u n a Professor J Servlets API Aplicações web usando recursos da Servlets API no desenvolvimento de aplicações web Everton Coimbra de Araújo (everton@utfpr.edu.br): desde 1987 atua na área de treinamento e desenvolvimento. É mestre em Ciência da Computação, e professor efetivo da UTFPR, Campus Medianeira. Tem atuado também em cursos de EaD oferecidos pela UAB e ETEC. Dedica-se às disciplinas relacionadas ao desenvolvimento de aplicações web e na persistência de objetos, focando seus estudos e pesquisas na plataforma Java (JSP, Servlets, JSF),.NET (ASP.NET) e AJAX. É autor da Visual Books, com seis livros já publicados. Tem proferido palestras em seminários de informática, voltados tanto para o meio acadêmico como para o empresarial. Aplicações web não são mais possibilidades, são realidades cada vez mais necessárias no contexto de aplicações, sejam elas comerciais, administrativas, organizacionais, sejam no mundo financeiro ou no mundo do agronegócio. Não existe mais o contentamento em ter as informações disponíveis dentro da empresa. A necessidade é ter a informação onde quer que se esteja. Desenvolvedores têm procurado se adequar ao paradigma (não mais novo) de aplicações web. Buscam através de frameworks a resolução de seus problemas relacionados à produtividade, o que é correto, pois a necessidade de prontidão no fornecimento de resultados não permite mais escrever uma aplicação em um bloco de notas ou no VI, como alguns puristas ainda pregam. Porém, muitos, ao fazerem uso de frameworks, como Struts, JSF e Spring, dentre outros, esquecem dos recursos oferecidos pela API Servlet, os quais são amplamente utilizados pelos frameworks. Quando se desenvolve uma aplicação web, várias preocupações devem ser atendidas, como, por exemplo, o que o usuário verá e como ele interagirá com a aplicação. Não existem, de maneira fácil e simples de implementar, todos os recursos disponíveis em uma aplicação desktop, como o oferecido pelo Delphi, Visual Basic ou ainda da em um browser (e existem vários), e um browser entende apenas HTML. É claro que é possível fazer uso de CSS e JavaScript para auxiliar na interface e na interatividade com o usuário. Note que este panorama é apresentado não levando em consideração o uso de frameworks e IDEs RAD. Perceba que a interface com o usuário é apenas uma situação a ser avaliada. E a regra de negócio? Quem resolve os problemas? E os dados? Onde eles ficam? Quem controla a interação do usuário com a regra de negócio? Quem fornece dados para o usuário? Quem persiste os dados informados pelo usuário? Servlets são classes pertencentes a uma aplicação web que funcionam no servidor que hospeda uma aplicação web. Normalmente, quando se fala em aplicação web, se generaliza, pensando em aplicação internet. É bom ressaltar que uma aplicação web funciona através do HTTP e, uma aplicação Internet pode ser, por exemplo, atendida via FTP, e um Servlet também pode ser usado para atender esta necessidade. Este artigo apresenta conceitos iniciais relacionados ao desenvolvimento de aplicações web. São apresentados conceitos introdutórios relacionados à estrutura de uma aplicação web e seu funcionamento. O artigo apresenta, também, através de exemplos práticos, a API Servlets. É assumido neste artigo que o leitor não possui conhecimento sobre o desenvolvimento de aplicações web e sobre API Servlet, mas é claro que os pontos trabalhos aqui podem ser, e certamente serão, úteis para demais desenvolvedores. 18

2 A internet e aplicações web Internet como plataforma Por mais que se busque trazer simplicidade ao desenvolvimento de aplicações web, ocultando do desenvolvedor toda a estrutura necessária para o perfeito funcionamento destas aplicações, existem ainda conhecimentos básicos que se fazem necessários. Quando se desenvolve uma aplicação para web, na realidade desenvolve-se para uma plataforma específica, onde qualquer usuário com acesso à internet pode tentar o acesso à sua aplicação. Diferente de uma aplicação desktop, na qual o acesso é restrito, normalmente, à rede onde a mesma está instalada. Ver a internet como uma plataforma, faz com que se pense na infraestrutura necessária para a execução de sua aplicação. Execução das aplicações web Quando se acessa uma aplicação web, ou um site, ou um portal, é possível dizer onde está hospedada fisicamente a aplicação em questão? Há possibilidades de afirmar se os dados retornados ou enviados para a aplicação estão no mesmo local da aplicação? Para o usuário da aplicação, esta é uma informação desnecessária, pois ele apenas quer ser atendido. Esta preocupação deve ser do desenvolvedor. Ele precisa garantir, através de sua implementação, que os recursos estejam disponíveis ao usuário, de forma transparente. No entanto, para o processo de aprendizagem em relação ao desenvolvimento de aplicações web é preciso ter em mente que sua aplicação não se mantém conectada com o usuário da mesma. É necessário saber que as aplicações web, acessadas via browser, são acessadas e atendidas através de requisições e respostas (request e response). Entende-se por requisição (request), no contexto de aplicações web, a solicitação por um recurso disponibilizado na internet, quer seja este recurso uma simples página web, em HTML, quer seja uma URL de uma aplicação. Esta requisição é submetida ao servidor onde o recurso desejado está hospedado. Já uma resposta (response), no contexto de aplicações web, é o retorno de uma requisição. O processo de requisição a um recurso web é possível graças ao protocolo HTTP (HyperText Transfer Protocol). O servidor recebe a requisição, juntamente com dados que vêm junto ao cabeçalho HTTP, como dados informados pelo usuário em um formulário em uma página web. O servidor identifica o serviço e define quem é responsável por ele. O responsável, então, atende a requisição e gera uma resposta para o solicitante (o cliente). Um detalhe importante é saber que quem atende uma requisição normalmente é uma aplicação, implementada em qualquer linguagem, mas a resposta, gerada para o cliente, é sempre HTML. Distribuindo as aplicações Quando se desenvolve uma aplicação web, a mesma precisa ser instalada na máquina servidora, onde um servidor web está instalado. A instalação de uma aplicação web é mais conhecida como Deploy, e a desinstalação como Undeploy. Para este artigo, será utilizado o Apache Tomcat como específica, chamada webapps. O servidor web Como comentado anteriormente, o servidor web utilizado neste artigo é o Apache Tomcat. Desta forma, é preciso ter o mesmo instalado e em perfeito funcionamento. Caso não o tenha em sua máquina, acesse tomcat.apache.org/ e realize o download do arquivo zip da versão 6.x. Descompacte-o em sua máquina. Por default, a porta definida para o tomcat atender a requisições é a Caso esta porta não esteja disponível em sua máquina, localize, na pasta conf, o arquivo server.xml e o edite no bloco de notas. Procure por 8080 e mude para a porta desejada. Para executar o Tomcat é preciso acessar, via console, a pasta onde estão os aplicativos responsáveis pelo startup dele. Esta pasta é nomeada como bin e se encontra dentro da pasta descompactada. Execute o arquivo de no caso de ambientes Unix, como Linux e Mac OS. Ele executará algumas verificações, e se tudo estiver correto, o Tomcat será iniciado e passará a atender as requisições na porta especificada na configuração. Caso a execução não ocorra, pode haver a necessidade de se configurar as variáveis de ambiente apontadas na mensagem de erro. Agora é preciso testar e ver se o Tomcat responde às requisições. Acesse seu browser e digite Caso esteja tudo bem configurado e funcionando, uma página do Tomcat será exibida. Praticando Uma página com conteúdo estático Uma página que possui conteúdo estático é aquela em que sempre, independentemente de qualquer situação, exibirá o mesmo conteúdo. Crie em sua máquina uma pasta chamada, por exemplo, meus_sites e dentro dela outra, chamada olahtml e, dentro desta pasta, crie um arquivo chamado ola.html e dentro dele o código da Listagem 1. Listagem 1. Código da página ola.html, com conteúdo estático. <html> <head><title>página com conteúdo estático</title></head> <body>esta página tem seu conteúdo estático</body> </html> Para o Tomcat, uma aplicação existe quando a mesma está hospedada dentro de seu diretório webapps. Copie a sua pasta olahtml para dentro da pasta webapps. Pode-se dizer que com esta operação, sua aplicação está disponível para ser acessada através de requisições ao Tomcat. Acesse seu browser e digite e o resultado deverá ser a apresentação de sua página no browser. Caso apareça em seu browser uma mensagem que informe o erro 404 (recurso solicitado não encontrado), verifique se informou a URL de forma correta. Caso esteja tudo certo no endereço, é preciso parar o Tomcat e iniciá-lo novamente. Na janela onde invocou o startup (.bat/.sh), execute agora o shutdown (.bat/.sh). Isso interrompe a execução do Tomcat. Execute o arquivo startup.bat (.bat/.sh) para iniciá-lo novamente. 19

3 Professor J Estrutura de uma aplicação web Uma aplicação web precisa ter um local onde são armazenados os recursos disponibilizados pela aplicação para acesso por parte do usuário. Tenha como recursos: páginas web (HTML), imagens, arquivos CSS (Cascade Style Note que o usuário pode acessar diretamente estes recursos através do browser por meio de uma página web ou ainda, em alguns casos, diretamente. Existem outros recursos, como dados armazenados em uma base de dados, que o usuário não pode (e nem deve) acessar diretamente. Uma aplicação web tem ainda recursos que são executados em um ambiente exclusivo do servidor, como, por exemplo, classes que acessem a base de dados para um determinado processamento. Estes recursos não podem ser acessados diretamente pelo usuário através do browser, pois precisam em certas situações de recursos que são gerenciados pelo servidor. Desta forma, é preciso que sua aplicação possua um local específico para armazenamento destes recursos. Uma aplicação pode também fazer uso de outras aplicações, conhecidas como bibliotecas que desempenham uma função específica. Assim sendo, é preciso que a aplicação armazene estes recursos em algum local (pasta/diretório) de sua aplicação. A figura 1 apresenta a estrutura básica necessária para uma aplicação web. Preferences Server Runtime Environment, o que lhe dará acesso a uma janela responsável pela configuração de Runtimes de servidores. Para adicionar um novo servidor, clique no botão Add e será apresentada uma janela para seleção do Runtime desejado. Localize a pasta com opções para Apache Tomcat e clique sobre Apache Tomcat v6.0, marque a opção Create a new local server e em seguida no botão Next. Na nova janela exibida, é preciso informar o nome dado ao novo Server Runtime (Name), assim como o local onde o mesmo se encontra instalado (Tomcat installation directory). As configurações do JRE podem ser mantidas ou sugeridas ou alteradas conforme necessidades específicas. Após clicar no botão Finish, você retornará, pressione OK para concluir a operação. Selecione a guia Server, como mostra a figura 2. Ela exibirá todos os esta guia em seu ambiente, verifique se a perspectiva atual de trabalho Open Perspective Other JEE. Se mesmo assim a guia Server não aparecer, Show View Server. É por meio desta guia que os projetos que representam uma aplicação web são distribuídos para o servidor integrado ao Eclipse criado anteriormente. Figura 2. Guia Server. Figura 1. Estrutura básica de pastas/diretórios para uma aplicação web. cação web. É nela que os recursos acessíveis de forma direta pelo seu pelo container (servidor). A pasta lib possui recursos (bibliotecas) utilizados por sua aplicação. É comum ouvir desenvolvedores que dizem que se mais de uma aplicação utiliza uma mesma biblioteca, esta deve ser colocada na pasta de bibliotecas comuns do container. Não faça isso, pois podem acontecer sérios problemas relacionados ao class loader. A pasta classes é a pasta que terá todas as classes utilizadas por seu projeto, já compiladas e na estrutura de pacotes das mesmas. Criando um projeto com o Eclipse Faremos uso neste artigo da ferramenta de desenvolvimento mais conhecida na comunidade Java, o Eclipse ( A versão é a Ganymede e a distribuição é a Eclipse IDE for Java EE Developers. Configurando o Eclipse para o desenvolvimento de aplicativos web O Eclipse por si só oferece recursos suficientes para o desenvolvimento de aplicações web, porém, o uso de determinados plugins facilitam em muito a vida de um desenvolvedor. Quando se instala o Eclipse IDE for Java EE Developers, alguns recursos já estão disponíveis para o uso, porém não faz parte do escopo deste artigo detalhar estes recursos. Para Criando o projeto Selecione File New janela apresentada, digite o nome de seu projeto no campo Project Name. Em Target Runtime, selecione o servidor criado anteriormente. A versão do botão Next e você será direcionado para uma nova janela, a qual representa a configuração da estrutura básica de uma aplicação web em seu projeto. O uso O Content Directory é o diretório da sua aplicação web dentro do projeto a ser criado, ou seja, é a sua aplicação web. O Java Source Directory é o diretório onde as classes Java (*.java) são armazenadas. As classes já compiladas (*.class) Context Root é o nome pelo qual sua aplicação será referenciada pelo usuário no browser. No exemplo trabalhado anteriormente, a URL solicitada pelo usuário, tem como contexto o nome olahtml. ola.html é o recurso solicitado ao contexto em questão. O contexto a ser utilizado neste exemplo será mundoj. Clique no botão Finish. Uma vez criado o projeto é preciso distribuí-lo (deploy) no servidor. Como o servidor em questão será o integrado ao Eclipse. Clique com o botão direito sobre o servidor na guia Servers e escolha a opção Add and Remove Projects e uma janela com os projetos web será apresentada, para que você possa adicioná-los ou removê-los do servidor em questão. Selecione seu projeto e clique no botão Add para adicioná-lo ao servidor em questão. Após isso, clique no botão Finish. Sua guia Servers deverá estar agora semelhante à exibida na figura

4 Listagem 2. Primeira classe Servlet criada. Criando uma página para testar o projeto Servlets Criando um Servlet Como pode ser verificado na figura 3, o servidor está parado, é preciso iniciá-lo. Para isso, pode-se clicar com o botão direito do mouse sobre o nome do servidor e escolher a opção Start, ou clicar no botão desta funcionalidade que está no topo da guia Servers. colha New HTML. Na janela que é exibida, digite o nome para a página HTML (olamundoj.html, por exemplo) e em seguida clique no botão Finish. O arquivo criado é exibido. Digite Olá Mundoj entre as tags <body></body>. Em seu browser, digite agora o endereço olamundoj.html. Sua página deverá ser exibida, porém, caso não seja, start novamente seu servidor e tente outra vez. Servlets, antes de tudo, são classes Java. Mais especificamente para o contexto do artigo, Servlets são classes que são executadas em um Servlet Container, que no caso deste artigo é o Tomcat. Um Servlet é requisitado por um cliente, recebendo informações enviadas por este para que possa realizar algum processo e, ao término deste processo, ele retorna uma resposta ao cliente. Com a necessidade de se desenvolver aplicações para a web (não apenas sites), a Sun especificou uma API para o desenvolvimento destas aplicações, conhecidas como JSP e Servlet. Não faz parte do escopo deste artigo comentar o que existia antes ou outras tecnologias atuais afins ao tema do artigo. É bom salientar que um Servlet não atende exclusivamente a requisições relacionadas a páginas web. É perfeitamente possível, por exemplo, implementar um Servlet que atende a requisições FTP. Para estas situações, cria-se um servlet, estendendo de GenericServlet, o qual implementa as interfaces Servlet e ServletConfig. com o botão direito sobre o pacote onde o mesmo será criado e escolher a opção New Servlet. É importante que um pacote tenha sido criado para que este servlet seja feito nele. Na janela apresentada, para criação do servlet, parâmetros básicos para a criação do servlet são solicitados. Assegure que a Superclass seja a javax.servlet.genericservlet. Clique no botão Next e na janela seguinte, clique no botão Edit para alterar o valor de URL Mappins para /Ola.MJ. Após isso, clique no botão Next e na última tela deste processo desmarque todos os checkboxes existentes e clique no botão Finish. Com a classe criada, pode ser notado na declaração da classe um erro de compilação (o Eclipse deve exibir isso), que informa a necessidade de implementar métodos definidos em GenericServlet, caso contrário a classe precisa ser definida como abstract. A Listagem 2 exibe o servlet criado, já com o método service() implementado. package servlets; import javax.servlet.genericservlet; public class OlaMundoj extends GenericServlet { public void service(servletrequest request, ServletResponse response) Entendendo o que foi criado A princípio, foi criada apenas uma classe que é, por extensão, um GenericServlet, ou seja, uma classe com capacidade de atender a requisições, que a princípio são limitadas ao HTTP. Foi feito uso de templates (ou wizzards) para a criação desta classe, mas nada impede a criação direta da mesma. O uso deste ferramental para a criação do servlet é útil para a configuração do servlet e consequente disponibilização, pois, se a opção foi de criar diretamente a classe, é preciso ainda registrar a mesma como servlet no arquivo de distribuição (web.xml) para que o mesmo possa ser disponibilizado. Quando se desenvolve uma aplicação servidora, a mesma precisa de configurações especiais para seu funcionamento, tais como recursos a serem disponibilizados. Até este momento, o recurso disponibilizado para a aplicação é o servlet implementado, que ainda não faz nada, mas precisa ser configurado. Esta configuração é implementada em um realizadas até o momento, todas feitas automaticamente pelo uso dos Listagem 3. Arquivo Web.XML. <?xml version= 1.0 encoding= UTF-8?> <web-app xmlns:xsi= xmlns= xmlns:web= xsi:schemalocation= id= WebApp_ID version= 2.5 > <display-name>mundoj01</display-name> <welcome-file-list> <welcome-file>index.jsp</welcome-file> </welcome-file-list> <servlet> <description></description> <display-name>olamundoj</display-name> <servlet-name>olamundoj</servlet-name> <servlet-class>servlets.olamundoj</servlet-class> </servlet> <servlet-mapping> <servlet-name>olamundoj</servlet-name> <url-pattern>/ola.mj</url-pattern> </servlet-mapping> </web-app> 21

5 Professor J Entendendo o conteúdo do Web.xml cação. Um destes elementos é o <welcome-file-list> que relaciona, através de subelementos <welcome-file>, os arquivos a serem requisitados caso a aplicação seja chamada apenas pelo seu nome (pelo seu contexto), como, por exemplo, Na Listagem 3 apenas o arquivo índex.jsp está relacionado, mas poderiam existir outros arquivos referenciados, como, por exemplo: índex.html. O elemento <servlet> descreve um servlet para a aplicação. Os subelementos <description> e <display-name> são responsáveis pelo nome e por uma descrição que podem ser verificadas através de ferramentas que possam gerenciar a aplicação. Em um ambiente de produção é sempre importante documentar o que realmente é cada servlet, assim como sua finalidade e uso. <servlet-name> define o nome lógico do servlet, ou seja, como ele será <servlet-class> refere-se ao nome, qualificado, da classe que representa o servlet em questão. Cada classe servlet deve possuir um elemento <servlet> no web.xml. Os elementos <description> e <display-name> são opcionais. É através do elemento <servlet-mapping> que se define como o usuário poderá acessar a classe definida no elemento <servlet>. Estes dois elementos, <servlet> e <servlet-mapping>, costumam gerar dúvidas quanto ao seu real papel e objetivo. A princípio, tenha em mente que <servlet> define uma classe como um serviço de sua aplicação e <servlet-mapping> define como este serviço pode ser acessado pelo usuário, que pode ser um link existente em alguma página. O subelemento <servlet-name> define para qual elemento <servlet> o mapeamento se refere. O subelemento <urlpattern> define a forma como o usuário requisitará no browser este serviço. Na Listagem 3, está definido /Ola.MJ, o que significa que se o usuário, no browser, digitar a aplicação irá identificar o /Ola.MJ como um mapeamento previamente configurado no <servlet-mapping>, que define o <servlet-name> que identifica o <servlet> que deve ser invocado, o qual define qual é a classe responsável por ele. Implementando uma funcionalidade ao Servlet Um servlet, quando requisitado, tem por objetivo resolver um problema. Normalmente, o servlet deve ser visto como um controlador, a classe que recebe o pedido de um serviço e então define quem deve resolver o solicitado. Para este primeiro exemplo, o servlet irá apresentar um Olá Mundo no browser. Veja a implementação desta funcionalidade na Listagem 4. Teste a alteração requisitando o servlet no browser ( localhost:8080/aplicacaomj/ola.mj). Listagem 4. Implementação do comportamento do servlet. public void service(servletrequest request, ServletResponse response) PrintWriter out = response.getwriter(); out.println( <html><head><title>mundoj</title></head> ); out.println( <body>olá Mundoj</body></html> ); out.close(); Entendendo a implementação do GenericServlet Como pode ser visto na Listagem 2, na linha de declaração da classe, a mesma estende GenericServlet, o que torna a classe um GenericServlet. A classe GenericServlet implementa duas interfaces, Servlet e ServletConfig. A interface Servlet define os métodos responsáveis pela inicialização do servlet, pelo atendimento às requisições e pela destruição/remoção do mesmo e dos recursos alocados, que são: destroy(), getservletconfig(), getservletinfo(), init() e service(). ServletConfig é uma interface que define os métodos responsáveis pela obtenção de informações de configuração do servlet. Estas informações são obtidas através do Servlet Container, o qual tem estas informações registradas no arquivo web. xml. Estes métodos são getinitparameter(), getinitialparameternames(), getservletcontext() e getservletname(). Todos estes métodos são implementados na classe GenericServlet. O método service(), como pode ser comprovado na sua declaração na Listagem 4, recebe dois argumentos, um objeto ServletRequest e um objeto ServletResponse. O objeto ServletRequest tem a responsabilidade de fornecer ao container informações relacionadas ao cliente e sua requisição. O ServletResponse é um objeto criado pelo servlet container e passado como um argumento para o método service(), o qual tem a responsabilidade da geração da resposta a ser enviada como retorno para o cliente. Logo no início do método, verifica-se a obtenção de um objeto Prin- responsável pela escrita de representações de objetos em um Stream (fluxo) em um formato de texto. Através dos métodos print() e println() os textos são enviados ao Stream. A chamada ao método close() fecha o Stream. Como o método service() termina, a resposta é então enviada de volta ao cliente. Com este exemplo de implementação de um Servlet, uma situação fica clara: não é uma boa prática implementar a camada de apresentação (o HTML para o browser) em uma classe, por vários motivos, mas um nítido é o relacionado a uma mudança no layout implicar em codificar e distribuir todas as classes novamente. Apesar de ter sido usado para isso, um Servlet não é para elaborar páginas, mas sim, uma classe, responsável em atender a uma requisição de serviço. Java Server Pages Uma página JSP é um arquivo básico de texto, que contém tags que um browser possa entender. Normalmente estas tags são HTML. Juntamente com estas tags existem elementos especiais, conhecidos como elementos JSP. Estes elementos JSP são utilizados para o processamento da lógica de negócio, o que também permite o dinamismo no conteúdo entre as requisições. Servlets são classes Java que também possibilitam o uso de instruções que permitem a geração de tags HTML, porém páginas JSP são mais indicadas para gerar conteúdo dinâmico relacionado à apresentação de páginas em um browser, o que permite uma melhor leitura, manutenção, e uma maior simplicidade na implementação, além da possibilidade de uso de ferramentas visuais para a produção do layout das páginas. JSP está fora do contexto deste artigo. 22

6 Fazendo uso da API Servlets Apesar de existir a possibilidade de sua aplicação possuir apenas um servlet, o qual serviria como controlador (C) entre as requisições do cliente (V) e a camada de negócio de sua aplicação (M), compondo assim o MVC (Model-View-Controller), é completamente aceitável a existência de mais de um servlet para uma aplicação web. Desta forma, é possível a definição de determinados parâmetros para cada servlet, além, é claro, de configurações especiais para toda a aplicação. Estas configurações escopo deste artigo. Saber mais Links sobre MVC: articles/architecture/, mvc/mvcgui.html e patterns/mvc-detailed.html Link sobre FrontController: Atribuindo e obtendo valores de configuração para a aplicação Suponha que sua aplicação possua um determinado dado que não é oriundo de nenhuma fonte de dados, algo constante e que deve estar disponível para qualquer servlet da aplicação. Este dado pode ser configurado no web.xml no elemento <context-param>, como mostra a Listagem 5. Listagem 5. Configuração do elemento <context-param> no WEB.XML. <context-param> <description> para envio de mensagens de suporte</description> <param-name>support </param-name> <param-value>everton@utfpr.edu.br</param-value> </context-param> A Listagem 6 apresenta um HttpServlet com o método GET implementado, o qual realiza a leitura deste valor. O primeiro ponto a ser observado no código é que esta classe agora estende HttpServlet. Isso quer dizer que o servlet é específico para o HTTP. Dentre as mensagens disponibilizadas por este protocolo estão a GET e a POST. A classe HttpServlet fornece dois métodos para estas mensagens, que são doget() e dopost(), respectivamente. Ambos os métodos recebem um objeto da requisição (HttpServletRequest) e um para a resposta (HttpServletResponse). Observe que o método getservletcontext() que é herdado de HttpServlet traz para o método o contexto no qual o servlet está, ou seja, a aplicação. Através deste objeto, é possível obter informações e configurações realizadas no arquivo web.xml, como o parâmetro support , como pode ser verificado pela invocação ao método getinitparameter(). Listagem 6. Implementação do HttpServlet. public class ServletWEBXML extends HttpServlet { protected void doget(httpservletrequest req, HttpServletResponse resp) ServletContext context = getservletcontext(); PrintWriter out = resp.getwriter(); out.println( <html><head><title>obtendo configurações do arquivo web.xml</title></head> ); out.println( <body>olá, o para suporte é <b> + context.getinitparameter( support ) + </b></body></html> ); out.close(); Atribuindo e obtendo valores de configuração para servlets Da mesma forma que é possível atribuir parâmetros para a aplicação através do web.xml, os quais podem ser acessados por qualquer servlet, é possível também definir parâmetros para cada servlet criado, como pode ser verificado através da Listagem 7. O exemplo desta listagem traz um parâmetro chamado versao. Pense em uma situação em que o servlet é testado, antes de ir para produção e, nesta situação, um comportamento diferenciado para logs de execução talvez seja necessário. Outro subelemento também é apresentado nesta listagem, o <load-on-startup>. Este elemento define que o servlet deverá ser instanciado no momento em que o Tomcat for iniciado. Neste momento, o método init() do servlet é chamado. O valor informado, que deve ser um número inteiro, define a ordem em que o(s) servlet(s) é(são) inicializado(s) (instanciados). Se sua aplicação possui servlets em que atividades a serem realizadas no método init() dependem de serviços realizados em outros servlets (no init()), esta ordem é de extrema relevância. Listagem 7. Configuração do subelemento <init-param> do elemento <servlet> no WEB.XML. <servlet> <display-name>servletwebxml</display-name> <servlet-name>servletwebxml</servlet-name> <servlet-class>servlets.servletwebxml</servlet-class> <init-param> <param-name>versao</param-name> <param-value>teste</param-value> </init-param> <load-on-startup>1</load-on-startup> </servlet> A Listagem 8 apresenta um HttpServlet com o método POST implementado, o qual sobrescreve o método init() (de GenericServlet, que é a superclasse de HttpServlet), assim como o dopost() (de HttpServlet). Busque no console que apresenta o log de startup do TomCat a linha 23

7 Professor J com o texto gerado pelo método init(). Caso o subelemento <load-onstartup> não exista na definição do servlet no web.xml o método init() será invocado na primeira chamada ao recurso. Listagem 8. Implementação do HttpServlet. public class ServletWEBXML extends HttpServlet { protected void dopost(httpservletrequest req, HttpServletResponse resp) PrintWriter out = resp.getwriter(); out.println( <html><head><title>obtendo valores iniciais para o servlet + getservletname() + </title></head> ); out.println( <body>olá, a versão para o servlet <b> + getservletname() + </b> é + getinitparameter( versao ) + </body></html> ); out.close(); public void init() throws ServletException { System.out.println( Servlet instanciado em + new Date()); É preciso notar que ao requisitar este servlet via browser será exibida a this URL. Este erro informa, na realidade, que o servlet não pode atender a uma requisição através do GET do HTTP, que é o que ocorre quando uma URL é requisitada diretamente no browser. Como o servlet implementa o método dopost(), se faz necessária a chamada ao servlet através de um formulário HTML. O uso de formulários é exibido mais adiante. Definição de um cabeçalho e rodapé para um determinado conjunto de requisições Em uma aplicação web é muito comum a existência de áreas comuns entre as páginas, as quais costumam não se alterar, como, por exemplo, o cabeçalho e rodapé. Apesar da existência de frameworks específicos para esta finalidade, como Sitemesh, Tiles e Faceslet, dentre outros, a API Servlet/JSP oferece este recurso básico para definir no web.xml o cabeçalho e rodapé para um conjunto específico de páginas. A Listagem 9 apresenta esta configuração. Observe na listagem o subelemento <url-pattern>. As requisições que possuírem a máscara definida neste subelemento terão, no momento da resposta, inseridas a ela os arquivos especificados como cabeçalho e rodapé. É possível, neste elemento, colocar na máscara caminhos físicos ou lógicos, como /admin/*.jsp. Listagem 9. Definição de cabeçalho e rodapé para um conjunto específico de páginas. <jsp-config> <jsp-property-group> <url-pattern>*.jsp</url-pattern> <include-prelude>cabecalho.jsp</include-prelude> <include-coda>rodape.jsp</include-coda> </jsp-property-group> </jsp-config> Capturando erros através de códigos e exceções Não é uma boa prática permitir que o usuário receba no browser uma tela de erro com o stacktrace do TomCat, pois dificilmente o usuário final entenderá os erros de uma aplicação Java. Através do web.xml, é possível a definição de uma página padrão para exibição de erros. Estes erros podem ser os códigos retornados pelo HTTP ou ainda exceções disparadas pela aplicação. A Listagem 10 apresenta esta configuração. Verifique na listagem a existência de dois elementos <error-page>, um com o subelemento <error-code> e outro com o subelemento <exception-type>, ambos com o subelemento <location>, o qual possui uma referência para qual página a requisição deve ser direcionada em caso de ocorrência do erro mapeado. Listagem 10. Definição de erros que devem ser capturados e redirecionados pela aplicação. <error-page> <error-code>404</error-code> <location>/paginainexistente.html</location> </error-page> <error-page> <exception-type>mj.exceptions.uniquekeyexception</exception-type> <location>/chaveunicaexigida.html</location> </error-page> Definição do tempo máximo para inatividade Ao se desenvolver uma aplicação web, segurança é um dos principais pontos a serem pensados. Desta forma, é preciso pensar na situação em que o usuário conecta-se à sua aplicação para realizar determinada atividade, que tem um começo e fim, em um tempo contínuo. Isso quer dizer que a conexão com sua aplicação (seu browser com o servidor) precisa de um controle, o qual garante que a conexão não ficará ativa caso o usuário não interaja com ela por um determinado tempo. Imagine a situação de um acesso ao seu Home Banking, onde você realiza a conexão em sua conta, sai para atender ao telefone e alguém chega no computador e faz uma transferência não autorizada. Buscando minimizar estes problemas, é oferecido o recurso de tempo máximo de inatividade permitido para uma Sessão. A Listagem 11 apresenta a configuração da sessão <sessionconfig>. Note que o subelemento <session-timeout> define o tempo de cinco minutos de tolerância de inatividade. Listagem 11. Definição do tempo máximo de inatividade tolerado pela aplicação. <session-config> <session-timeout>5</session-timeout> </session-config> Ciclo de vida de um Servlet Os métodos relacionados ao ciclo de vida de um servlet são declarados na interface javax.servlet.servlet e estes métodos são: init(), service() e destroy(). Cada um destes métodos tem seu momento específico de invocação, e ocorrem em tempos diferentes. O init(), como visto anteriormente, ocorre na inicialização do servlet, já o destroy() ocorre quando o mesmo é tirado de serviço. O método service() é o responsável pelo atendimento das requisições, como pôde ser visto no exemplo que implementou um GenericServlet. Em 24

8 um HttpServlet, para o atendimento a uma requisição, os métodos invocados são os doxxx() (neste artigo apenas o doget() e dopost() são apresentados), porém, estes métodos não são chamados diretamente. O método responsável em atender a uma requisição, mesmo em um HttpServlet, ainda é o service(). É ele que delegará a requisição para o método doxxx() específico. A figura 4 apresenta o ciclo de vida para um servlet. instanciado uma única vez, o que facilita o trabalho do container, pois, uma vez instanciado o servlet, ele está disponível na JVM para atender a qualquer requisição. Devido a este fato, o que ocorre quando for solicitada, simultaneamente duas ou mais requisições a este servlet? Elas irão compartilhar o mesmo objeto e seus atributos, de forma semelhante a atributos static. Suponha que dois usuários requisitem simultaneamente o servlet da Listagem 13. Através da identificação do limite de cada cliente, o atributo limitecredito recebe o valor de 4 mil e o valor da compra de 300 para o primeiro usuário. O segundo usuário compra 3 mil e tem o limite identificado de 200. Por alguma situação de escalonamento de threads, a segunda requisição chega antes da primeira no if que verifica se a compra pode ser realizada. Neste caso, o cliente que tem limite de 200 pode chegar com o limite do primeiro usuário e realizar uma compra de 3 mil enquanto seu limite é de 200 e o que tem limite de 3 mil pode ter sua compra de 300 barrada. Listagem 13. Implementação do Servlet com problema de concorrência. Servlets seguros e concorrentes (Thread Safe Servlets) Listagem 12. Formulário HTML para teste de concorrência. <form action= ServletThreadSafe method= post > Cliente:<input type= text id= txtcliente ><br/> Compra:<input type= text id= txtcompra ><br/> <input type= submit value= Confirmar Compra > </form> Figura 4. Ciclo de vida de um Servlet. Como já discutido, um servlet é um recurso disponibilizado para acesso através de requisições do usuário via browser. Deve ser assumido que um servlet não é requisitado de forma única, ou seja, várias requisições simultâneas podem ocorrer no mesmo servlet. Mas como garantir esta concorrência? Diz-se que um servlet deve ser Thread Safe, ou seja, ter a garantia de atender bem e de forma segura a várias chamadas simultâneas. Bem, para garantir isso, um exemplo que traz um problema de concorrência será exibido, o tradicional Cliente pobre, Cliente rico. Veja na Listagem 12 um JSP que recebe dados referentes a uma compra e submete para o servlet implementado na Listagem 13. Observe no servlet da Listagem 13 os métodos init() e destroy(). Ambos chamam sua implementação da superclasse (GenericServlet) e realizam um log de sua atividade através do método log(), que é mais recomendado que o uso do System.out.println(). No método dopost(), é possível verificar o uso do método getparameter() do objeto request para obter dados informados no formulário HTML e que vêm junto com o HTTP. Caso seja usado o método GET no formulário HTML, deve ser implementado o método doget(), porém, a maneira de se obter os dados não muda, mas, na URL apresentada no browser existe alteração. Quando se usa o GET, todos os dados enviados para o servidor são enviados juntos com a URL, o que não é uma boa alternativa para segurança. Outro fato importante é que o getparameter() retorna sempre uma String. Em relação ao problema de concorrência, observe a declaração do atributo limitecredito. Pelo conhecimento básico de orientação a objeto, deduz-se que cada objeto desta classe possuirá este atributo e, pode-se pensar que cada servlet o terá, uma vez que um servlet é uma classe. Porém, um servlet é public class ServletThreadSafe extends HttpServlet { // Este atributo sera compartilhado por todas as requisições private double limitecredito; public void init(servletconfig config) throws ServletException { super.init(config); log( Servlet instanciado em + new Date()); public void destroy() { super.destroy(); log( Servlet tirado de serviço em + new Date()); protected void dopost(httpservletrequest request, HttpServletResponse response) Long cliente = Long.parseLong(request.getParameter( txtcliente )); // Rotina para busca de cliente e identificação de limite de crédito limitecredito = <limite obtido através de consulta ao banco de dados>; Double compra = Double.parseDouble(request.getParameter( txtcompra )); if (compra < limitecredito) throw new ServletException( Saldo insuficiente ); Para resolver este problema, mova a declaração do atributo que está na classe para dentro do método que o utilizará. Isso faz com que a variável seja única para cada requisição. O mais importante é nunca declarar atributos na classe. Redirecionando requisições É muito comum a necessidade de direcionar a requisição do usuário para algum recurso (página, servlet,...) específico. Uma situação típica é o usuário tentar acessar uma página a qual não tem direito de acesso. Neste caso, após esta constatação, sua aplicação deve, ao invés de permitir o acesso, redirecionar o usuário a uma página de login, por exemplo. Existem duas formas de tratar este redirecionamento, e elas estão na implementação da Listagem 1. Observe que na avaliação do usuário e senha como valores corretos existe a chamada ao método sendredirect() do HttpServletResponse. Este método gera a resposta da requisição para o cliente (browser) e então o browser (cliente) realiza uma nova requisição ao servidor, desta vez requisitando o recurso enviado como argumento ao método sendredirect(). Para a negação do if(), há também um redirecionamento, porém, neste caso, através de um Dispatcher. Existem duas 25

9 Professor J diferenças básicas entre estas duas formas de redirecionamento. A primeira diferença é que o sendredirect() atua sobre o HttpServletResponse, ao invés do HttpServletRequest do RequestDispatcher e, a segunda, é que o forward() não devolve uma resposta para browser para que ele possa disparar uma nova requisição. O redirecionamento é realizado diretamente no servidor. Desta forma, a URL exibida no browser, quando se faz uso do forward() não é alterada para a nova URL, ou seja, é mantida a URL da requisição original. Listagem 14. Redirecionamento de requisições. protected void dopost(httpservletrequest request, HttpServletResponse response) String usuario = request.getparameter( usuario ); String senha = request.getparameter( senha ); if (usuario.equals( MJ ) && senha.equals( MJ )) response.sendredirect( liberado.html ); else { RequestDispatcher dispatcher = request.getrequestdispatcher( negado.html ); dispatcher.forward(request, response); Cookies Certamente você já acessou algum site onde precisou digitar seu ou nome de usuário para se conectar e acessar recursos específicos. Na primeira vez, você digitou seu nome/ e sua senha, porém, na segunda vez, seu já aparecia. Como seu aparece automaticamente? Através do uso de Cookies. Cookies também são utilizados por sites de comércio eletrônico. Você acessa uma livraria on-line, compra um livro de JSF e, em um próximo acesso, a livraria exibe na página principal seu novo lançamento de JSF. Como o site sabia de seu interesse por JSF? Através do uso de Cookies. Cookies são pequenos textos enviados do servidor para o cliente (browser) para que possam ser armazenados na máquina do usuário. Estes cookies são novamente enviados a cada requisição do cliente para o servidor. As informações gravadas na máquina do usuário são armazenadas em conjuntos de chave e valor. Os cookies possuem um tempo de vida. Os cookies que têm seu tempo de vida expirado quando a sessão do browser é fechada, são automaticamente eliminados da máquina do usuário. Os cookies estão relacionados a um servidor da web. Quando um usuário solicita uma URL cujo servidor e diretório correspondam àqueles de um ou mais de seus cookies armazenados, o próprio browser se encarrega de enviar os cookies correspondentes de volta para o servidor. O objeto HttpServletRequest oferece o método getcookies(), que retorna todos os cookies que são acessíveis a partir da página requisitada. Para adicionar um novo cookie, faz-se uso do método addcookie() do objeto HttpServletResponse. A Listagem 15 exibe o trecho de um método doget()/ dopost() responsável pela leitura dos Cookies relacionados a uma requisição. Verifique na Listagem 15 o uso do método getcookies() do HttpServletRequest. Ele retorna um array de Cookie. Para identificar a existência do cookie desejado, é feita uma varredura neste array. No exemplo, caso o cookie seja encontrado a referência ao mesmo é armazenada e seu valor pode ser obtido depois, através da chamada ao método getvalue(). A Listagem 16 apresenta o trecho de código responsável pela criação de um cookie. Observe o cons- Listagem 15. Lendo os cookies recebidos através de uma requisição. Cookie cookies[] = req.getcookies(); Cookie cookie = null; if (cookies!= null) { for (Cookie c : cookies) { if (c.getname().equals( nomeusuario )) { cookie = c; break; trutor do Cookie, que recebe seu nome (chave) e seu valor, respectivamente. O valor pode ser obtido através de um campo de formulário HTML, através do método getparameter() do HttpServletRequest. Listagem 16. Criando um cookie. Cookie cookie = new Cookie( nomeusuario, Mundoj ); cookie.setmaxage(10); response.addcookie(cookie); O método setmaxage() recebe o tempo de vida para o cookie, expresso em segundos. Para que um cookie seja removido assim que a sessão do browser terminar e o mesmo for fechado, basta atribuir 0 (zero) ao tempo máximo de vida. O cookie é adicionado ao objeto HttpServletResponse, o qual garante a escrita do mesmo na máquina do cliente. Existe ainda os métodos getname(), getvalue() e setvalue() que podem obter o nome do cookie, seu valor e atribuir um valor ao mesmo, respectivamente. Existem outros métodos não trabalhados neste artigo, mas que valem a pena o estudo, como: get/setdomain(), get/setpath() e get/setsecure(). Sessions Gerenciamento de sessão é o nome dado ao processo de manter o estado de uma aplicação através de múltiplas solicitações HTTP. Como visto anteriormente, através do uso de Cookies, é possível manter informações do usuário para recuperação e uso por sua aplicação para tomadas de decisões. Porém, certamente é de seu conhecimento que o uso de Cookies pode ser desabilitado pelo usuário em seu browser. Além disso, um cookie permite o armazenamento apenas de strings e existe uma limitação para a quantidade de cookies que podem ser armazenados por sua aplicação no cliente. Estes problemas e limitações não existem quando se faz uso de objetos Http- Session. Uma sessão é criada pelo container no momento da primeira requisição do browser e disponibilizada para armazenamento e recuperação de qualquer tipo de objeto. O tempo de vida padrão para uma sessão (sem atividade) é de 30 minutos, porém, como visto anteriormente, este tempo pode ser configurado através do web.xml. A sessão, além de expirar após o tempo definido como limite para inatividade, pode também ser destruída através de código. Uma sessão é um objeto do tipo javax.servlet.httpsession. Cada browser tem sua forma de gerenciamento de sessão no container web. Desta forma, conexões com a mesma aplicação através de browsers diferentes não compartilham os dados mantidos nas sessões criadas por estes browsers. A Listagem 17 apresenta um trecho de código responsável pela obtenção/criação de uma sessão. 26

10 Uma sessão pode ser obtida através do método getsession() de um objeto HttpServletRequest. Chamando este método, sem argumento ou com o argumento true a sessão atual é retornada. Caso não exista uma sessão associada, uma nova é criada. Chamando o método com o argumento false, isso não ocorre. Um objeto pode ser atribuído à sessão através da invocação do método setattribute(), que recebe a chave para o valor a ser armazenado e o valor respectivamente. Diferentemente de um cookie, uma session pode armazenar qualquer tipo de objeto. Na Listagem 17 o objeto é de um tipo criado pelo usuário, uma classe que representa um carrinho de compra. Através do método setmaxinactiveinterval() é possível sobrescrever o tempo máximo aceitável para inatividade na sessão, o qual pode ser inicialmente configurado no arquivo web.xml, como visto anteriormente. A Listagem 18 exibe o trecho de código responsável pela recuperação de um objeto armazenado na sessão. Listagem 17. Criando/obtendo um objeto HttpSession. HttpSession session = request.getsession(true); session.setattribute( carrinho, carrinho); session.setmaxinactiveinterval(60*60*24*2); Listagem 18. Recuperando um objeto previamente armazenado na sessão. HttpSession session = request.getsession(); Carrinho carrinho = (Carrinho) session.getattribute( carrinho ); O método getattribute(), que recebe uma string que representa o nome (chave) do valor desejado, retorna um Object, o qual precisa sofrer um cast para o tipo desejado, como demonstra a Listagem 18. Caso o objeto desejado não exista, é retornado null. Para remover um objeto da sessão, basta chamar o método removeattribute(), enviando como argumento o nome do objeto desejado. Para destruir uma sessão, basta chamar o método invalidate() do objeto HttpSession. Outros métodos interessantes são: isnew() que informa se o objeto Http- Session é novo ou não, no caso do mesmo ter sido criado na invocação do método getsession(); getid() que retorna um identificador único para a sessão; getcreationtime() que retorna o exato momento em que a sessão foi criada; e getmaxinactiveinterval() que retorna o tempo (em segundos) configurado como máximo permitido para inatividade. Filters Pense em uma situação no qual uma determinada área de sua aplicação web (RH por exemplo) precise ser acessada apenas por uma faixa de endereços IPs (os computadores dos funcionários do RH). Como garantir que o recurso requisitado seja disponibilizado apenas para esta faixa de IPs, uma vez que sua aplicação é um ERP e pode estar disponível para a Internet? O uso de filtros é apropriado para este cenário. De maneira simples, filtros são classes, que implementam javax.servlet.filter, que têm a finalidade de capturar uma requisição, realizar uma determinada lógica de negócio e permitir ou não que a requisição seja atendida. Um filtro pode atuar não apenas sobre chamadas à Servlets, mas também a JSPs e HTMLs. Os filtros podem ser encadeados, ou seja, uma requisição pode ser capturada por mais de um filtro. Um filtro tem sua implementação em execução não apenas no processo de requisição, mas também no de resposta, ou seja, após ou atendimento (ou não) do recurso requisitado. A Listagem 19 apresenta a implementação de um filtro, que atende a requisição, desde que o usuário seja o correto, caso contrário o redireciona a uma página de login. Listagem 19. Uso de filtro para verificação de usuário logado. public class ConectedUserFilter implements Filter { public void dofilter(servletrequest request, ServletResponse response, FilterChain filterchain) throws IOException, ServletException { HttpSession session = request.getsession(); Usuario user = (Usuario) session.getattribute( usuarioconectado ); If(user!= null) filterchain.dofilter(request, response); else response.sendredirect( login.jsp ); public void destroy() { public void init(filterconfig arg0) throws ServletException { Veja, na Listagem 19, o método dofilter() responsável pela captura da requisição do usuário e pela lógica do Filtro. Este método recebe um objeto FilterChain, além dos objetos ServletRequest e ServletResponse que um servlet recebe. Este objeto é responsável pelo gerenciamento dos filtros existentes para o recurso solicitado. Observe que caso o usuário esteja logado o método dofilter() do objeto FilterChain é invocado. Caso exista(m) outro(s) filtro(s), ele(s) será(ão) chamado(s) neste momento. Caso o filtro seja o último da cadeia previamente configurada, o recurso solicitado será invocado. A Listagem 20 exibe a configuração do filtro no arquivo web.xml. Listagem 20. Configuração do filtro no WEB.XML. <filter> <filter-name> ConectedUserFilter</filter-name> <filter-class>filter.conecteduserfilter</filter-class> </filter> <filter-mapping> <filter-name> ConectedUserFilter</filter-name> <url-pattern>/*</url-pattern> </filter-mapping> É possível verificar na Listagem 20 que a configuração de um filtro é semelhante à configuração de um servlet. Note pelo elemento <url-pattern> que qualquer requisição feita, será primeiro chamado este filtro. Considerações finais A plataforma Java oferece, através da API Servlets, todos os recursos ne- dir, como visto nos exemplos, os objetivos de um Servlet. Evite utilizá-lo para renderização de código HTML, a não ser que esteja desenvolvendo um framework. Faça uso de Servlets para resolver problemas relacionados à lógica de negócio ou, mais recomendado ainda, para definir quem é responsável por resolver o problema solicitado. O assunto de Servlets não se esgota com este artigo. Existem muitos recursos oferecidos pela API e vale a pena o estudo. Como temas recomendados para estudo ficam: JSP, MVC, FrontController e claro, JSF. Termino este artigo recomendando um acompanhamento na JSR 315 (Servlet 3) e colocando-me Referências jw-0712-threadsafe.html?page=1 27