Jspservlets

Sumário
I Sobre essa Apostila 3
II Informações Básicas 5
III GNU Free Documentation License 10
IV JSP e Servlets 19
1 O que é JSP e o que são Servlets 20
2 Plano de ensino 21
2.1 Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.2 Público Alvo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.3 Pré-requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.4 Descrição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.5 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.6 Cronograma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.7 Programa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.8 Avaliação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.9 Bibliografia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3 Iniciando em JSP e Servlets 24
3.1 Definições: JSP e Servlets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2 Comparação de Java Server Pages com Servlets . . . . . . . . . . . . . . . . . . . . 25
3.3 Aplicações Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4 Instalações e Configurações 29
4.1 Instalações Necessárias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.2 Estrutura de Diretórios do Tomcat . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5 Fundamentos da Orientação a Objeto 33
5.1 Classes, Objetos e Métodos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.2 Conceitos Importantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.3 Variáveis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.4 Modificadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.5 Pacotes (Packages): . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.6 Uma Página em JSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
1

CDTC Centro de Difusão de Tecnologia e Conhecimento Brasil/DF
5.7 Condicionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.8 Repetição(loop) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
6 TAGS JSP 40
6.1 TAGS - Expressões, Scriptlets e Declarações . . . . . . . . . . . . . . . . . . . . . . 40
6.2 TAGS - Diretivas e Comentários - e Ações . . . . . . . . . . . . . . . . . . . . . . . . 42
7 JSTL e Javabeans 46
7.1 Noções JavaBeans e EJB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
7.2 JSTL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
8 Servlets: Criação e Ciclo 50
8.1 O que são Servlets? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
8.2 Criar o primeiro Servlet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
8.3 Um Exemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
8.4 O Ciclo de Vida de um Servlet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
8.5 Métodos de Serviço . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
8.6 Implementação e Publicação de servlets . . . . . . . . . . . . . . . . . . . . . . . . . 60
8.7 HTML e Java - Servlets e JSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
8.8 Mapear uma servlet para uma URL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
8.9 Retornando ao cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
8.10 Cookies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
9 Servlets: API, Request e Response 63
9.1 Requisição e Resposta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
9.2 Servlet - O “CGI de Java” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
9.3 CGI X Servlets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
9.4 API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
9.5 Interfaces do doGet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
10 Usando Cookies e Controlando Sessões 69
10.1 Cookies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
10.2 Sessões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
11 Controle de Erros 72
11.1 Erros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
11.2 MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
2

Conteúdo
O conteúdo dessa apostila é fruto da compilação de diversos materiais livres publicados na in-
ternet, disponíveis em diversos sites ou originalmente produzido no CDTC (http://www.cdtc.org.br.)
O formato original deste material bem como sua atualização está disponível dentro da licença
GNU Free Documentation License, cujo teor integral encontra-se aqui reproduzido na seção de
mesmo nome, tendo inclusive uma versão traduzida (não oﬁcial).
A revisão e alteração vem sendo realizada pelo CDTC (suporte@cdtc.org.br) desde outubro
de 2006. Críticas e sugestões construtivas serão bem-vindas a qualquer hora.
Autores
A autoria deste é de responsabilidade de Júlio Cesar Júnior (julio@cdtc.org.br) .
O texto original faz parte do projeto Centro de Difusão de Tecnologia e Conhecimento que
vêm sendo realizado pelo ITI (Instituto Nacional de Tecnologia da Informação) em conjunto com
outros parceiros institucionais, e com as universidades federais brasileiras que tem produzido e
utilizado Software Livre apoiando inclusive a comunidade Free Software junto a outras entidades
no país.
Informações adicionais podem ser obtidas através do email ouvidoria@cdtc.org.br, ou da
home page da entidade, através da URL http://www.cdtc.org.br.
Garantias
O material contido nesta apostila é isento de garantias e o seu uso é de inteira responsabi-
lidade do usuário/leitor. Os autores, bem como o ITI e seus parceiros, não se responsabilizam
direta ou indiretamente por qualquer prejuízo oriundo da utilização do material aqui contido.
Licença
Copyright ©2006, Instituto Nacional de Tecnologia da Informação (cdtc@iti.gov.br) .
Permission is granted to copy, distribute and/or modify this document under the terms
of the GNU Free Documentation License, Version 1.1 or any later version published by
the Free Software Foundation; with the Invariant Chapter being SOBRE ESSA APOS-
TILA. A copy of the license is included in the section entitled GNU Free Documentation
License.
4

Parte II
Informações Básicas
5

Sobre o CDTC
Objetivo Geral
O Projeto CDTC visa a promoção e o desenvolvimento de ações que incentivem a dissemina-
ção de soluções que utilizem padrões abertos e não proprietários de tecnologia, em proveito do
desenvolvimento social, cultural, político, tecnológico e econômico da sociedade brasileira.
Objetivo Específico
Auxiliar o Governo Federal na implantação do plano nacional de software não-proprietário e
de código fonte aberto, identificando e mobilizando grupos de formadores de opinião dentre os
servidores públicos e agentes políticos da União Federal, estimulando e incentivando o mercado
nacional a adotar novos modelos de negócio da tecnologia da informação e de novos negócios
de comunicação com base em software não-proprietário e de código fonte aberto, oferecendo
treinamento específico para técnicos, profissionais de suporte e funcionários públicos usuários,
criando grupos de funcionários públicos que irão treinar outros funcionários públicos e atuar como
incentivadores e defensores dos produtos de software não proprietários e código fonte aberto, ofe-
recendo conteúdo técnico on-line para serviços de suporte, ferramentas para desenvolvimento de
produtos de software não proprietários e do seu código fonte livre, articulando redes de terceiros
(dentro e fora do governo) fornecedoras de educação, pesquisa, desenvolvimento e teste de pro-
dutos de software livre.
Guia do aluno
Neste guia, você terá reunidas uma série de informações importantes para que você comece
seu curso. São elas:
• Licenças para cópia de material disponível;
• Os 10 mandamentos do aluno de Educação a Distância;
• Como participar dos foruns e da wikipédia;
• Primeiros passos.
É muito importante que você entre em contato com TODAS estas informações, seguindo o
roteiro acima.
Licença
Copyright ©2006, Instituto Nacional de Tecnologia da Informação (cdtc@iti.gov.br).
6

É dada permissão para copiar, distribuir e/ou modiﬁcar este documento sob os termos
da Licença de Documentação Livre GNU, Versão 1.1 ou qualquer versão posterior
públicada pela Free Software Foundation; com o Capitulo Invariante SOBRE ESSA
APOSTILA. Uma cópia da licença está inclusa na seção entitulada "Licença de Docu-
mentação Livre GNU".
Os 10 mandamentos do aluno de educação online
• 1. Acesso à Internet: ter endereço eletrônico, um provedor e um equipamento adequado é
pré-requisito para a participação nos cursos a distância;
• 2. Habilidade e disposição para operar programas: ter conhecimentos básicos de Informá-
tica é necessário para poder executar as tarefas;
• 3. Vontade para aprender colaborativamente: interagir, ser participativo no ensino a distân-
cia conta muitos pontos, pois irá colaborar para o processo ensino-aprendizagem pessoal,
dos colegas e dos professores;
• 4. Comportamentos compatíveis com a etiqueta: mostrar-se interessado em conhecer seus
colegas de turma respeitando-os e se fazendo ser respeitado pelos mesmos;
• 5. Organização pessoal: planejar e organizar tudo é fundamental para facilitar a sua revisão
e a sua recuperação de materiais;
• 6. Vontade para realizar as atividades no tempo correto: anotar todas as suas obrigações e
realizá-las em tempo real;
• 7. Curiosidade e abertura para inovações: aceitar novas idéias e inovar sempre;
• 8. Flexibilidade e adaptação: requisitos necessário à mudança tecnológica, aprendizagens
e descobertas;
• 9. Objetividade em sua comunicação: comunicar-se de forma clara, breve e transparente é
ponto - chave na comunicação pela Internet;
• 10. Responsabilidade: ser responsável por seu próprio aprendizado. O ambiente virtual não
controla a sua dedicação, mas reﬂete os resultados do seu esforço e da sua colaboração.
Como participar dos fóruns e Wikipédia
Você tem um problema e precisa de ajuda?
Podemos te ajudar de 2 formas:
A primeira é o uso dos fóruns de notícias e de dúvidas gerais que se distinguem pelo uso:
. O fórum de notícias tem por objetivo disponibilizar um meio de acesso rápido a informações
que sejam pertinentes ao curso (avisos, notícias). As mensagens postadas nele são enviadas a
7

todos participantes. Assim, se o monitor ou algum outro participante tiver uma informação que
interesse ao grupo, favor postá-la aqui.
Porém, se o que você deseja é resolver alguma dúvida ou discutir algum tópico específico do
curso. É recomendado que você faça uso do Fórum de dúvidas gerais que lhe dá recursos mais
efetivos para esta prática.
. O fórum de dúvidas gerais tem por objetivo disponibilizar um meio fácil, rápido e interativo
para solucionar suas dúvidas e trocar experiências. As mensagens postadas nele são enviadas
a todos participantes do curso. Assim, fica muito mais fácil obter respostas, já que todos podem
ajudar.
Se você receber uma mensagem com algum tópico que saiba responder, não se preocupe com a
formalização ou a gramática. Responda! E não se esqueça de que antes de abrir um novo tópico
é recomendável ver se a sua pergunta já foi feita por outro participante.
A segunda forma se dá pelas Wikis:
. Uma wiki é uma página web que pode ser editada colaborativamente, ou seja, qualquer par-
ticipante pode inserir, editar, apagar textos. As versões antigas vão sendo arquivadas e podem
ser recuperadas a qualquer momento que um dos participantes o desejar. Assim, ela oferece um
ótimo suporte a processos de aprendizagem colaborativa. A maior wiki na web é o site "Wikipé-
dia", uma experiência grandiosa de construção de uma enciclopédia de forma colaborativa, por
pessoas de todas as partes do mundo. Acesse-a em português pelos links:
• Página principal da Wiki - http://pt.wikipedia.org/wiki/
Agradecemos antecipadamente a sua colaboração com a aprendizagem do grupo!
Primeiros Passos
Para uma melhor aprendizagem é recomendável que você siga os seguintes passos:
• Ler o Plano de Ensino e entender a que seu curso se dispõe a ensinar;
• Ler a Ambientação do Moodle para aprender a navegar neste ambiente e se utilizar das
ferramentas básicas do mesmo;
• Entrar nas lições seguindo a seqüência descrita no Plano de Ensino;
• Qualquer dúvida, reporte ao Fórum de Dúvidas Gerais.
Perfil do Tutor
Segue-se uma descrição do tutor ideal, baseada no feedback de alunos e de tutores.
O tutor ideal é um modelo de excelência: é consistente, justo e profissional nos respectivos
valores e atitudes, incentiva mas é honesto, imparcial, amável, positivo, respeitador, aceita as
idéias dos estudantes, é paciente, pessoal, tolerante, apreciativo, compreensivo e pronto a ajudar.
8

A classificação por um tutor desta natureza proporciona o melhor feedback possível, é crucial, e,
para a maior parte dos alunos, constitui o ponto central do processo de aprendizagem.’ Este tutor
ou instrutor:
• fornece explicações claras acerca do que ele espera e do estilo de classificação que irá
utilizar;
• gosta que lhe façam perguntas adicionais;
• identifica as nossas falhas, mas corrige-as amavelmente’, diz um estudante, ’e explica por-
que motivo a classificação foi ou não foi atribuída’;
• tece comentários completos e construtivos, mas de forma agradável (em contraste com um
reparo de um estudante: ’os comentários deixam-nos com uma sensação de crítica, de
ameaça e de nervossismo’)
• dá uma ajuda complementar para encorajar um estudante em dificuldade;
• esclarece pontos que não foram entendidos, ou corretamente aprendidos anteriormente;
• ajuda o estudante a alcançar os seus objetivos;
• é flexível quando necessário;
• mostra um interesse genuíno em motivar os alunos (mesmo os principiantes e, por isso,
talvez numa fase menos interessante para o tutor);
• escreve todas as correções de forma legível e com um nível de pormenorização adequado;
• acima de tudo, devolve os trabalhos rapidamente;
9

Parte III
GNU Free Documentation License
10

(Traduzido pelo João S. O. Bueno através do CIPSGA em 2001)
Esta é uma tradução não oficial da Licença de Documentação Livre GNU em Português Brasi-
leiro. Ela não é publicada pela Free Software Foundation, e não se aplica legalmente a distribuição
de textos que usem a GFDL - apenas o texto original em Inglês da GNU FDL faz isso. Entretanto,
nós esperamos que esta tradução ajude falantes de português a entenderem melhor a GFDL.
This is an unofficial translation of the GNU General Documentation License into Brazilian Por-
tuguese. It was not published by the Free Software Foundation, and does not legally state the
distribution terms for software that uses the GFDL–only the original English text of the GFDL does
that. However, we hope that this translation will help Portuguese speakers understand the GFDL
better.
Licença de Documentação Livre GNU Versão 1.1, Março de 2000
Copyright (C) 2000 Free Software Foundation, Inc.
59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
É permitido a qualquer um copiar e distribuir cópias exatas deste documento de licença, mas
não é permitido alterá-lo.
INTRODUÇÃO
O propósito desta Licença é deixar um manual, livro-texto ou outro documento escrito "livre"no
sentido de liberdade: assegurar a qualquer um a efetiva liberdade de copiá-lo ou redistribui-lo,
com ou sem modificações, comercialmente ou não. Secundariamente, esta Licença mantém
para o autor e editor uma forma de ter crédito por seu trabalho, sem ser considerado responsável
pelas modificações feitas por terceiros.
Esta Licença é um tipo de "copyleft"("direitos revertidos"), o que significa que derivações do
documento precisam ser livres no mesmo sentido. Ela complementa a GNU Licença Pública Ge-
ral (GNU GPL), que é um copyleft para software livre.
Nós fizemos esta Licença para que seja usada em manuais de software livre, por que software
livre precisa de documentação livre: um programa livre deve ser acompanhado de manuais que
provenham as mesmas liberdades que o software possui. Mas esta Licença não está restrita a
manuais de software; ela pode ser usada para qualquer trabalho em texto, independentemente
do assunto ou se ele é publicado como um livro impresso. Nós recomendamos esta Licença prin-
cipalmente para trabalhos cujo propósito seja de introdução ou referência.
APLICABILIDADE E DEFINIÇÕES
Esta Licença se aplica a qualquer manual ou outro texto que contenha uma nota colocada pelo
detentor dos direitos autorais dizendo que ele pode ser distribuído sob os termos desta Licença.
O "Documento"abaixo se refere a qualquer manual ou texto. Qualquer pessoa do público é um
11

licenciado e é referida como "você".
Uma "Versão Modificada"do Documento se refere a qualquer trabalho contendo o documento
ou uma parte dele, quer copiada exatamente, quer com modificações e/ou traduzida em outra
língua.
Uma "Seção Secundária"é um apêndice ou uma seção inicial do Documento que trata ex-
clusivamente da relação dos editores ou dos autores do Documento com o assunto geral do
Documento (ou assuntos relacionados) e não contém nada que poderia ser incluído diretamente
nesse assunto geral (Por exemplo, se o Documento é em parte um livro texto de matemática, a
Seção Secundária pode não explicar nada de matemática).
Essa relação poderia ser uma questão de ligação histórica com o assunto, ou matérias relaci-
onadas, ou de posições legais, comerciais, filosóficas, éticas ou políticas relacionadas ao mesmo.
As "Seções Invariantes"são certas Seções Secundárias cujos títulos são designados, como
sendo de Seções Invariantes, na nota que diz que o Documento é publicado sob esta Licença.
Os "Textos de Capa"são certos trechos curtos de texto que são listados, como Textos de Capa
Frontal ou Textos da Quarta Capa, na nota que diz que o texto é publicado sob esta Licença.
Uma cópia "Transparente"do Documento significa uma cópia que pode ser lida automatica-
mente, representada num formato cuja especificação esteja disponível ao público geral, cujos
conteúdos possam ser vistos e editados diretamente e sem mecanismos especiais com editores
de texto genéricos ou (para imagens compostas de pixels) programas de pintura genéricos ou
(para desenhos) por algum editor de desenhos grandemente difundido, e que seja passível de
servir como entrada a formatadores de texto ou para tradução automática para uma variedade
de formatos que sirvam de entrada para formatadores de texto. Uma cópia feita em um formato
de arquivo outrossim Transparente cuja constituição tenha sido projetada para atrapalhar ou de-
sencorajar modificações subsequentes pelos leitores não é Transparente. Uma cópia que não é
"Transparente"é chamada de "Opaca".
Exemplos de formatos que podem ser usados para cópias Transparentes incluem ASCII sim-
ples sem marcações, formato de entrada do Texinfo, formato de entrada do LaTex, SGML ou XML
usando uma DTD disponibilizada publicamente, e HTML simples, compatível com os padrões, e
projetado para ser modificado por pessoas. Formatos opacos incluem PostScript, PDF, formatos
proprietários que podem ser lidos e editados apenas com processadores de texto proprietários,
SGML ou XML para os quais a DTD e/ou ferramentas de processamento e edição não estejam
disponíveis para o público, e HTML gerado automaticamente por alguns editores de texto com
finalidade apenas de saída.
A "Página do Título"significa, para um livro impresso, a página do título propriamente dita,
mais quaisquer páginas subsequentes quantas forem necessárias para conter, de forma legível,
o material que esta Licença requer que apareça na página do título. Para trabalhos que não
tenham uma página do título, "Página do Título"significa o texto próximo da aparição mais proe-
minente do título do trabalho, precedendo o início do corpo do texto.
12

FAZENDO CÓPIAS EXATAS
Você pode copiar e distribuir o Documento em qualquer meio, de forma comercial ou não
comercial, desde que esta Licença, as notas de copyright, e a nota de licença dizendo que esta
Licença se aplica ao documento estejam reproduzidas em todas as cópias, e que você não acres-
cente nenhuma outra condição, quaisquer que sejam, às desta Licença.
Você não pode usar medidas técnicas para obstruir ou controlar a leitura ou confecção de
cópias subsequentes das cópias que você fizer ou distribuir. Entretanto, você pode aceitar com-
pensação em troca de cópias. Se você distribuir uma quantidade grande o suficiente de cópias,
você também precisa respeitar as condições da seção 3.
Você também pode emprestar cópias, sob as mesmas condições colocadas acima, e também
pode exibir cópias publicamente.
FAZENDO CÓPIAS EM QUANTIDADE
Se você publicar cópias do Documento em número maior que 100, e a nota de licença do
Documento obrigar Textos de Capa, você precisará incluir as cópias em capas que tragam, clara
e legivelmente, todos esses Textos de Capa: Textos de Capa da Frente na capa da frente, e
Textos da Quarta Capa na capa de trás. Ambas as capas também precisam identificar clara e
legivelmente você como o editor dessas cópias. A capa da frente precisa apresentar o título com-
pleto com todas as palavras do título igualmente proeminentes e visíveis. Você pode adicionar
outros materiais às capas. Fazer cópias com modificações limitadas às capas, tanto quanto estas
preservem o título do documento e satisfaçam a essas condições, pode ser tratado como cópia
exata em outros aspectos.
Se os textos requeridos em qualquer das capas for muito volumoso para caber de forma
legível, você deve colocar os primeiros (tantos quantos couberem de forma razoável) na capa
verdadeira, e continuar os outros nas páginas adjacentes.
Se você publicar ou distribuir cópias Opacas do Documento em número maior que 100, você
precisa ou incluir uma cópia Transparente que possa ser lida automaticamente com cada cópia
Opaca, ou informar, em ou com, cada cópia Opaca a localização de uma cópia Transparente
completa do Documento acessível publicamente em uma rede de computadores, à qual o público
usuário de redes tenha acesso a download gratuito e anônimo utilizando padrões públicos de
protocolos de rede. Se você utilizar o segundo método, você precisará tomar cuidados razoavel-
mente prudentes, quando iniciar a distribuição de cópias Opacas em quantidade, para assegurar
que esta cópia Transparente vai permanecer acessível desta forma na localização especificada
por pelo menos um ano depois da última vez em que você distribuir uma cópia Opaca (direta-
mente ou através de seus agentes ou distribuidores) daquela edição para o público.
É pedido, mas não é obrigatório, que você contate os autores do Documento bem antes de
redistribuir qualquer grande número de cópias, para lhes dar uma oportunidade de prover você
com uma versão atualizada do Documento.
13

MODIFICAÇÕES
Você pode copiar e distribuir uma Versão Modificada do Documento sob as condições das se-
ções 2 e 3 acima, desde que você publique a Versão Modificada estritamente sob esta Licença,
com a Versão Modificada tomando o papel do Documento, de forma a licenciar a distribuição
e modificação da Versão Modificada para quem quer que possua uma cópia da mesma. Além
disso, você precisa fazer o seguinte na versão modificada:
A. Usar na Página de Título (e nas capas, se houver alguma) um título distinto daquele do Do-
cumento, e daqueles de versões anteriores (que deveriam, se houvesse algum, estarem listados
na seção "Histórico do Documento"). Você pode usar o mesmo título de uma versão anterior se
o editor original daquela versão lhe der permissão;
B. Listar na Página de Título, como autores, uma ou mais das pessoas ou entidades responsá-
veis pela autoria das modificações na Versão Modificada, conjuntamente com pelo menos cinco
dos autores principais do Documento (todos os seus autores principais, se ele tiver menos que
cinco);
C. Colocar na Página de Título o nome do editor da Versão Modificada, como o editor;
D. Preservar todas as notas de copyright do Documento;
E. Adicionar uma nota de copyright apropriada para suas próprias modificações adjacente às
outras notas de copyright;
F. Incluir, imediatamente depois das notas de copyright, uma nota de licença dando ao público
o direito de usar a Versão Modificada sob os termos desta Licença, na forma mostrada no tópico
abaixo;
G. Preservar nessa nota de licença as listas completas das Seções Invariantes e os Textos de
Capa requeridos dados na nota de licença do Documento;
H. Incluir uma cópia inalterada desta Licença;
I. Preservar a seção entitulada "Histórico", e seu título, e adicionar à mesma um item dizendo
pelo menos o título, ano, novos autores e editor da Versão Modificada como dados na Página de
Título. Se não houver uma sessão denominada "Histórico"no Documento, criar uma dizendo o
título, ano, autores, e editor do Documento como dados em sua Página de Título, então adicionar
um item descrevendo a Versão Modificada, tal como descrito na sentença anterior;
J. Preservar o endereço de rede, se algum, dado no Documento para acesso público a uma
cópia Transparente do Documento, e da mesma forma, as localizações de rede dadas no Docu-
mento para as versões anteriores em que ele foi baseado. Elas podem ser colocadas na seção
"Histórico". Você pode omitir uma localização na rede para um trabalho que tenha sido publicado
pelo menos quatro anos antes do Documento, ou se o editor original da versão a que ela se refira
der sua permissão;
K. Em qualquer seção entitulada "Agradecimentos"ou "Dedicatórias", preservar o título da
14

seção e preservar a seção em toda substância e fim de cada um dos agradecimentos de contri-
buidores e/ou dedicatórias dados;
L. Preservar todas as Seções Invariantes do Documento, inalteradas em seus textos ou em
seus títulos. Números de seção ou equivalentes não são considerados parte dos títulos da seção;
M. Apagar qualquer seção entitulada "Endossos". Tal sessão não pode ser incluída na Versão
Modificada;
N. Não reentitular qualquer seção existente com o título "Endossos"ou com qualquer outro
título dado a uma Seção Invariante.
Se a Versão Modificada incluir novas seções iniciais ou apêndices que se qualifiquem como
Seções Secundárias e não contenham nenhum material copiado do Documento, você pode optar
por designar alguma ou todas aquelas seções como invariantes. Para fazer isso, adicione seus
títulos à lista de Seções Invariantes na nota de licença da Versão Modificada. Esses títulos preci-
sam ser diferentes de qualquer outro título de seção.
Você pode adicionar uma seção entitulada "Endossos", desde que ela não contenha qual-
quer coisa além de endossos da sua Versão Modificada por várias pessoas ou entidades - por
exemplo, declarações de revisores ou de que o texto foi aprovado por uma organização como a
definição oficial de um padrão.
Você pode adicionar uma passagem de até cinco palavras como um Texto de Capa da Frente
, e uma passagem de até 25 palavras como um Texto de Quarta Capa, ao final da lista de Textos
de Capa na Versão Modificada. Somente uma passagem de Texto da Capa da Frente e uma de
Texto da Quarta Capa podem ser adicionados por (ou por acordos feitos por) qualquer entidade.
Se o Documento já incluir um texto de capa para a mesma capa, adicionado previamente por
você ou por acordo feito com alguma entidade para a qual você esteja agindo, você não pode
adicionar um outro; mas você pode trocar o antigo, com permissão explícita do editor anterior que
adicionou a passagem antiga.
O(s) autor(es) e editor(es) do Documento não dão permissão por esta Licença para que seus
nomes sejam usados para publicidade ou para assegurar ou implicar endossamento de qualquer
Versão Modificada.
COMBINANDO DOCUMENTOS
Você pode combinar o Documento com outros documentos publicados sob esta Licença, sob
os termos definidos na seção 4 acima para versões modificadas, desde que você inclua na com-
binação todas as Seções Invariantes de todos os documentos originais, sem modificações, e liste
todas elas como Seções Invariantes de seu trabalho combinado em sua nota de licença.
O trabalho combinado precisa conter apenas uma cópia desta Licença, e Seções Invariantes
Idênticas com multiplas ocorrências podem ser substituídas por apenas uma cópia. Se houver
múltiplas Seções Invariantes com o mesmo nome mas com conteúdos distintos, faça o título de
15

cada seção único adicionando ao final do mesmo, em parênteses, o nome do autor ou editor
origianl daquela seção, se for conhecido, ou um número que seja único. Faça o mesmo ajuste
nos títulos de seção na lista de Seções Invariantes nota de licença do trabalho combinado.
Na combinação, você precisa combinar quaisquer seções entituladas "Histórico"dos diver-
sos documentos originais, formando uma seção entitulada "Histórico"; da mesma forma combine
quaisquer seções entituladas "Agradecimentos", ou "Dedicatórias". Você precisa apagar todas as
seções entituladas como "Endosso".
COLETÂNEAS DE DOCUMENTOS
Você pode fazer uma coletânea consitindo do Documento e outros documentos publicados
sob esta Licença, e substituir as cópias individuais desta Licença nos vários documentos com
uma única cópia incluida na coletânea, desde que você siga as regras desta Licença para cópia
exata de cada um dos Documentos em todos os outros aspectos.
Você pode extrair um único documento de tal coletânea, e distribuí-lo individualmente sob
esta Licença, desde que você insira uma cópia desta Licença no documento extraído, e siga esta
Licença em todos os outros aspectos relacionados à cópia exata daquele documento.
AGREGAÇÃO COM TRABALHOS INDEPENDENTES
Uma compilação do Documento ou derivados dele com outros trabalhos ou documentos se-
parados e independentes, em um volume ou mídia de distribuição, não conta como uma Ver-
são Modificada do Documento, desde que nenhum copyright de compilação seja reclamado pela
compilação. Tal compilação é chamada um "agregado", e esta Licença não se aplica aos outros
trabalhos auto-contidos compilados junto com o Documento, só por conta de terem sido assim
compilados, e eles não são trabalhos derivados do Documento.
Se o requerido para o Texto de Capa na seção 3 for aplicável a essas cópias do Documento,
então, se o Documento constituir menos de um quarto de todo o agregado, os Textos de Capa
do Documento podem ser colocados em capas adjacentes ao Documento dentro do agregado.
Senão eles precisarão aparecer nas capas de todo o agregado.
TRADUÇÃO
Tradução é considerada como um tipo de modificação, então você pode distribuir traduções
do Documento sob os termos da seção 4. A substituição de Seções Invariantes por traduções
requer uma permissão especial dos detentores do copyright das mesmas, mas você pode incluir
traduções de algumas ou de todas as Seções Invariantes em adição às versões orignais dessas
Seções Invariantes. Você pode incluir uma tradução desta Licença desde que você também in-
clua a versão original em Inglês desta Licença. No caso de discordância entre a tradução e a
16

versão original em Inglês desta Licença, a versão original em Inglês prevalecerá.
TÉRMINO
Você não pode copiar, modificar, sublicenciar, ou distribuir o Documento exceto como expres-
samente especificado sob esta Licença. Qualquer outra tentativa de copiar, modificar, sublicen-
ciar, ou distribuir o Documento é nula, e resultará automaticamente no término de seus direitos
sob esta Licença. Entretanto, terceiros que tenham recebido cópias, ou direitos de você sob esta
Licença não terão suas licenças terminadas, tanto quanto esses terceiros permaneçam em total
acordo com esta Licença.
REVISÕES FUTURAS DESTA LICENÇA
A Free Software Foundation pode publicar novas versões revisadas da Licença de Documen-
tação Livre GNU de tempos em tempos. Tais novas versões serão similares em espirito à versão
presente, mas podem diferir em detalhes ao abordarem novos porblemas e preocupações. Veja
http://www.gnu.org/copyleft/.
A cada versão da Licença é dado um número de versão distinto. Se o Documento especificar
que uma versão particular desta Licença "ou qualquer versão posterior"se aplica ao mesmo, você
tem a opção de seguir os termos e condições daquela versão específica, ou de qualquer versão
posterior que tenha sido publicada (não como rascunho) pela Free Software Foundation. Se o
Documento não especificar um número de Versão desta Licença, você pode escolher qualquer
versão já publicada (não como rascunho) pela Free Software Foundation.
ADENDO: Como usar esta Licença para seus documentos
Para usar esta Licença num documento que você escreveu, inclua uma cópia desta Licença
no documento e ponha as seguintes notas de copyright e licenças logo após a página de título:
Copyright (c) ANO SEU NOME.
É dada permissão para copiar, distribuir e/ou modificar este documento sob os termos da Licença
de Documentação Livre GNU, Versão 1.1 ou qualquer versão posterior publicada pela Free Soft-
ware Foundation; com as Seções Invariantes sendo LISTE SEUS TÍTULOS, com os Textos da
Capa da Frente sendo LISTE, e com os Textos da Quarta-Capa sendo LISTE. Uma cópia da li-
cença está inclusa na seção entitulada "Licença de Documentação Livre GNU".
Se você não tiver nenhuma Seção Invariante, escreva "sem Seções Invariantes"ao invés de
dizer quais são invariantes. Se você não tiver Textos de Capa da Frente, escreva "sem Textos de
Capa da Frente"ao invés de "com os Textos de Capa da Frente sendo LISTE"; o mesmo para os
Textos da Quarta Capa.
Se o seu documento contiver exemplos não triviais de código de programas, nós recomenda-
mos a publicação desses exemplos em paralelo sob a sua escolha de licença de software livre,
17

tal como a GNU General Public License, para permitir o seu uso em software livre.
18

Capítulo 1
O que é JSP e o que são Servlets
JSP (Java Server Pages) e Servlets são tecnologias desenvolvidas pela Sun Microsystems
orientadas para criar páginas web com programação em Java que sejam executadas do lado do
servidor. JSP é semelhante ao Microsoft Active Server Pages (ASP), porém, por ser baseada
na linguagem Java, tem a vantagem da portabilidade de plataforma, podendo ser executado
em outros Sistemas Operacionais. Já servlets são, basicamente, classes java instanciadas e
executadas junto ao servidor web, atendendo requisições HTTP, como a dos browsers.
Em linhas gerais, JSP permite ao desenvolvedor de sites produzir aplicações que permitam
o acesso a banco de dados, o acesso a arquivos-texto, a captação de informações a partir de
formulários, a captação de informações sobre o visitante e sobre o servidor, o uso de variáveis
e loops entre outros. De um modo geral, permite produzir conteúdos dinâmicos que possam ser
reutilizados.
O curso tem base na distribuição Debian.
20

Capítulo 2
Plano de ensino
2.1 Objetivo
Capacitar o usuário para o uso autônomo dos recursos do JSP e dos Servlets.
2.2 Público Alvo
Em especial usuários do sistema operacional Linux que queiram fazer uso de JSP e dos
Servlets.
2.3 Pré-requisitos
Os usuários deverão ser, necessariamente, indicados por empresas públicas e ter conheci-
mento básico acerca da lógica de programação. Além disso, são necessários conhecimentos em
Java e HTML. Recomendamos o curso: “Java Básico” do CDTC.
2.4 Descrição
O curso será realizado na modalidade Educação a Distância e utilizará a Plataforma Moodle
como ferramenta de aprendizagem. Ele será dividido em tópicos e cada um deles é composto
por um conjunto de atividades (lições, fóruns, glossários, questionários e outros) que deverão ser
executadas de acordo com as instruções fornecidas. O material didático estará disponível on-line
de acordo com as datas pré-estabelecidas em cada tópico. A versão adotada do JDK para uso
do JSP é a JDK 5. Caso possua outra versão instalada, poderão ocorrer poucas diferenças.
Todo o material está no formato de lições, e estará disponível ao longo do curso. As lições
poderão ser acessadas quantas vezes forem necessárias. Aconselhamos a leitura de "Ambien-
tação do Moodle", para que você conheça o produto de Ensino a Distância, evitando diﬁculdades
advindas do "desconhecimento"sobre o mesmo.
Ao ﬁnal de cada semana do curso será disponibilizada a prova referente ao módulo estudado
anteriormente que também conterá perguntas sobre os textos indicados. Utilize o material de
cada semana e os exemplos disponibilizados para se preparar para prova.
21

Os instrutores estarão a sua disposição ao longo de todo curso. Qualquer dúvida deve ser
disponibilizada no fórum ou enviada por e-mail. Diariamente os monitores darão respostas e
esclarecimentos.
2.5 Metodologia
O curso está dividido da seguinte maneira:
2.6 Cronograma
• Lição 1 - Iniciando em JSP e Servlets;
• Lição 2 - Instalações e Configurações;
• Lição 3 - Noções de POO e Comandos Java;
• Lição 4 - TAGS JSP;
• Lição 5 - JSTL e Javabeans;
• Lição 6 - Servlets: Criação e Ciclo;
• Lição 7 - Servlets: API, Request e Response;
• Lição 8 - Usando Cookies e Controlando Sessões;
• Lição 9 - Controle de Erros e MVC;
• Avaliação de Aprendizagem.
As lições contém o conteúdo principal. Elas poderão ser acessadas quantas vezes forem ne-
cessárias, desde que esteja dentro da semana programada. Ao final de uma lição, você receberá
uma nota de acordo com o seu desempenho. Responda com atenção às perguntas de cada li-
ção, pois elas serão consideradas na sua nota final. Caso sua nota numa determinada lição seja
menor do que 6.0, sugerimos que você faça novamente esta lição.
Ao final do curso será disponibilizada a avaliação referente ao curso. Tanto as notas das lições
quanto a da avaliação final serão consideradas para a nota final. Todos os módulos ficarão visí-
veis para que possam ser consultados durante a avaliação final.
Aconselhamos a leitura da "Ambientação do Moodle"para que você conheça a plataforma de En-
sino a Distância, evitando dificuldades advindas do "desconhecimento"sobre a mesma.
Os instrutores estarão a sua disposição ao longo de todo curso. Qualquer dúvida deverá ser
enviada ao fórum. Diariamente os monitores darão respostas e esclarecimentos.
2.7 Programa
O curso de JSP e Servlets oferecerá o seguinte conteúdo:
• Introdução;
• Instalação;
22

• Noções de Java;
• Conteúdo JSP;
• Conteúdo Servlets;
• Cookies e Controle de Sessões;
• JSTL, Erros e MVC.
2.8 Avaliação
Toda a avaliação será feita on-line.
Aspectos a serem considerados na avaliação:
• iniciativa e autonomia no processo de aprendizagem e de produção de conhecimento;
• capacidade de pesquisa e abordagem criativa na solução dos problemas apresentados.
Instrumentos de avaliação:
• participação ativa nas atividades programadas.
• avaliação ao final do curso.
• o participante fará várias avaliações referentes ao conteúdo do curso. Para a aprovação e
obtenção do certificado o participante deverá obter nota final maior ou igual a 6.0 de acordo
com a fórmula abaixo:
• Nota Final = ((ML x 7) + (AF x 3)) / 10 = Média aritmética das lições.
• AF = Avaliações.
2.9 Bibliografia
Site official:
http://java.sun.com/products/jsp/
Outros:
http://www.criarweb.com/artigos/227.php
http://www.crieseuwebsite.com/apostilas/detalhes.php?categoria=JSP&arquivo=93
http://www.caelum.com.br
http://www.mundooo.com.br/
http://www.javafree.org/javabb/viewtopic.jbb?t=9127
http://arquivos.coinfo.cefetpb.edu.br/~fred/pweb/servlets/slides/04-Servlets.pdf
http://www.dpi.ufv.br/~alcione/proginter2001/ApostilaServletJSP.pdf
http://www.mhavila.com.br/topicos/java/tomcat_unix.html
23

Capítulo 3
Iniciando em JSP e Servlets
3.1 Deﬁnições: JSP e Servlets
JSP (Java Server Pages) é uma tecnologia utilizada na criação de aplicações para a web. É
uma linguagem relativamente nova, já que surgiu por volta do ano 2000 como uma estratégia
da Sun MicroSystems para combater linguagens emergentes como o ASP(Active Server Pages),
linguagem de autoria da Microsoft, e o PHP (Hypertext PreProcessor). Por ser baseada na lin-
guagem Java, tem a vantagem da portabilidade de plataforma, o que permite sua execução em
variados sistemas operacionais. Podemos escrever JSP com um editor de texto HTML/XML co-
mum, já que as páginas JSP estão compostas de cógido HTML/XML mesclado com etiquetas
para programar scripts de servidor em sintaxe Java. O motor das páginas JSP está baseado nos
servlets de Java.
Os arquivos JSP têm extensão ’.jsp’ , os quais, dentro das tags HTML, contém o código em
java a executar no servidor. Antes que os arquivos sejam funcionais, o motor JSP realiza uma
fase de tradução dessa página em um servlet, implementado em um arquivo class (Byte codes
de Java).
24

Servlets são componentes que disponibilizam ao programador java uma interface para o ser-
vidor web, através de uma API. Servlets ampliam a funcionalidade de servidores baseados em
requisições/respostas. Uma página criada com a tecnologia JSP, após instalada em um servidor
de aplicação compatível com a tecnologia Java EE, é transformada em um Servlet. Para ser
executado um servlet necessita de um container Web, isto é, um servidor onde são instaladas
servlets para tratar as requisições que o servidor receber. Existem vários containers web, mas
um dos mais usados é o Tomcat, por vários motivos entre eles por não ser pago e por ser o
container de servlets usado na referência oﬁcial de implementação de JSP.
Para tirar um bom proveito de JSP e de Servlets são necessários conhecimentos em HTML e
java, já que são as duas bases sobre as quais JSP é moldado. Parte lógica do JSP envolve Java
Beans, Objetos JDBC, Enterprise Java Beans ( EJB ) entre outros componentes que interagem
com a plataforma Java. Portanto, alertamos aqueles que pretendem desenvolver uma aplicação
mais soﬁsticada que tenham, além de conhecimentos de HTML, que entendam de programação
em Java. Para os que ainda não estão familiarizados com o java, recomendamos o curso de
“Java Básico” do CDTC.
3.2 Comparação de Java Server Pages com Servlets
JSP e Servlets são bem parecidos, já que todo JSP é compilado em forma de Servlet. Os dois
são processados do lado do servidor e retornam apenas conteúdo HTML ao cliente. JSPs geram
essencialmente conteúdo HTML enquanto os servlets são usados para controle da aplicação,
mas o programador pode opcionalmente inverter esses papéis.
A principal diferença entre eles é que em JSP escreve-se Java no HTML e em servlets
escreve-se HMTL dentro do código java. Sabemos que servlets são classes java que forne-
cem serviço especial de ’server-side’. Basicamente, o que acontece é que é mais difícil escrever
código HTML em Servlets já que neles são necessárias várias linhas de código de impressão
(println) para gerar HTML, o que não acontece em JSPs.
25

3.3 Aplicações Web
Estrutura Usual de APLICAÇÕES WEB Desenvolvidas Usando o Java
Aplicações web são aplicações que executam no servidor e que consistem de compontentes
como JSP, Servlets, HTML, etc. Uma das principais características de uma aplicação web é seu
relacionamento com o ServletContext. Um ServletContext serve basicamente para armazenar
informação relativa à aplicação como um todo. Em particular, o ServletContext é usado para:
• conter parâmetros de inicialização da aplicação;
• armazenar recursos associados à aplicação. Uma conexão de Banco de Dados um exem-
plo;
• armazenar qualquer atributo da aplicação como objeto;
• fornecer acesso à funcionalidade de logging.
Cada aplicação tem somente um único ServletContext. Este relacionamento é controlado pelo
container de servlet. Na grande maioria dos casos, o desenvolvimento dessas aplicações web
que usam o java como padrão procura seguir os passos seguintes:
1 - desenvolvimento e teste dos diversos Servlets, JSPs, necessários ao projeto da aplicação
web;
2 - escrita do ’descritor de aplicação’ (Web Application Deployment Descriptor). Geralmente é
um arquivo .xml e é usado pelo container ou servidor para a instalação da aplicação. Descreve-se
nele as variáveis de ambiente a serem usadas, os componentes e os requisitos de segurança.
Tem seu nome usual como ’web.xml’ e é localizado no diretório WEB-INF. Nesse arquivo, pode-
mos encontrar informações referentes a:
• Parâmetros de Inicialização do ServletContext;
• Conﬁguração de Session;
• Deﬁnições de Servlet/JSP;
• Mappings de Servlet/JSP;
• Páginas de Erros;
• Segurança.
Exemplo de ’web.xml’:
<web-app>
<display-name>NomeAplicacao</display-name>
<session-timeout>30</session-timeout>
<servlet>
<servlet-name>Servlet1</servlet-name>
<servlet-class>com.nome.ServletNome1</servlet-class>
<load-on-startup>1</load-on-startup>
26

<init-param>
<param-name>name</param-name>
<param-value>value</param-value>
</init-param>
</servlet>
</web-app>
OBS: A criação de um web.xml será explicada detalhadamente adiante.
3 - compilação de todos os componentes web e das classes referenciadas por eles. Existem
algumas ferramentas para esse propósito, como o ’Ant’. O Apache Ant é uma ferramenta escrita
em java (está disponível em http://ant.apache.org/) que permite criar scripts para a realização
automática de tarefas como a compilação de programas java. Os scripts são definidos em XML;
4 - empacotamento da aplicação web. As aplicações web primeiramente são empacotadas
em um arquivo com a extensão ’.war’ (Web application Archive) e são então instaladas em um
container ou servidor. Embora esse processo seja opcional para a posterior instalação no contai-
ner , ele é recomendado, pois facilita o processo da instalação. Novamente o uso da ferramenta
Ant é muito útil para esta fase do desenvolvimento. A ferramenta JAR do JDK também pode criar
o WAR file com o seguinte comando:
jar cvf nome.war
Usando o Elipse, por exemplo, basta usar SeuProjeto / Exportar / WAR file.
OBS: JAR ou Java ARchive é um arquivo compactado usado para distribuir um conjunto de
classes Java. É usado para armazenar classes compiladas e metadados associados que podem
constituir um programa.Arquivos jar podem ser criados e extraídos usando o utilitário "jar"da JDK;
5 - instalação no container ou servidor. Já empacotada em ’.war’, somente é necessário copiar
o arquivo para o diretório ’webapps’ do Tomcat ou o diretório ’autodeploy’ do domínio desejado
no Servidor de Aplicações da Sun Microsystems. O servidor, então, fará a instalação automática;
6 - abrir o browser e apontar para a URL da aplicação, que normalmente é algo como:
http://localhost:8080/dir_da_aplicação.
A estrutura de diretórios de uma aplicação web é normalmente assim:
27

DirRaiz/ diretório raíz da aplicação web
DirRaiz/index.html documento HTML
DirRaiz/index.jsp documento JSP
DirRaiz/imagens diretório onde se localizam as imagens da página
DirRaiz/META-INF/ diretório opcional, usado para se deﬁnir extensões
e outras informações relacionadas aos dados do pacote.
DirRaiz/WEB-INF/ diretório que contém os recursos relacionados
à aplicação como o web aplication deployment.
DirRaiz/WEB-INF/classes diretório que contém Servlets, JavaBens e demais
classes Java,todos compilados.
DirRaiz/WEB-INF/lib diretório que contém JAR ﬁles que a aplicação web tem
dependência, como um JAR de drive JDBC.
DirRaiz/WEB-INF/web.xml descritor de instalação ’web.xml’.
28

Capítulo 4
Instalações e Configurações
4.1 Instalações Necessárias
A primeira coisa a se fazer é instalar um servidor (container) JSP. Existem vários contai-
ners, dentre os quais podemos citar: JBoss, Weblogic e WebSphere. Neste curso escolhemos
e ensinaremos a configurar o Tomcat, do projeto Jakarta (http://tomcat.apache.org). Como ele
é inteiramente escrito em Java, necessita de uma Java Virtual Machine (JVM) - Máquina Virtual
Java - para ser executado. Ele é oficialmente endossado pela Sun como a Implementação de
Referência (RI) para as tecnologias Java Servlet e JavaServer Pages (JSP).
O Tomcat é um servidor de aplicações Java para web. É distribuído como software livre e
desenvolvido como código aberto dentro do conceituado projeto Apache Jakarta. O Tomcat é
robusto e eficiente o suficiente para ser utilizado mesmo em um ambiente de produção.
Para a instalação do Tomcat em ambiente de desenvolvimento - onde serão desenvolvidas
classes Java em geral, incluindo Servlets e páginas JSP -, deve-se utilizar o JDK (Java Develop-
ment Kit) completo. Se você não tiver ainda o JDK instalado, faça o download através do site da
Empresa Sun. (http://java.sun.com).
4.2 Estrutura de Diretórios do Tomcat
É importante que saibamos como é a estrutura de diretórios do Tomcat pois isto ajuda a ter
maior controle sobre as aplicações, além de nos fazer entender melhor containers semelhantes
a ele. A estrutura básica é a seguinte:
29

/bin Diretório que contém os binários executáveis. No caso do Linux
é util pois contém os arquivos ’.sh’ para a execução do servidor.
/common Diretório que contém classes disponíveis tanto para funcionamento
do servidor quanto às aplicações web instaladas. Geralmente contém os
diretórios /classe e /lib nos quais se localizam classes disponíveis não
só para o Tomcat quanto para as aplicações rodando no servidor. Classes
compiladas devem ser colocadas no ’/classes’ e arquivos JAR devem ser
colocados no ’/lib’.
/conf Diretório que contém os arquivos de configuração. Os mais importantes são
’server.xml’ - arquivo de configuração principal do Tomcat, que é usado para
configurar logs, conexões com outros servidores, a porta e host na qual o
servidor está sendo executado e o local dos arquivos de cada aplicação
web - ’tomcat-users.xml’ - base de dados padrão para a autenticação de
usuários. - e o ’web.xml’ que já foi citado.
/logs Diretório que contém os arquivos de logs.
/server Diretório que contém novamente subdiretórios : classes, lib e webapps.
Porém, os desta pasta não são acessíveis a outras aplicações. Webapps
é o local das aplicações de gerenciamento do Tomcat: admin e manager.
/shared Diretório que contém novamente os dois subdiretórios: classes e lib com a
diferença que classes nestes subdiretórios estarão disponíveis a todas as
aplicações web, exceto ao Tomcat.
/webapps Diretório para a instalação de aplicações web no Tomcat. Sua estrutura já
foi explicada na Lição anterior.
/work Diretório onde o Tomcat armazena o código da página JSP depois que este é
convertido em um Servlet.
Instalação
A instalação do Tomcat é muito simples e consiste, essencialmente, em descompactar o pa-
cote de arquivos no local desejado. Os comandos de instalação procuram utilizar máscaras de
substituição ? e * nos nomes de arquivo para se manterem genéricos em relação à versão espe-
cífica do Tomcat, já que os procedimentos são idênticos para toda versão.
Os procedimentos de instalação no curso pressupõem como convenção o caminho /opt/ como
diretório base para a instalação. Os demais exemplos citados neste tutorial se referem a este ca-
minho. Em algumas plataformas, pode-se preferir usar /usr/local/ ou mesmo outro local persona-
lizado, como por exemplo /web. Como não há padrão rígido para esta organização, se você optar
por outra localização, basta lembrar de alterar as referências ao caminho de instalação conforme
30

necessário.
No nosso caso, os seguintes procedimentos foram tomados:
1 - criação de um diretório novo chamado ’install’ em /usr/local/
$ cd /opt
$ mkdir install
2 - mover o arquivo de instalação ( no caso o ’apache-tomcat.?.?.*.tar.gz’
ou ’apache-tomcat.?.?.*.zip’ para a pasta /opt/install.
$ mv apache-tomcat.?.?.*.tar.gz /opt/install
3 - o comando script cria um arquivo de registro tomcat-install.log com toda a saída apresen-
tada na tela durante a instalação (até que seja finalizado com o comando exit):
$ script /opt/install/tomcat-install.log
OBS.: Se precisar conferir depois em detalhes o que aconteceu durante a instalação,
em busca de algum problema consulte o arquivo install/tomcat-install.log gerado.
4 - o GNU tar tem a opção z que já descompacta o formato gzip. As outras opções xvf são
respectivamente para extrair, exibir mais informações e especificar o nome do arquivo:
$ tar -xzvf /opt/install/apache-tomcat-?.?.*.tar.gz
* Se for usado o pacote ZIP, o comando passa a ser:
$ unzip /opt/install/apache-tomcat-?.?.*.zip
5 - recomendável também criar um link simbólico sem a versão, para facilitar a referência em
scripts administrativos independentes da versão atual:
$ ln -s apache-tomcat-?.?.?? tomcat
6 - apenas se tiver sido usado o pacote ZIP, é necessário este passo adicional: verificar e
atribuir permissão de execução aos scripts do Tomcat:
$ cd tomcat/bin
$ ls -l *.sh
$ chmod +x *.sh
$ cd ../..
7 - como root, defina as variáveis de ambiente JAVA_HOME e CATALINA_HOME, para apon-
tar o diretório principal da instalação do Java SDK e do Tomcat, respectivamente:
- entre no arquivo .bashrc com algum editor de texto:
31

$ vim /home/[nome_de_usuario]/.bashrc
8 - adicione as linhas abaixo no ﬁm do arquivo ’.bashrc’ . Onde citamos ?jdk1.5.0?, trata-se
da versão do Java já instalado na máquina. Novamente adapte o guia à sua versão do JDK:
# java home and path
JAVA_HOME=/[caminho_do_diretorio_do_java]/jdk1.5.0; export JAVA_HOME
export PATH=$PATH:/[caminho_do_diretorio_do_java/jdk1.5.0/bin/
# catalina home
CATALINA_HOME=/opt/install/[diretório_do_tomcat]; export JAVA_HOME
- Salve suas alterações e saia do diretório root com o comando:
$ exit
11 - execute o script desejado para iniciar e parar o tomcat:
Iniciar:
$ /[diretório_do_tomcat]/bin/startup.sh
ou
$ /[diretório_do_tomcat]/bin/catalina.sh start
Parar:
$ /[diretório_do_tomcat]/bin/shutdown.sh
ou
$ /[diretório_do_tomcat]/bin/catalina.sh stop
12 - para testar se o Tomcat está rodando corretamente após iniciado(startup.sh), abra o
browser e vá para o endereço:
http://localhost:8080/
32

Capítulo 5
Fundamentos da Orientação a Objeto
Apesar de recomendar o prévio conhecimento de java para o curso de JSP e Servlets, é ne-
cessário relembrarmos os conceitos fundamentais da programação java e suas derivadas, con-
seqüentemente o JSP, que são conceitos da orientação a objeto (comumente conhecida como
Programação Orientada a Objeto ou POO). São, apesar de fundamentais, conceitos amplos que
requerem prática para que possam ser plenamente compreendidos.
5.1 Classes, Objetos e Métodos
Classe é um aglomerado de métodos - funções e procedimentos com os quais acessamos e
usamos os objetos, realizando tarefas específicas -, e de variáveis, que definem o comportamento
de um objeto que poderá vir a existir se a classe for solicitada para tal.
Um objeto é uma entidade do mundo real que possui uma identidade. Podem ser entidades
concretas ou conceituais. Podemos citar como exemplos de objetos: uma conta corrente, clientes,
agências, arquivos no computador, bicicletas, lojas etc. Em termos de programação, pode-se
definir objeto como o resultado da ação construtora de uma classe.
Todo objeto é “fabricado” em uma classe, sendo por isso denominado instância da classe.
Além disso, tem outras características: a estrutura de objetos de uma certa classe é descrita
por meio de atributos; objetos de uma mesma classe têm um mesmo comportamento que são
representados pelo conjunto de operações que podem ser executadas sobre eles. O método de
construção de objetos com a mesma "genética"da classe é chamado de método construtor.
5.2 Conceitos Importantes
Alguns outros conceitos importantes:
Encapsulamento: imprescindível ao entendimento de POO e ao aprendizado java, já que é
indispensável para contribuir com a diminuição dos malefícios causados pela interferência externa
sobre os dados. É uma técnica que consiste em ocultar no objeto algumas de suas variáveis (ou
33

campos) e alguns de seus métodos. É importantíssimo na medida em que deixa o programa
robusto, impedindo o acesso a certas partes de seu funcionamento.
Herança: outro conceito importante na POO é o conceito de herança, que significa que toda
classe definida como uma subclasse de outra receberá automaticamente todo o conteúdo da
classe-mãe. Tomamos como exemplo uma classe ’Pessoa’, onde possui como propriedades:
nome, endereço, telefone, cpf e etc. Incluímos a classe ’Pessoa’ em uma classe ’Funcionário’,
dessa forma aproveitamos todas as propriedades de ’Pessoa’ e incluímos as propriedades espe-
cíficas de ’Funcionário’, como: data de admissão, cargo, salário e etc.
Polimorfismo: um conceito mais difícil de ser entendido, porém não menos importante é o
conceito de polimorfismo. Essa dificuldade decorre da amplitude desse conceito e de significados
em POO. Suas variadas definições são:
.overloading: designa um tipo de polimorfismo em que podemos utilizar um nome igual para
designar métodos diferentes que terão lista de parâmetros também diferentes. Isto tanto em
número de parâmetros quanto em tipo; .os objetos de uma classe-mãe podem ser redefinidos por
objetos das suas sub-classes; .variáveis podem assumir tipos diferentes ao longo da execução.
Visibilidade: através dos indicadores ’public’ e ’private’ algumas classes e métodos podem
ser visíveis ou não. Os métodos e propriedades públicas serão a interface do objeto com o
usuário.
Abstração: em termos de desenvolvimento, abstração significa concentrar-se no que um
objeto é e faz antes de se decidir como ele será implementado. Significa representar as caracte-
rísticas essenciais de um tipo de dado sem incluir o mecanismo que concretiza a funcionalidade.
A abstração é fundamental para conseguir uma boa modularização, que é uma técnica que tem a
estratégia de ’dividir para conquistar’, ou seja, resolver um grande problema dividindo-o em vários
problemas menores.
5.3 Variáveis
Variáveis de Classe: são variáveis declaradas no escopo de uma classe, mas de tal modo
que não precisam de objetos para serem referenciadas, bastando a definição da classe na qual
são declaradas.
Variáveis de Instância: variáveis declaradas no escopo de uma classe e definem os atributos
que cada objeto da classe possui.
Variáveis Paramétricas: declaradas como parâmetros de métodos, construtores e manipula-
dores de exceções.
34

5.4 Modificadores
No caso da linguagem java, existem uma série de modificadores de métodos, classes e atri-
butos. Mostraremos os principais e mais usados :
• public: permite acesso total em uma classe, em um método ou sobre um atributo;
• private: não é aplicável a classes, mas é acessado pela classe em métodos e atributos;
• protected: modificador que não é aplicável a classes, mas é acessado pelo pacote em
métodos e atributos;
• final: numa classe indica que é sem herança, não pode ser sobrescrito em um método e
indica que um atributo é constante;
• static: não aplicável a classes, e dá acesso a métodos e atributos somente referenciando
a classe;
• native: aplicável somente a métodos para indicar código nativo;
• synchonized: aplicável somente a métodos para indicar não acesso simultâneo.
Exemplo de uso dos modificadores:
public static void FazConta();
This e Super
Palavras-chave aplicadas a métodos não estáticos, ou seja, de instância. This é utilizada para
referenciar variáveis ou métodos da instância atual e o super é utilizada para associar a métodos
da classe ’mãe’.
5.5 Pacotes (Packages):
Conjunto organizado de classes e demais arquivos que estão relacionados através de um pro-
pósito comum ou atuam com dependências entre si. São muito úteis e necessários na medida em
que são usados para localizar o código da classe de forma eficiente. Para utilizá-los, simplismente
precedemos diretivas importi (importar) ao nome e caminho do pacote dessa maneira:
import nomedopacote.nomedosubpacote.NomeDaClasse;
Exemplo:
import java.io.IOException;
OBS.: se necessário o uso de mais de uma classe do mesmo pacote podemos referenciar
com o uso de ’*’ dessa maneira:
import java.lang.*;
35

5.6 Uma Página em JSP
Já dissemos que uma página escrita em JSP é baseada no HTML padrão. A maior parte do
código de uma página JSP consiste em template text. O template text é similar ao HTML e é
passado ao browser do cliente por um servlet criado para manusear a página. Logo, para criar
uma aplicação JSP podemos incluir tags JSP em uma página html previamente criada (normal-
mente começam com ’<%’ e terminam com ’%>’) e salvar o arquivo com extensão ’.jsp’ ao invés
de ’.html’.
Basta agora abrir a página em um browser qualquer. É certo que o resultado nesse caso
será o mesmo que em uma página html, mas levará mais tempo para abri-la em JSP. Mas so-
mente da primeira vez. Se tentar carregá-la novamente, carregará normalmente. Isso acontece
porque o código da página, numa primeira vez, é transformado em um arquivo Java, compilado
e executado. Logo, a não ser que o código seja alterado normalmente, a página será carregada
imediatamente numa segunda chamada.
A partir dessa parte faremos um rápido resumo para relembrar a sintaxe dos comandos con-
dicionais e loops do java.
5.7 Condicionais
As condicionais são usadas quando o programador precisa que algum código seja executado,
se uma condição for verdadeira, ou outra seja executada se a primeira condição for falsa, e assim
por diante.
Comandos IF/ELSE
Um bloco if é formado primeiramente com o próprio ’if’ e seguido por um teste booleano e
uma instrução ou um bloco de instruções que precisam ser executadas caso o teste booleano
seja verdadeiro. O ’else’ pode ser usado caso o programador queira que o programa execute o
bloco de instruções que o segue, caso o teste booleano do ’if’ não seja verdadeiro. Exemplo:
<html>
<body>
<%
int valor = -10;
if(valor < 0){
out.println("Valor absoluto de" + valor + " = " + -valor);
}
else{
out.println("Valor absoluto de" + valor + " = " + valor);
}
%>
</body>
</html>
36

Comando SWITCH
O comando switch é usado em situações em que apenas uma entre as condições sendo
testadas assume o valor true num mesmo momento. Se a expressão tem valor coincidente no
switch, a instrução após ele é executada. Caso contrário, a instrução em default é executada. A
sintaxe é a seguinte:
switch(expressão) {
case (constante 1):
(comando 1)
break;
case (constante 2):
(comando 2)
break;
.
.
.
case (constante n):
(comando n)
break;
default:
(comando)
}
Exemplo:
<html>
<body>
<%
int a = 1;
char op = '+';
switch(a) {
case 1:
out.println("case 1: op="+op);
break;
case 2:
out.println("case 2: op="+op);
break;
case 3:
out.println("case 3"+op);
break;
default:
out.println("default: op nao esta no limite 1..3");
}
%>
</body>
</html>
37

5.8 Repetição(loop)
Tratatemos nessa seção sobre as rotinas de repetição de java, que logicamente podem ser
usadas em JSP.
FOR
• repete uma instrução determinado número de vezes até que alguma condição seja satis-
feita;
• forma básica:
for(inicialização;condição;incremento){
código
}
Exemplo:
<html>
<body>
<%
for(int i=0;i<10; i++){
out.println("Dessa vez, i = " + i + "<br />");
}
%>
</body>
</html>
WHILE
• repete uma instrução até que alguma condição seja verdadeira. Primeiro testa a condição
e depois entra no loop;
• forma básica:
while(condição){
código
}
Exemplo:
<html>
<body>
<%
int i = 0;
while(i < 10){
out.println("Dessa vez, i = " + i + "<br />");
i++;
}
%>
</body>
</html>
38

DO...WHILE
• é parecido com um while, só que repete uma instrução até que alguma condição seja falsa.
Primeiro entra no loop e depois checa a condição;
• forma básica:
do{
código
}while(condição);
Exemplo:
<html>
<body>
<%
int i = 0;
do { %>
<font size=<%=i%>>
Olá Mundo
Fonte: <%= i %>
</font><br>
<% i++;
}while(i<=5); %>
</body>
</html>
Obs.: Se por acaso for necessário que o programa saia da rotina de repetição antes do seu
término usual, podemos usar a palavra-chave break, que para imediatamente a execução do loop
e continua no comando seguinte a ele. Já se o programador desejar parar apenas a execução de
uma interação e continuar o loop na seguinte, ele pode usar a palavra-chave continue.
39

Capítulo 6
TAGS JSP
6.1 TAGS - Expressões, Scriptlets e Declarações
Existem 5(cinco) tipos diferenciados de tags em JSP. São elas: Expressões, Scriptlets, Decla-
rações, Diretivas, e Comentários.
Expressões
As expressões são trechos avaliados (em tempo de execução, quando a página é requisitada
pelo browser), convertidas em String e colocadas na página enviada. Têm forma geral:
<%= expressão %>
Exemplos de Expressões:
<%= request.getMethod() %>
<%= new java.util.date() %>
<%= x*y*z %>
<%= Math.sqrt(49) %>
Obs.: As expressões não aceitam ponto-e-vírgula.
Scriptlets
Scriptlets é como são ostrechos de código JSP dentro de páginas HTML. São úteis quando
não é necessário mais de um comando Java ou quando o resultado da computação não é para
ser colocado na página de resposta.
<% Código java %>
Exemplo de Scriptlet:
<html>
<body>
<% out.println( "Validando a data" );
java.util.Date date = new java.util.Date();
%>
40

Hello! The time is now:
<%
out.println(String.valueOf(date));
%>
</body>
</html>
Obs.:
• 1. Todo código HTML estático antes e após um scriptlet é transformado em comandos de
saída (out). Assim, não é necessário abranger os códigos estáticos, além do que blocos de
controle abertos afetam o código HTML envolvido por scriptlets. Exemplo:
Inserir Numero
<% if (Math.random() < .4) { %>
Número correto!
<% } else { %>
Tente novamente
<% } %>
que produz:
out.println("Inserir Numero")
if (Math.random() < .4) {
out.println("Número Correto!")
} else {
out.println("Tente Novamente")
}
• 2. Scriptlets são considerados uma péssima prática de programação pois deixam o código
sujo dificultando a legibilidade e possibilitam a execução de tarefas que não deveriam ser
efetuadas na camada de aprensentação, como por exemplo, acessar o banco de dados,
executar regras de negócio, modificar o fluxo de navegação e etc.
• 3 Quando se está usando o padrão MVC (melhor explicado adiante), deve-se sempre pres-
tar atenção na regra que diz que a camada View(JSP) , deve ser usada apenas para apre-
sentação dos dados da aplicação.
• 4. Scriptlets exigem ponto-e-vírgula ao final de sentenças.
Declarações
Declarações em JSP são alocações de espaços na memória através de definições das variá-
veis e métodos que serão inseridos no corpo do servlet, e serão então referenciados através de
outros elementos de criação de scriptlets. Por não gerarem saída nenhuma, as declarações são
usadas em combinações com expressões e scriptlets. Em JSP são feitas dessa maneira:
<%! Código java %>
41

Deve-se sempre declarar os métodos e as variáveis antes de usá-los. O escopo é geralmente
o arquivo JSP, mas pode ser expandido se houver outros arquivos relacionados com uma diretiva
include. Neste caso se expandirá para o cover do arquivo incluído.
Exemplos de declarações:
<%! int c = 30; %>
<%! String [] pessoas = {?Pedro?,?Jose?,?Maria?}; %>
<%! private int num=0; %>
<%! Metodo a = new Metodo(5.0); %>
<%! double d,e; int f ;%>
Declaradas dessa maneira, são variáveis de instância. Já as declaradas dentro de scriptlets
são variáveis locais ao método _jspService.
Obs.: Cada declaração deve ser separada por ponto-e-vírgula ou ﬁnalizada.
6.2 TAGS - Diretivas e Comentários - e Ações
Diretivas
Diretivas são mensagens incluídas no html que passam informações para o JSP container.
Não enviam nada para a página, mas são importantes pois informam o servidor web coisas
como: a linguagem usada no documento, que no caso é o java, importa os pacotes necessários
ao uso, etc.
1. Diretiva PAGE
A diretiva page possui onze atributos opcionais que fornecem processamento de informações
especiais ao motor JSP. Seu formato padrão é:
<%@ Diretiva atributo1="valor1" atributo2="valor2" ... atributoN="valorN" %>
Exemplo de diretiva page:
<%@ page language="java" import="java.util.*" %>
Apesar de serem opcionais por já possuírem um valor default, aqui listaremos os atributos
mais usados na diretiva page:
• import - especiﬁca o pacote a ser importado. Único atributo que pode ser usado mais de
uma vez. Ex:
<%@ page import="java.util.*" %>
• isThreadSafe - indica se o servlet será executado no modo SingleThread. O valor default é
true. Ex:
<%@ page isThreadSafe="true|false" %>
42

• session - indica se as informações da sessão http estarão disponíveis ou não para a página.
O valor default é true. Ex:
<%@ page session="true|false" %>
• buffer - especifica o tamanho do buffer do JSPWriter out. o Default é definido pelo servidor.
Ex:
<%@ page buffer="sizekb|none" %>
• autoFlush - indica se o buffer deve ser esvaziado quando cheio. O default é true. Ex:
<%@ page autoFlush="true|false" %>
• ContentType - indica o tipo MIME da página de resposta. Deve ser colocado no início do
arquivo. Ex:
<%@ page ContentType="text/html;charset=ISO-8859-1" %>
• extends - define se a subclasse do servlet deve ser gerada. O default é javax.servlet.HttpServlet.
Ex:
<%@ page extends="package.class" %>
• info - informação sobre o servlet que pode ser recuperada pelo método Servlet.getServletInfo().
o defalut é uma string vazia. Ex:
<%@ page info="texto" %>
• errorPage - mostra a página a ser exibida no caso de algum erro não tratado no código. Ex:
<%@ page errorPage="url" %>
• isErrorPage - indica se a página é de erro. Logicamente o default é false. Ex:
<%@ page isErrorPage="true|false" %>
• language - especifica a linguagem usada. No caso o java. Ex:
<%@ page language="java" %>
43

2. Diretiva INCLUDE
A diretiva include é usada, por exemplo, quando se quer inserir um texto de outro arquivo
no local indicado no arquivo JSP atual. Essa diretiva divide conteúdos em blocos de construção
separados. É bom saber que ela trata um arquivo incluído como estático.
Exemplo de diretiva include:
<%@ include file="arquivo.txt" %>
3. Diretiva TAGLIB
A diretiva Taglib é uma coleção de tags customizadas que podem ser usadas pela página.
Tags customizadas permitem aos desenvolvedores esconder complexos códigos ’server-side’dos
web-designers. Possui dois atributos:
• uri : Uniform Resource Identifier (URI) que identifica o arquivo TLD que descreve as tags
associadas com o prefixo dado. Este atributo pode ser definido como uma URL:
<%@ taglib uri='http://java.sun.com/jstl/core' prefix='c' %>
ou como um caminho:
<%@ taglib uri="WEB-INF/HelloWorld.tld" prefix="t" %>
• prefix : é o prefixo usado para identificar a biblioteca. No caso anterior:
<t:reservar />
OBS.: Os prefixos: jsp, jspx, java, javax, servlet, sun, e sunw não podem ser usados, pois são
reservados pela Sun Microsystems.
Exemplo de diretiva Taglib com sua uri e prefixo:
<%@ taglib uri = ?tag library URI? prefix = ?tag Prefix? %>
Comentários
Um primeiro tipo de comentário é o comentário HTML: independente de ser uma página JSP
(ou seja, mesmo sendo uma página HTML estática), pode-se utilizá-lo para incluir um texto que
não aparecerá diretamente para o usuário, a não ser que ele visualize o código-fonte da página.
A sintaxe de um comentário HTML é a seguinte:

Ao contrário do anterior, comentários JSP não são visíveis ao usuário nem mesmo se ele
visualizar o código-fonte da página.
<%--Comentários--%>
44

Ações
Ações permitem que acrescentemos funcionalidades ao JSP através da interações JavaBe-
ans. São tags que fornecem um mecanismo simpliﬁcado de acesso a objetos Java em páginas
JSP. Disponibilizam ainda comando para redirecionamento do JSP para outro servlet ou JSP.
Ações Padrão são ações pré-deﬁnidas pelo container JSP.
Exemplo:
<jsp:forward page=?/NomeDoDiretório/NomeDoArquivo.jsp? />
Esse comando redireciona a página passando o request.
45

Capítulo 7
JSTL e Javabeans
7.1 Noções JavaBeans e EJB
JavaBeans
Segundo a especificação da Sun Microsystems os JavaBeans são componentes reutilizáveis
de software que podem ser manipulados visualmente com a ajuda de uma ferramenta de de-
senvolvimento. De uma maneira direta, Javabeans são classes que possuem o construtor sem
argumentos e métodos de acesso do tipo get e set.
EJB
A pergunta que não quer se calar pode ser respondida muito facilmente uma vez que a maior
confusão feita aí fora é entre Javabeans e EJB.
Enterprise Java Beans é uma arquitetura de componentes multi-plataforma para o desenvolvi-
mento de aplicações Java muiti-tier, distribuídas, escaláveis e orientadas a objetos. O objetivo da
arquitetura EJB é facilitar o trabalho do desenvolvedor para que ele não tenha que se preocupar
com aspectos de infra-estrutura.
Podemos usar beans por diversos motivos, normalmente as classes de modelo da nossa
aplicação costumam ser java beans.
Existem três tipos de EJBs:
• 1. Session Bean - é o tipo mais simples de EJB, pode ter estado (stateful) ou não ter
(stateless);
• 2. Entity Bean - mapeiam tabelas de um banco de dados relacional através de um arquivo
de mapeamento. Na prática cada objeto entity representa uma linha de uma tabela. Existe
uma linguagem de query específica para buscar entitys chamada EQL;
• 3. MDB - são consumidores assincronos de mensagens de filas / tópicos JMS.
Na teoria, o uso de EJBs tornaria mais fácil escrever aplicações empresariais como compo-
nentes provendo um conjunto de serviços automáticos para suportar aplicações transacionais, o
que não acontece na prática.
46

7.2 JSTL
Em lições anteriores mostramos alguns problemas como: a dificuldade de construir páginas
JSPs bem organizadas; web designers normalmente não programam em Java, o que causa difi-
culdades na interação entre desenvolvedores e web designers. Seguindo a idéia de melhorar o
código java que precisa de uma maneira ou de outra ser escrito na página jsp, a Sun sugeriu o
uso da Java Server Pages Standard Tag Library: a JSTL.
A JSTL é a API que encapsulou em tags simples toda a funcionalidade que diversas páginas
web precisam, como controle de laços (fors), controle de fluxo do tipo if/else, manipulação de
dados xml e internacionalização de sua aplicação. Consiste em uma coleção de bibliotecas,
tendo cada uma um propósito bem definido, que permitem escrever páginas JSPs sem código
Java, aumentando assim a legibilidade do código e a interação entre desenvolvedores e web
designers.
Existe também uma outra parte famosa da JSTL, aquela que acessa banco de dados e per-
mite escrever códigos SQL na nossa página, mas às vezes o designer não conhece java, muito
menos SQL. O uso de tal parte da JSTL é desencorajado. A JSTL foi a forma encontrada de
padronizar o trabalho de milhares de programadores de páginas JSP.
Muitas páginas JSP no mundo ainda possuem muitos pedaços de scriplets espalhados dentro
dela mesma. Recomendamos a todos os nossos alunos que optarem pelo jsp como camada de
visualização que utilizem a jstl e outras bibliotecas de tag para evitar o código incompreensível que
pode ser gerado com scriplets. O código das scriplets mais confundem do que ajudam, tornando
a manutenção da página jsp cada vez mais custosa para o programador e para a empresa.
Para instalar a implementação mais famosa da JSTL basta baixar a mesma no site do apache:
http://www.apache.org
Bibliotecas JSTL padrão
Biblioteca Prefixo URI Tipos de uso Exemplo
JSTL
core c */core .acesso e modificação <c:forEach>
de dados em memória;
.comandos condicionais
e loops;
processamento x */xml .Parsing** de documentos <x:forEach>
de xml .impressão de partes de
documentos XML;
.tomada de decisão base-
ado no conteúdo do XML;
internacionalização fmt */fmt .Leitura e impressão <fmt:formatDate>
e formatação de números e datas
.ajuda a aplicação a
funcionar em mais de
uma língua;
acesso a banco de sql */sql .Leitura e escrita em <sql:query>
dados via SQL banco de dados;
* http://java.sun.com/jstl
**Parsing = Leitura
47

Instalando:
1. Faça o download em : http://www.apache.org/dist/jakarta/taglibs/standard/
2. Descompacte o arquivo e copie:
a) /jakarta-taglibs-standard-1.*/tld/* para WEB-INF
b) /jakarta-taglibs-standard-1.*/lib/* para WEB-INF/lib
3. Adicione essas informações no web.xml:
<taglib>
<taglib-uri>http://java.sun.com/jstl/fmt</taglib-uri>
<taglib-location>/WEB-INF/fmt.tld</taglib-location>
</taglib>
<taglib>
<taglib-uri>http://java.sun.com/jstl/fmt-rt</taglib-uri>
<taglib-location>/WEB-INF/fmt-rt.tld</taglib-location>
</taglib>
<taglib>
<taglib-uri>http://java.sun.com/jstl/core</taglib-uri>
<taglib-location>/WEB-INF/c.tld</taglib-location>
</taglib>
<taglib>
<taglib-uri>http://java.sun.com/jstl/core-rt</taglib-uri>
<taglib-location>/WEB-INF/c-rt.tld</taglib-location>
</taglib>
<taglib>
<taglib-uri>http://java.sun.com/jstl/sql</taglib-uri>
<taglib-location>/WEB-INF/sql.tld</taglib-location>
</taglib>
<taglib>
<taglib-uri>http://java.sun.com/jstl/sql-rt</taglib-uri>
<taglib-location>/WEB-INF/sql-rt.tld</taglib-location>
</taglib>
<taglib>
<taglib-uri>http://java.sun.com/jstl/x</taglib-uri>
<taglib-location>/WEB-INF/x.tld</taglib-location>
</taglib>
48

<taglib>
<taglib-uri>http://java.sun.com/jstl/x-rt</taglib-uri>
<taglib-location>/WEB-INF/x-rt.tld</taglib-location>
</taglib>
4. Por fim, na página JSP, declare os tipos que for utilizar:
<%@ taglib uri="http://java.sun.com/jstl/core" prefix="c" %>
Explicando a sintaxe
Cada tag faz parte uma biblioteca JSTL e realiza um determinado tipo de processamento
(equivalente a código Java dentro de JSP). Uma página JSTL pode utilizar várias bibliotecas
JSTLs. Na primeira linha, temos a seguinte tag:
<%@ taglib prefix="fmt" uri="http://java.sun.com/jsp/jstl/fmt"%>
Essa declaração informa ao compilador que é utilizada uma biblioteca cujas tags serão reco-
nhecidos pelo prefixo "fmt", de modo a evitar possíveis conflitos com tags de mesmo nome de
outras bibliotecas. A biblioteca de tags é identificada pelo atributo uri. Veja:
Exemplo de página JSTL:
<%@ taglib prefix="fmt" uri="http://java.sun.com/jsp/jstl/fmt" %>
<html>
<body bgcolor="#FF0000">
<jsp:useBean id="now" class="java.util.Date"/><br>
Short Version: <fmt:formatDate value="${now}" />
Long Version: <fmt:formatDate value="${now}" dateStyle="full"/>
</body>
</html>
A tag padrão <jsp:useBean> é utilizada para instanciar um objeto java.util.Date (inicializado
por padrão com a data e hora atuais do sistema).
A variável now, criada pelo tag <jsp:useBean>, é depois referenciada dentro do atributo value
dos tags <fmt:formatDate>, que aparece duas vezes na página.
Observe que o atributo dateStyle do tag <fmt:formatDate> define se será utilizado um formato
resumido da data ou um formato longo.
O exemplo apresenta a data atual em dois formatos: um curto e outro longo.
No caso o resultado da hora das versões:
Short Version: 24/05/2007
Long Version: Quinta-Feira, 24 de Maio de 2007
Observe que não existe nenhum código Java.
49

Capítulo 8
Servlets: Criação e Ciclo
8.1 O que são Servlets?
No começo, a web foi basicamente utilizada para disponibilizar conteúdo estático. Da neces-
sidade de gerar conteúdo dinâmico surgiram primeiro os programas de CGI (Common Gateway
Interface). No entanto, a primeira tecnologia java que tinha a finalidade de oferecer conteúdo
dinâmico foi "Servlet".
Servlets são programas java que executam em associação com servidores web através do
modelo ’request/response’, ou seja, lidando com características típicas do protocolo HTTP, como
os métodos GET, POST, com os Cookies etc.
Servlets não possuem interface gráfica e trabalham não só com servidores web mas com
vários tipos de servidores, uma vez que sua API não contém explicitamente especificações ao
ambiente do servidor. Além disso, são carregadas apenas uma vez e, por serem multi-thread,
podem atender a mais de uma solicitação de uma só vez. Esta peculiaridade que a torna mais
rápida que um programa CGI comum.
Exemplo de arquitetura de um servlet:
50

OBS.: Thread é uma forma de um processo dividir-se em mais de uma tarefa que podem ser
executadas simultaneamente. Uma thread permite que o usuário de programa use uma funcio-
nalidade do ambiente enquanto outras threads realizam outros cálculos e operações.
O servidor interage com o servlet através de uma interface padrão, que é:
Interface javax.servlet.Servlet.
Ela define os métodos init, service e destroy, que são responsáveis pelo ciclo de vida de um
servlet. O comportamento das servlets que veremos adiante é definido na classe HttpServlet do
pacote javax.servlet. Eles se aplicam às servlets que trabalham através do protocolo Http.
8.2 Criar o primeiro Servlet
Depois da instalação e configuração do Tomcat seguimos basicamente seis etapas para es-
crever o seu servlet a executá-lo.
51

Primeiro:
Crie um diretório chamado teste no diretório webapps do Tomcat. É importante o nome do
diretório, pois ele irá aparecer na URL do browser. Crie também um diretório chamado WEB-INF
dentro do teste, e dentro de WEB-INF crie o diretório classes.
Segundo:
Preparamos então o código-fonte e salvamos no diretório classes do contexto.Preparamos
então o código-fonte e salvamos no diretório classes do contexto (arquivo deve ter o mesmo
nome da classe, da maneira “java” de ser).
___________________________________________________________________________________
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
public class ServletTeste extends HttpServlet {
private PrintWriter out;
public void doGet(HttpServletRequest request,HttpServletResponse response)
throws IOException, ServletException{
response.setContentType("text/html");
saida = response.getWriter();
saida.println("<HTML>");
saida.println( "<HEAD>");
saida.println( "<TITLE> Teste</TITLE>");
saida.println( "<BODY>");
saida.println( "Primeiro Servlet.");
saida.println( "</BODY>");
saida.println("</HTML>");
}
public void doPost(HttpServletRequest request,HttpServletResponse response)
throws IOException, ServletException{
doGet(request, response);
}
}
___________________________________________________________________________________
Terceiro:
Compilamos então o código-fonte anterior. Exemplo:
$ javac -classpath /opt/install/apache-tomcat-6.0.10/lib/servlet-api.jar:. -d classes ServletTeste.java
, onde
52

-classpath <pasta>:<pasta> - define os diretórios que serão usados como classpath ()
-d <pasta> - define o diretório para onde vai o arquivo compilado ( .class).
Quarto: Criamos o ’web.xml’ e o colocamos no diretório /WEB-INF do contexto. A criação
do básico do web.xml é feita da seguinte maneira (a explicação deste primeiro web.xml é mais
superficial. Um arquivo web.xml mais prático vai ser criado mais pra frente):
___________________________________________________________________________________
<?xml version="1.0" encoding="ISO-8859-1"?> <!-- |1|>
<!DOCTYPE web-app <!-- |2|>
PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
"http://java.sun.com/dtd/web-app_2_3.dtd">
<web-app> <!-- |3|>
<display-name>Minha Aplicacao Web</display-name> <!-- |4|>
<description> <!-- |5|>
Esta é a versão XX de uma aplicação web que faz uso de servlet e jsp e serve
para automatizar tal coisa.
</description>
<context-param> <!-- |6|>
<param-name>webmaster</param-name> <!-- |7|>
<param-value>meuendereco@minhaempresa.com</param-value> <!-- |8|>
<description>
Endereco de email do administrador para quem questoes e comentarios
devem ser enviados.
</description>
</context-param>
<servlet> <!-- |9|>
<servlet-name>meuServlet</servlet-name> <!-- |10|>
<description>
Servlet usado para blablabla...
</description>
<servlet-class>com.meu.pacote.NomedoServlet</servlet-class> <!-- |11|>
<init-param> <!-- |12|>
<param-name>listaOrdens</param-name>
<param-value>com.minhaempresa.minhasAcoes.ListaOrdensAcoes</param-value>
</init-param>
<load-on-startup>5</load-on-startup> <!-- |13|>
</servlet>
<servlet-mapping> <!-- |14|>
<servlet-name>meuServlet</servlet-name>
<url-pattern>/meuServlet</url-pattern>
</servlet-mapping>
53

<session-config> <!-- |15|>
<session-timeout>30</session-timeout>
</session-config>
<welcome-file-list> <!-- |16|>
<welcome-file>index.jsp</welcome-file>
<welcome-file>index.html</welcome-file>
<welcome-file>index.htm</welcome-file>
</welcome-file-list>
</web-app>
___________________________________________________________________________________
Explicações gerais do web.xml:
|1| - Esta é a DTD (Document Type Definition) para os deployments descriptors da versão da
API Servlet. Os deployments descriptors também devem incluir um DOCTYPE |2|.
|3| - A partir daqui começam as descrições gerais da aplicação. A tag web-app é a raiz
dos deployment descriptor para as aplicações web. Nela, as tags devem obrigatoriamente estar
organizadas na seguinte ordem imposta pela DTD inclusa acima:
web-app <(icon?, display-name?, description?, distributable?, context-param*,
filter*, filter-mapping*, listener*, servlet*, servlet-mapping*, session-config?,
mime-mapping*, welcome-file-list?, error-page*, taglib*, resource-env-ref*,
resource-ref*, security-constraint*, login-config?, security-role*, env-entry*,
ejb-ref*, ejb-local-ref*)>
Onde uma "?"indica que a tag pode aparecer 0 ou 1 vez e o "*"indica 0 ou mais vezes.
|4| - Define um nome a ser mostrado para a aplicação. Não tem relação com o context-path,
portanto, essa configuração não vai alterar a maneira de acesso da aplicação.
|5| - Descrição para a aplicação web.
|6| - Parâmetro de inicialização que será utilizado por toda a aplicação. Valores definidos
nessa tag podem ser recuperados em um servlet ou uma jsp pela chamada do método:
String param = getServletContext().getInitParameter("name");
, onde "nome"deve coincidir com o valor definido na subtag <param-name>. Pode-se definir
também qualquer número de paramentros de inicialização que forem necessários. Incluindo o
zero.
|7| - Nome do parâmetro de inicialização.
|8| - Valor do parâmetro.
54

|9| - Definições para os servlets que fazem parte da aplicação, incluindo parâmetros de inicia-
lização. No Tomcat, pode-se também enviar requests para servlets não listados aqui da seguinte
maneira:
http://localhost:8080/diretório_raiz/servlet/Nome_da_classe
Entretanto, esse uso não é garantidamente portável. Isso também torna referências relativas
a recursos usados pelo servlet mais complexas. Então definir todos os servlets é o recomendado.
Parâmetros de inicialização do servlet podem ser recuperados em um servlet ou jsp da seguinte
maneira:
String value = getServletConfig().getInitParameter("nome");
onde "nome"deve coincidir com o valor definido na subtag <param-name> para algum dos
parâmetros. Pode-se definir também qualquer quantidade de servlets incluindo zero.
|10| - Nome do servlet. É uma tag obrigatória.
|11| - Tag usada para indicar o pacote (se houver) e a classe (qualificada) que representa o
servlet definido. Outra tag obrigatória.
|12| - Lista de parâmetros de inicialização referentes apenas a esse servlet. Pode-se usar
quantos <init-param> quiser inclusive zero.
|13| - Indica que este servlet deve ser carregado (instanciado e ter seu método init() cha-
mado) quando a aplicação for iniciada. O conteúdo desse elemento deve ser um inteiro indicando
a ordem na qual os servlets serão carregados. Se o valor é negativo, ou não é apresentado, o
container é livre para carregar o servlet a qualquer hora que escolher. Se o valor é um inteiro
positivo ou 0 (zero), o container deve carregar e inicializar o servlet assim que a aplicação é inici-
ada. O container deve garantir que servlet marcados com inteiros menores devem ser carregados
antes de servlets marcados com inteiros de valores altos. O Container pode escolher a ordem
para carregar servlet marcados com o mesmo valor em load-on-startup.
|14| - Como já explicado, a tag <serlvet-mapping> define um mapeamento que é usado pelo
servlet container para traduzir um request URI para um servlet em particular. Pode-se definir
qualquer número de mapeamentos para serlvets, incluindo zero. Tambem é permitido fazer mais
de um mapeamento para um mesmo servlet.
|15| - Define um timeout default para as sessions de sua aplicação, em minutos. A partir de um
serlvet ou JSP pode-se modificar manualmente o timeout para uma session em particular usando
dinamicamente os métodos.
HttpSession.getMaxInactiveInterval() e
HttpSession.setMaxInactiveInterval(int interval).
|16| - Lista de arquivos que serão procurados quando alguém acessar o diretório virtual da
aplicação. Os arquivos são listados em ordem de prioridade, de modo que os primeiros serão
55

procurados antes e, caso não sejam encontrados, o servlet container tentará usar o próximo da
lista.
Quinto:
Iniciar o Tomcat. Caso já esteja iniciado, ignore esta etapa.
Sexto:
Chamar o servlet a partir de um browser pela URL já demonstrada (usando a porta 8080):
http://localhost:8080/teste/Teste
Em lições posteriores serão melhor explicados os métodos usados no código fonte do Servlet.
8.3 Um Exemplo
Mostrarei aqui um exemplo mais prático. Nele criamos os diretórios na pasta webapps do
Tomcat, criamos um web.xml, criamos um servlet e uma página com um formulário.
Organização das pastas no tomcat(como já mostrado, a pasta padrão do Tomcat no nosso
caso é: /apache-tomcat-6.0.10):
+ apache-tomcat-6.0.10
| + webapps
| | + exemplo1
| | | | form.html
| | | + WEB-INF
| | | | web.xml
| | | | + classes
| | | | | Exemplo.class
| | | | -
| | | -
| | -
| -
-
Organização das pastas de projeto:
+ projetos
| + exemplo1
| | + web
| | | form.html
| | -
| | + etc
| | | web.xml
| | -
| | + src
56

| | | Exemplo.java
| | -
| | + classes
| | | Exemplo.class (Será criado na compilação do Exemplo.java)
| | -
| -
-
.Criando o arquivo ’form.html’ na pasta: projetos/exemplo1/web/
______________________________________________________________________________
<html>
<head>
<title>Exemplo1 CDTC</title>
</head>
<body>
<h1>Exemplo1 CDTC</h1>
<hr />
<p> Digite um valor: </p>
<form action="acao.do" method="post">
<input type="text" name="valor" />
<input type="submit" />
</form>
</body>
</html>
_______________________________________________________________________________
Criar arquivo Exemplo.java na pasta projetos/exemplo1/src/
________________________________________________________________________________
import java.io.*;
public class Exemplo extends HttpServlet {
public void doPost(HttpServletRequest request,HttpServletResponse response)
throws IOException, ServletException {
response.setContentType("text/html");
PrintWriter out = response.getWriter();
out.println("Você selecionou: <br />" );
String escolha = request.getParameter("color");
out.println(escolha + "<br />");
}
}
________________________________________________________________________________
.Criar arquivo web.xml na pasta projetos/exemplo1/etc/
57

________________________________________________________________________________
<web-app xmlns="http://java.sun.com/xml/ns/j2ee "
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd style=
"font-family:courier new,courier,monospace;">"
version="2.4">
<servlet>
<servlet-name>Exemplo1</servlet-name>
<servlet-class>Exemplo</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>Exemplo1</servlet-name>
<url-pattern>/acao.do</url-pattern>
</servlet-mapping>
</web-app>
________________________________________________________________________________2
.Compilar o arquivo Exemplo.java da seguinte forma:
$ cd projetos/exemplo1/ $ javac -classpath /opt/install/apache-tomcat-6.0.10/lib/servlet-api.jar:classes:.
-d classes src/Exemplo.java
,onde:
-classpath <pasta>:<pasta> - deﬁne os diretórios que serão usados como classpath
(buscar os arquivos java compilados que serão utilizados pelo programa)
- d <pasta> - deﬁne em qual pasta deverão ser armazenados os arquivos compilados
.Copiar o web.xml para a pasta ’exemplo1’:
$ cp etc/web.xml /opt/install/apache-tomcat-6.0.10/webapps/exemplo1/WEB-INF
.Copiar o conteúdo da pasta classes para /opt/install/apache-tomcat-6.0.10/webapps/WEB-
INF/classes/
$ cp -r classes /opt/install/apache-tomcat-6.0.10/webapps/exemplo1/WEB-INF/
Copiar o arquivo form.html para a pasta /opt/tomcat/webapps/exemplo1
$ cp web/form.html /opt/install/apache-tomcat-6.0.10/webapps/exemplo1
Reiniciar o Tomcat:
$ ./shutdown.sh
58

$ ./startup.sh
Acessar:
http://localhost:8080/form.html
8.4 O Ciclo de Vida de um Servlet
Inicialização de um servlet:
A inicialização de um servlet é uma tarefa realizada apenas uma vez. Operações comuns
na inicialização são as operações de carregar os parâmetros, carregar dados de configuração,
etc. Como já foi mostrado anteriormente, o servidor de aplicações de um servlet necessita de
um container para sua execução. Containers tratam as requisições recebidas, interagindo com a
plataforma de execução. Controlam o ciclo de vida do servlet. Quando a solicitação é feita, são
realizadas as seguintes operações pelo container:
Carrega a classe Cria uma Instância chama o init() iniciando a instância.
Cada requisição é tratada por um método service(). Este recebe dois parâmetros que repre-
sentam a entrada(dados recebidos do cliente) e a saída (dados enviados ao cliente). Entretanto
os passos mostrados anteriormente só ocorrem quando não existe nenhuma instância do servlet
requerido já carregada no container. Se já houver, apenas pule esse passo e execute o método
passando os objetos request/response como parâmetros.
OBS: Relembrando: Instância significa a concretização de uma classe, ou seja, criação de
um objeto com base em uma classe definida.
Finalização de um servlet:
Se é necessária a remoção do servlet, o container o finaliza chamando o método destroy()
daquele.
exemplificação do ciclo de vida de um servlet:
59

8.5 Métodos de Serviço
São métodos que implementam as operações de respostas quando o cliente faz alguma re-
quisição. Nos servlets HTTP métodos de serviço são divididos em doGET() e doPOST(), para
tratar respectivamente requisições GET e POST do Browser. Mostraremos mais adiante a API de
Servlets e isso ficará mais claro.
8.6 Implementação e Publicação de servlets
Como já foi dito, A implementação de servlets HTTP basicamente consiste em extender a
classe HttpServlet e redefinir um ou mais métodos de serviços. Os métodos init() e destroy()
podem também ser redefinidos, opcionalmente. A execução de um método de serviço consiste
em obter dados a partir do objeto request (que possui métodos os quais permitem manipular
os parâmetros fornecidos na solicitação HTTP), no processamento da transação e na resposta
através do response (que representa a página HTML que será devolvida ao usuário). O doGet é
chamado através de hyperlinks e o doPost através de formulários HTTP.
Para que seja utilizado, um servlet deve ser publicado num servidor de aplicação. Normal-
mente este está associado a um servidor web. Um exemplo disso seria Tomcat + Apache. No
caso do Tomcat os Servlets devem ser colocados no diretório /web-inf/classes. Terá então a
seguinte constituição:
http://localhost:8080/servlet/NomeDoServlet
60

8.7 HTML e Java - Servlets e JSPs
É complicado ficar escrevendo HTML dentro de uma servlet assim como é complicado ficar
escrevendo java em JSPs.
A idéia é não colocar muito código html dentro de uma classe em java, o que dificultaria muito
a alteração da página por um designer. Compare o código do ’HelloWorld’ como servlet. Muito
mais simples de editar o html: mas o designer não compreende o código Java. Duas coisas
que ajudam a combater esse problema são os JavaBeans e os variados padrões de arquitetura
existentes.
JSP: fica mais fácil para o designer alterar o código HTML!
SERVLETS: fica mais fácil de programar orientado a objetos e em JAVA!
Uma boa idéia para o problema é usar o MVC(Model View Controller) que será rapidamente
abordado mais adiante. Outra solução seria o uso de JSTLs, que também será rapidamente
abordado mais adiante.
8.8 Mapear uma servlet para uma URL
Uma vez que chamar a servlet pelo pacote e pelo nome da classe acaba criando URLs estra-
nhas e complicadas, é comum mapear uma servlet. Para fazer esse mapeamento é necessário
usar o arquivo ’web.xml’:
servlet
servlet-nameservletDeTeste/servlet-name
servlet-classbr.com.nome.servlet.HelloWorld/servlet-class
/servlet
E colocar o nome servletDeTeste para a url /hello :
servlet-mapping
servlet-nameservletDeTeste/servlet-name
url-pattern/hello/url-pattern
/servlet-mapping
Em resumo, usam-se dois passos:
• 1. Definir o nome e classe da servlet;
• 2. Usando o nome da servlet, definir a url.
Agora a servlet pode ser acessada, por exemplo, através de uma url desse tipo:
http://localhost:8080/jspfolder/hello
Assim que o arquivo web.xml e a classe de servlet de exemplo forem colocados nos diretó-
rios corretos basta configurar o tomcat para utilizar o diretório de base como padrão para uma
aplicação web.
61

8.9 Retornando ao cliente
Para retornar algo ao cliente, podemos usar a OutputStream ou o PrintWriter que é retornado
do objeto response.
PrintWriter writer = response.getWriter();
OutputStream stream = response.getOutputStream();
Para redirecionar o usuário para outra página, usamos o método sendRedirect(String):
response.sendRedirect(novaURL);
É importante, contudo, a chamada de apenas um desses métodos de cada vez. Se você
escreve algo através do writer, o cabeçalho é enviado ao cliente e impede o redirecionamento,
enquanto que se você chamar o método getWriter e depois o getOutputStream ocorrerá um erro.
8.10 Cookies
Os cookies permitem que dados sobre a página atual sejam armazenadas na máquina do
cliente para que sejam acessados em visitas futuras. Com os cookies, pode-se reconhecer quem
entrou num site, de onde vem, com que periodicidade costuma voltar, dentre outras utilidades.
Para a escrita dos métodos são utilizados os objetos request - que lê os cookies usando o método
getCookies() -, e o response - que escreve os cookies através do método addCookie(Cookie).
Falaremos mais sobre os Cookies posteriormente.
62

Capítulo 9
Servlets: API, Request e Response
9.1 Requisição e Resposta
Quando você digita algum endereço (URL) no browser, basicamente solicita um determinado
arquivo localizado em um computador em especial no local que você digita a URL. Esta máquina
onde o arquivo solicitado por você está armazenado, é chamado de web server (servidor web).
Essa principal função do computador é para servir a qualquer um na Internet que solicite arquivos
que ele hospeda. Já que você nunca sabe quando um usuário visitará e usará o seu aplicativo
web, o seu servidor web precisa estar ativo e em execução o tempo todo.
De uma maneira mais analítica, o que acontece é o seguinte após você digitar:
• 1- o browser(cliente) estabelece uma conexão TCP/IP com o servidor;
• 2- o browser envia uma solicitação ao servidor (request);
• 3- o servidor envia uma resposta ao cliente (response);
• 4- o servidor fecha a conexão.
HTTP é o protocolo que permite que os servidores web e browsers troquem dados pela web.
É um protocolo de requisição e resposta.
No início as páginas eram praticamente todas estáticas, ou seja somente arquivos HTML que
não eram gerados dinamicamente e nem tinham conexões com banco de dados. Logo após
começaram a criar as CGIs (Common Gateway Interface) que eram geradas dinamicamentes,
podiam trabalhar com arquivos, interagir com banco de dados e etc. Mais tarde vieram linguagens
em script tais como php e asp.
9.2 Servlet - O “CGI de Java”
Um servlet é como se fosse um “CGI de Java”. O objetivo de um servlet é receber uma
requisição do cliente e produzir uma resposta. Esta pode ser encaminhada a outro componente
web, como as JSPs, ou produzida pelo próprio servlet. A última, porém, não é uma alternativa
muito boa, já que a função especial de um servlet não é essa.
63

9.3 CGI X Servlets
CGI é outra tecnologia que permite gerar páginas dinâmicas, permitindo a um browser passar
parâmetros a um programa alojado num servidor web. Embora a linguagem tipicamente asso-
ciada aos CGI seja o PERL, o CGI foi projetado de forma a ser independente de linguagem.
Atualmente tecnologias como ASP ou PHP continuam utilizando a especiﬁcação.
Algumas vantagens de Servlets sobre CGI é que aqueles são: multi-threads(várias requisi-
ções ao mesmo tempo), utilizam toda a API de Java, possuem mais portabilidade e a programa-
ção é OO. O que acontece é que scripts CGI acionam programas no servidor. No entanto, seu uso
o sobrecarrega, uma vez que cada resquisição culmina a execução de um programa executável
(escrito com qualquer linguagem que suporte o padrão CGI) no servidor. Além disso, o processo
é inteiramente realizado pelo CGI no servidor. Se acontece algum erro na entrada de dados, o
CGI tem que produzir um HTML explicando o problema. Já os Servlets são carregados apenas
uma vez e além disso têm a vantagem de serem multi-threads. Cada cliente é representado por
uma linha de execução em Servlets, enquanto que em CGI cada cliente é representado por um
processo. Novas versões de CGI contornam o problema, mas permanecem alguns como falta de
portabilidade e insegurança na execução de código.
9.4 API
Application Programming Interface ou simplesmente API é um conjunto de rotinas e padrões
estabelecidos por um software para utilização de suas funcionalidades. De modo geral, a API é
composta por uma série de funções acessíveis somente por programação, e que permitem utilizar
características do software menos evidentes ao usuário tradicional.
A API de Servlets é composta, portanto, por um conjunto de Interfaces e Classes . O mais
básico é a Interface ’Servlet’, que deﬁne o comportamento básico do Servlet. O método service()
é quem trata todas as requisições dos clientes. Em geral não é sobrescrito, delega o processo
para o representante (método) adequado, de acordo com a requisição. A estrutura básica da API
de Servlet é a seguinte:
64

Eis aqui as considerações sobre os métodos:
• . os métodos init() e destroy() são chamados respectivamente quando o servlet é iniciado e
fechado no container;
• . o método getServletConfig() retorna um objeto (ServletConfig) que contém os parâmetros
de inicialização;
• . o método getServletInfo() retorna uma String que contém informações sobre o Servlet;
• . a classe GenericServlet normalmente não é usada. Ela implementa um servidor genérico;
• . a classe HttpServlet é uma classe abstrata que foi criada para lidar com o protocolo HTTP
e é a mais usada. Para o servlet atender as requisições HTTP, deve ser criada uma classe
derivada da HttpServlet e sobrescever ao menos um dos métodos:
doGet(): trata requisições GET, que podem ser enviadas várias vezes, sendo então
armazenadas em um bookmark;
doPost(): trata requisições POST, que permitem o envio de dados (somente uma vez)
de qualquer tamanho ao servidor web;
doPut(): trata requisições PUT, que permite o envio de dados ao servidor de maneira
parecia com o FTP;
doDelete(): trata requisições DELETE, que permite que o cliente remova algum docu-
mento do servidor.
Darei agora um exemplo de Servlet que implementa inicialização, finalização e o service:
__________________________________________________________________________________
package br.com.nome.servlet;
import java.io.*;
public class HelloWorld extends HttpServlet {
public void destroy() {
super.destroy();
System.out.println(Destruir!);
}
public void init() throws ServletException {
super.init();
System.out.println(Iniciar!);
}
protected void service(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
// objeto para receber o writer
// escreve o texto
65

out.println(html);
out.println(CDTC - JSP explica);
out.println(/html);
}
}
___________________________________________________________________________________
A organização dos principais métodos de cada Interface na API de Servlets é a seguinte:
9.5 Interfaces do doGet
1 - Interface HttpServletRequest
O método doGet() recebe dois parâmetros. Um deles é o HttpServletRequest, que é respon-
sável pela comunicação e tratamento do que vem do cliente para o servidor.
É necessário que citemos que, de acordo com a API, esta interface contém:
String getHeader(): obtém valor do primeiro cabeçalho;
Enumeration getHeaders(): obtém os valores de todos os cabeçalhos;
Enumeration getHeaderNames(): obtém os nomes de todos os cabeçalhos;
String getParameter(String par): obtém o valor do parâmetro;
66

String[] getParameterValues(String par): obtém os valores de todos os parâmetros;
Enumeration getParameterNames(): obtém os nomes de todos os parâmetros;
String getMethod(): obtém o método HTTP usado;
String getHeader(): obtém o cabeçalho HTTP;
String getQueryString(): obtém os dados codificados;
String getRemoteHost(): obtém nome do host remoto;
String getRemoteAddr(): obtém IP do host remoto;
String getProtocol(): obtém o protocolo utilizado;
Cookie[] getCookies(): obtém todos os cookies recebidos;
HttpSession getSession(boolean cria): pega/cria sessão;
Object getAttribute(String atr): obtém valor do atributo;
void setAttribute(String nome, Object obj): cria/modifica atributo;
2 - Interface HttpServletResponse
Outro parâmetro do método doGet() é o HttpServletResponse que é responsável pela comu-
nicação e tratamento do que vai do servidor ao cliente.
É necessário que citemos que, de acordo com a API, esta interface contém:
void setStatus(int code): define o código da resposta;
void setHeader(String cabec , String valor): define valor;
void addHeader (String cabec, String valor): define mais um valor;
void setContentType(String mime): define tipo de conteúdo a ser enviado. É obrigatório a
todo servlet que monte resposta;
void addCookie (Cookie c): define um cookie;
void sendError (int cod, String msg): devolve uma página de erro. Só pode ser usado se o
stream não estiver comprometido;
void sendRedirect (String URI): redireciona requisição. Só pode ser usado se o stream não
estiver comprometido;
OBS: Para testar se o stream está comprometido use isCommited(), mas só usa-se na prática
estes métodos quando não tiver usado o stream;
PrintWriter getWriter(): obtém stream de caracteres;
ServletOutputStream getOutputStream(): idem, só que de bytes.
Obsevação geral: Deve-se utilizar os métodos de cabeçalhoantes de usar o stream para
montar a resposta do Servlet.
3 - Interface ServletRequest
Os principais métodos que esta interface contém estão mostrados na figura da página anterior.
67

4 - Interface ServletResponse
Os principais métodos que esta interface contém estão mostrados na ﬁgura da página anterior.
Para ﬁnalizar, um outro exemplo de Servlet implementando as interfaces e alguns métodos:
import java.util.*;
import java.io.*;
public class SimpleServlet extends HttpServlet {
public void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
String title = Simple Servlet Output;
//configura tipo de conteúdo e outro cabeçalho de resposta primeiro
response.setContentType(text/html);
out.println(HTMLHEADTITLE);
out.println(title);
out.println(/TITLE/HEADBODY);
out.println(H1 + title + /H1);
out.println(PThis is output from SimpleServlet.);
out.println(PMethod: + request.getMethod());
out.println(PRequest URI: + request.getRequestURI());
out.println(P Protocol: + request.getProtocol());
out.println(PPathInfo: + request.getPathInfo());
out.println(PRemote Address: + request.getRemoteAddr());
// pega os parâmetros
Enumeration epar = request.getParameterNames();
while (epar.hasMoreElements()) {
String par = (String)epar.nextElement();
String val = request.getParameter(par);
out.println(PParâmetro +par+, valor=+val);
}
out.println(/BODY/HTML);
out.close();
}
public void doPost(HttpServletRequest request, HttpServletResponse response){
try {
doGet(request, response);
} catch (Exception e){
System.err.println(Erro no doPost n+e);
}
}
}
68

Capítulo 10
Usando Cookies e Controlando
Sessões
10.1 Cookies
O protocolo HTTP possui como uma de suas características não possuir informações de es-
tado. Isto é, depois que uma solicitação é recebida e uma resposta é devolvida, o servidor HTTP
esquecetudo a respeito do computador no qual aquele navegador está rodando. A próxima
requisição será tratada, então, como se fosse a primeira daquela máquina. Apesar de tornar o
protocolo HTTP mais simples e portanto mais confiável, isso faz com que aplicações web tornem-
se cada vez mais avançadas, a fim de suprir as necessidades de personalização de uma página
para seu usuário.
Para facilitar a vida dos programadores, foram criados os cookies. Os cookies permitem que
dados sobre a página atual sejam armazenadas na máquina do cliente para que sejam acessados
em visitas futuras. Com os cookies, pode-se reconhecer quem entrou num site, de onde vem, com
que periodicidade costuma voltar, dentre outras utilidades.
Normalmente, um cookie é um par de Strings guardado na máquina cliente, assim como um
mapa de Strings. Esse par de strings possui limitações que variam de acordo com o cliente utili-
zado. Isto torna os cookies pouco confiáveis, já que as informações do cookie são armazenadas
na máquina cliente. O mesmo pode, portanto, alterá-la de alguma maneira, o que torna inviável,
por exemplo, guardar o nome do usuário logado. Para a escrita dos métodos são utilizados os
objetos request - que lê os cookies usando o método getCookies() -, e o response - que escreve
os cookies através do método addCookie(Cookie).
Da primeira vez que a máquina cliente faz a requisição, o cookie é salvo nela. A partir daí, ele
é enviado de volta ao servidor toda vez que o cliente efetuar nova requisição. Assim indentifica-se
um usuário: sempre com os dados que o cookie envia.
Cada cookie só é armazenado para um website. Cada website possui seus próprios cookies
e estes não são vistos em outra página.
Exemplo do uso de cookies: em logins de websites são bastante usados para relembrar seu
nome de usuário e/ou senha para que não precise digitá-los toda vez que acessar a página.
69

Problemas com o uso de cookies
Apesar de sua funcionalidade, é um tanto arriscado trabalhar com os cookies em sessões que
necessitam de segurança e é também um trabalho complicado achar um cookie específico. Outro
problema é que, na primeira vez que adicionamos um cookie na resposta, ele não está disponível
para a leitura através da requisição. Podemos, entretanto, resolver este problema usando um
atributo do método request:
request.setAttribute();
request.getAttribute();
Porém, uma outra dificuldade em lidar com cookies é que através deles não é possível marcar
um cliente com um objeto, somente com Strings. Seria necessário para gravar dados de um
usuário logado um cookie para cada atributo: usuario, senha, id, etc.
Por fim, por essas e outras, pode-se perceber que trabalhar apenas com os cookies pode ser
muito penoso.
10.2 Sessões
O processo de tentar manter o estado através de múltiplas solicitações HTTP é chamado de
Gerenciamento de Sessão. A idéia aqui é que as solicitações de um usuário por páginas de
um servidor web durante um certo período de tempo, são na verdade parte da mesma sessão
interativa.
Uma sessão facilita a vida de todos por permitir atrelar objetos de qualquer tipo a um cliente,
não sendo limitada somente a strings e é independente de cliente. O JSP inclui suporte embutido
para Gerenciamento de Sessão ao se aproveitar das capacidades fornecidas pela API de Servlet
de Java. Os Servlets, por sua vez, podem usar a reescrita de URL ou cookies para implementar
o gerenciamento de sessão, mas os detalhes deste estão ocultos no nível JSP de linguagem.
A abstração da API facilita o trabalho do programador, já que dispensa saber como a seção
foi implementada no container. Ele simplesmente sabe que a funcionalidade existe e está lá para
o uso. Uma importante desvantagem do uso de cookies é que um usuário pode desabilitar o
suporte para cookies no Browser. Podemos então usar a reescrita de URL(url-rewriting). É uma
técnica que anexa o ID de sessão com um parâmetro de solicitação a todas as URL que se
linkam as páginas locais ao servidor web. Esta técnica é bem trabalhosa, já que, a fim de fluir o
ID de sessão apropriado específico de usuário, todas as referências às URLs devem ser geradas
dinamicamente.
A sessão nada mais é que um tempo que o usuário permanece ativo no sistema. A cada
página visitada, o tempo de sessão é zerado. Quando o tempo ultrapassa um limite demarcado
no arquivo web.xml, o cliente perde sua sessão. Neste momento toda a memória do sistema
associada com este objeto session, incluindo aquela de qualquer objeto específico da aplicação
armazenados nele, se torna disponível para remoção da JVM (garbage Colection). Da próxima
vez que o usuário voltar ao site, um novo objeto session vazio será criado, nenhuma informação
é carregada de sessões que já tenham expirado.
70

Conﬁgurando o tempo
Para conﬁgurar o tempo padrão para o usuário perder a sessão somente incluímos:
session-config
session-timeout3/session-timeout
/session-config
no arquivo ’web.xml’.
Registrando o usuário logado na Sessão
Primeiramente devemos criar uma sessão para poder utilizar os recursos dela. Assim conse-
guiremos marcar o cliente para a próxima vez que ele visitar uma página na mesma aplicação. Na
classe HttpServletRequest existem dois métodos getSession() sendo que um não recebe argu-
mentos e retorna a sessão que já existia ou uma sessão nova caso não exista nenhuma. Métodos
básicos de uma sessão já pronta:
Vantagens
Algumas das vantagens do Gerenciamento de Sessão são:
• torna mais difícil para o cliente forjar ser alguém que ele não é;
• os objetos são armazenados no servidor e não precisam ser reenviados em toda requisição
(apenas o link de sessão precisa ser enviado);
• qualquer objeto Java pode ser utilizado como valor salvo na seção, não se limitando apenas
a strings.
Desvantagens
Algumas das desvantagens do Gerenciamento de Sessão são :
• o servidor perde o dado se o navegador for fechado;
• uma seção não é necessariamente a mesma em diferentes instâncias do mesmo browser
no mesmo cliente acessando a mesma aplicação web, o servidor não controla o cliente.
Não se sabe como ele irá funcionar.
71

Capítulo 11
Controle de Erros
É comum que diversos pontos de nossa aplicação necessitem de tratar seus erros. O pro-
cesso de declaração para controle de erros não requer mudanças na classe, apenas de um
arquivo de configuração. Através deste é possível, para cada tipo de erro, configurar qual página
html, jsp, servlet, etc, deve ser utilizada.
Se uma exception ocorrer em uma página jsp ou servlet através do processo declarativo, todas
as exceções de um tipo ou de um código definido vai para uma página de erro.
Um exemplo de uma página de erro é a seguinte:
%@ page isErrorPage=true %
html
Um erro ocorreu.br/
% if(exception!=null) { %
Descrição: %=exception.getMessage()%br/
% } %
/html
onde primeiramente usa-se uma diretiva para indicar que é uma página de controle de erro.
Pode-se então verificar se uma variável ( no caso exception) não é nula e imprimir assim uma
mensagem de erro. Nomearemos essa página como ’paginaerro.jsp’.
11.1 Erros
1 - Erros em páginas JSP
Novamente, no arquivo ’web.xml’ define-se qual tipo de exception vai para qual página jsp:
error-page
exception-typeclasse/exception-type
location/nome_da_pagina.jsp/location
/error-page
Imaginemos, por exemplo, que o seguinte código trata um erro numa conexão de banco de
dados (não tratado no curso):
72

html
%
if(true) throw new java.sql.SQLException(Não foi possível acessar o banco de dados!);
%
/html
Se já tivermos conﬁgurado quando ocorrer uma exceção SQLException a página ’pagina-
erro.jsp’, por exemplo, deve ser mostrada, não precisamos mais fazer nada na página jsp que
pode gerar um erro. O arquivo ’web.xml’ é quem trata os erros, só nos preocupamos então com
o nosso código.
2 - Erros em Servlets
Quando acontecem erros em servlets, já não é uma situação tão trivial. Precisamos tratá-los
antes de jogá-los adiante. A assinatura do método service(ou doGet, ou doPost, etc) só permite
fazer o throw (lançamento de erros para posterior tratamento) do ServletException, IOException
e RuntimeException. A primeira foi criada para que a utilizemos como wrapper para as exceções,
ou seja, devemos empacotaras exceções em uma ServletException para que possamos sair do
método. Exemplo:
throws new ServletException(
new SQLException(?Erro em uma consulta ao banco de dados?));
OBS: aqui o ServletException engloba o SQLException.
Se checarmos as lições anteriores, notaremos que existem dois métodos na interface HttpSer-
vletResponse responsáveis por lidar com exceções em estilo programático. São eles: sendError()
e setStatus().
Os dois recebem um int com o código do erro que ocorreu apesar de que o setStatus não gera
o processo de erro conrrespondente, somente marca no cabeçalho o que ocorreu. O setStatus
recebe também uma variável String que representa a mensagem de erro.
Podemos também adicionar o controle no web.xml através do código do erro que ocorre:
error-page
error-code404/error-code
location/paginaNaoEncontrada.jsp/location
/error-page
Códigos dos erros e seus signiﬁcados:
200 - OK;
400 - requisição mal formada;
403 - acesso negado;
404 - recurso(página, imagem etc.) inexistente;
500 - erro no servidor (requisição não pode ser tratada).
73

11.2 MVC
Model View Controller ou Modelo-Visão-Controlador é um padrão de arquitetura de aplicações
que visa separar:
• lógica da aplicação, com as classes que representam suas entidades, e as que lhe ajudam
a armazenar e buscar os dados: (Model);
• interface do usuário, responsável por apresentar os resultados da página web: (View);
• fluxo da aplicação,a servlet (e auxiliares) que faz os dispatchs para quem deve executar
determinada tarefa: (Controller).
Esse padrão permite que a mesma lógica de negócios possa ser acessada e visualizada por
várias interfaces. Garante a separação de tarefas facilitando assim a reescrita de alguma parte já
que reduz a duplicação de código, centraliza o controle e torna a aplicação mais robusta, portável
e de fácil manutenção. O controle de fluxo é implementado fora das páginas JSP, normalmente
em arquivos XML, nos quais são definidas as regras de navegação da aplicação.
Struts ajuda-nos a implementar o MVC, pois tem uma controladora já pronta, com uma série
de ferramentas para o auxílio. O Hibernate pode ser usado como Model, por exemplo. E como
View, você não precisa usar só JSP, pode usar a ferramenta Velocity, por exemplo.
OBS: Struts é um framework do grupo Jakarta que serve como o Controller de uma arquite-
tura MVC. Apesar de ter suporte para qualquer tipo de Servlets, é focado no uso de HttpServlets.
Sempre que você utilizar o Struts, não precisará alterar os dados do web.xml, você irá somente
adicionar novas ações no struts-config.xml.
Pode-se então melhorar o código da aplicação se trabalharmos com código java na servlet e
depois o código HTML em uma página jsp.
74

A api da servlet nos permite fazer tal redirecionamento. Basta conhecermos a url que quere-
mos acessar e podemos usar o método getRequestDispatcher para acessar outro recurso web,
seja esse recurso uma página jsp ou uma servlet, dessa maneira:
RequestDispatcher rd = request.getRequestDispatcher(?/visualizacao.jsp?);
rd.forward(request,response);
return;
Pode-se assim executar a lógica de nossa aplicação web em uma servlet e então redirecionar
para uma página jsp, onde você possui seu código html.
cookies: http://www.roseindia.net/jsp/jspcookies.shtml
75

Jspservlets

Mais conteúdo relacionado

Mais procurados

Semelhante a Jspservlets

Mais de Tiago

Último

Jspservlets