Curso Tomcat

Servidores de Aplicações
J2EE usando TomCat
Marcos Pedro Pinto

Servidores de Aplicação Java
EE usando Tomcat
• Este curso visa capacitar profissionais
na administração e gerenciamento de
servidores de aplicação Tomcat, tanto
em ambiente de desenvolvimento
quanto em ambiente de produção.
Aula 1
Conceitos Java EE
• Java SE x Java EE
• Containers Web, EJB e de Aplicação
• Servlets, JSP, JSTL e JSF
• Frameworks Struts, Hibernate e outros
• O formato War e deployment
descriptions
Java SE x Java EE
• Java SE ou JSE Java Standard Edition (Antigo
J2SE)
– Fornece a JVM (Maquina Virtual java) e as APIS
essenciais para coleções, E/S , reflexão,
serialização, XML, interfaces gráficas e redes.
• Java EE ou JEE – Java Enterprise Edition

(Antigo J2EE)
– Tecnologias e APIs da plataforma Java para
computação baseada em Servidor
– Conectividade com bancos de dados, serviços de
diretórios, correio eletrônico e outros serviços.
Aplicações JavaEE
Aplicações Java EE
APIs do Java EE
Bibliotecas APIs de Extensão

(ex.Jakarta Commons) (ex. JAf)
APIs do Java SE
JVM
Sistema Operacional
Aplicação Java EE x JVM x Container
Processo do S.O
JVM
Container Web
Aplicação 1 Aplicação 2
O formato WAR e deployment
descriptor
• Uma aplicação web em Java deve ser

empacotada em um formato chamado
WAR
• O arquivo WAR é um JAR (que por sua vez é
um zip). Nele contem as classes java e o
descriptor deployment
• Outros arquivos são tratados como páginas
estáticas ou páginas JSP dinâmicas
Sobre o Tomcat
• É um servidor de aplicação Java EE que
fornece apenas o Container Web para
execução de aplicações Web Java EE
• Fornece ainda serviços JNDI e JMX, de modo
que aplicações Web criadas originalmente
para servidores de aplicações mais
“parrudos” como o Jboss devem rodar sem
modificações no Tomcat
• Apresenta recursos avançados, como suporte
nativo a clustering (desde a versão 5.0)
Configuração do Ambiente Java
• Se você não usa o JPackage
• Será necessário configurar uma série de variáveis do
ambiente de acordo com a sua instalação do Java:
• JAVA_HOME para o diretório de instalação:
Export JAVA_HOME=/usr/java/jdk1.5.0_12
• PATH para incluir o diretório onde estão os comandos
java e javac
export PATH=$JAVA_HOME/bin:$PATH
Os instaladores do java da Sun não configuram
estas variáveis!
Instalando os Pacotes Jpackage do Java da
Sun
• Acesse o endereço http://192.168.0.242/cd

• Faça download dos arquivos do endereço:
http://desenv/cd/sun-java-1.5.0-jpp/
• Pacotes como “alsa” e “jdbc” dependem de outras
bibliotecas que podem não estar presentes na sua
instalação linux
• Os pacotes “demo” e “src” não são necessários ao
funcionamento do Java da Sun
• O pacote “plugin” server apenas para execução de
applets em um navegador web
Instalação mínima do java da Sun via
JPackage
• É realizada pelos comandos:
• rpm –ivh java-1.5.0-sun-1.5.0.07-1jpp.i586.rpm
java-1.5.0-sun-devel-1.5.0.07-1jpp.i586.rpm
java-1.5.0-sun-fonts-1.5.0.07-1jpp.i586.rpm
java-1.5.0-sun-plugin-1.5.0.07-1jpp.i586.rpm
Configurando o Java Default
• Se houverem várias instalações do “Java” no formato

Jpackage, é possível configurar o default utilizando o
comando alternatives
java –version
Gij (GNU libgcj) version 4.1.1 ...
alternatives --config java
java –version
• O sinal de + indica o java selecionado como Default
Instalação do Tomcat
• Pré-requisitos
• Versões do Tomcat
• Onde e como baixar
• Principais Arquivos e diretórios do
Tomcat
• Startup e shutdown do tomcat
Pré-requisitos do Tomcat
• Necessitamos de um ambiente de
desenvolvimento Java 1.4 ou superior
devidamente configurado para uso pela linha de
comando
• Acesse http://curso:8080/tomcat
• Copie o arquvo oi.java para a pasta /home/aluno
• Compile uma classe java com o comando javac
– javac oi.java
Pré-Requisitos
• Tomcat 5.0.x e anteriores
– JDK 1.3 ou superior
– O Tomcat necessita do computador Java fornecido
pelo JDK para compilar os servlets gerados pelo
processamento de páginas JSP
• Tomcat 5.5.x
– JRE 1.5.0 ou superior
– JRE 1.4.2 com biblioteca de compatibilidade
– O tomcat passou a incluir o compilador Java do
Eclipse de modo que basta um JRE
Como e Onde Baixar
• Visite http://tomcat.apache.org e siga o link
para download da versão desejada
• Baixe a distribuição Core, em formato zip
• A versão em formato “Windows Executable”
cria atalhos no menu iniciar e configura o
Tomcat para execução como serviço do
Windows
• A criação dos atalhos e serviço também pode
ser feito manualmente pela versão zip, que
inclui ainda os scripts para execução em
Linux e Unix
Instalação em Linux
• Descompacte o zip do Tomcat no seu
diretório home, preservando os
subdiretórios contidos no zip
– unzip apache-tomcat-5.5.16.zip
• Entre na pasta bin e dê permissão de
execução para todos os shell scripts
cd apache-tomcat-*/bin
chmod a+x *.sh
Principais arquivos e Diretórios
• Jakarta-tomcat-versão até a versão 5.0
• Apache-tomcat-versao (5.5.0 em diante)
• bin (scripts de inicialização e shutdown)
• conf (arquivos de configuração)
• webapps (aplicações e WARs)
• server (classes internas do servidor)
• common (classes usadas tanto pelo servidor quanto
por aplicações, como API de servlets)
• shared (classes compartilhadas por várias aplicações
, como drivers JDBC)
• logs,temp e work (arquivos voláteis)
Startup e Shutdown
• Dentro da pasta bin, os scripts startup e shutdown
(em versões .sh Linux e .bat em windows) são
usados, respectivamente para iniciar e parar o
servidor.
• Há ainda executáveis (.exe) para atalhos e serviços
Windows
• Scripts de início e término no padrão System V
(/etc/init.d) não fornecidos, devem ser criados pelo
administrador.
• A configuração padrão do tomcat escuta as portas
8080 (web), 8009 (AJP) e 8085 shutdown.
Configurando o JAVA_HOME 1/2
• O tomcat espera que esteja definida a

variável de ambiente JAVA_HOME, indicando
o diretório de instalação do Java
• Espera-se que um ambiente Java configurado
para uso pela linha de comando tenha
definido esta variável.
• Então é necessário configurar o JAVA_HOME
nos scripts de início do Tomcat
Configurando o JAVA_HOME 2/2
• Edite o arquivo conf/catalina.sh

• No início do arquivo, antes da linha que limpa o
CLASSPATH, acrescente:
export JAVA_HOME=/home/aluno/java
• Esta linha faz com que seja executado o java desta
pasta , mesmo que tenha outros java instalado.
• No nosso caso equivale a escolher o Java da Sun,
pois O GCJ no Fedora 6 é compatível com o 1.4.2
• Nota: Os binários do Tomcat 5.5.x são compilados
para o 1.5.0, mas podem ser re-compilados para o
1.4.x
Instalando o Java da Sun
• Utilizando diretamente os downloads no site da
Sun (http://java.sun.com) será necessário
configurar manualmente o ambiente
– Haverão problemas de compatibilidade com o
empacotamento de aplicações Java inclusos na sua
distribuição Linux no caso do RPM
• Melhor usar os pacotes em formato Jpackage ou
baixar o arquivo com a extensão “.bin”.
• Ou então use os pacotes fornecidos com o
RHEL e Suse Enterprise
Iniciando e Encerrando o Tomcat
• Para Iniciar entre na pata bin do Tomcat
cd ~/apache-tomcat-*/bin
• Execute o script startup
./startup.sh
• Para Terminar:
cd ~/apache-tomcat-*/bin
./shutdown.sh
• Após cada operação (início e término) conforme
a presença do processo Java e verifique que as
três portas abertas pelo tomcat.
Testando o tomcat
• Entre na pasta bin

• Execute o script startup
• Após alguns segundos,
deverá ser possível
acessar o Topmcat
• Acesse a URL:
• HTTP://127.0.0.1:8080
• O resultado deverá ser
como visto ao lado:
Exemplos do Tomcat
• No final do menu de navegação (laranja)
na parte esquerda da página inicial,
haverão links para exemplos de servlets e
páginas JSP
• Os links para documentação acessam
páginas fornecidas
Se Algo Deu Errado...
• Verifique os logs do Tomcat em especial o
/logs/catalina.out
• Verifique se o comando java pode ser executado
diretamente pela linha de comando
• Verifique se as portas 8080, 8009 e 8005
estavam livres antes do início do Tomcat
• Verifique se a estrutura de diretórios do Tomcat
foi preservada depois da descompactação do
artquivo zip
• Se tudo o mais falhar, encerre todos os
processos “java” ativos e reinstale o tomcat do
zero
Exercícios
• Encerre o Tomcat, caso ele esteja rodando
• Use o programa java fornecido pelo instrutor
para ocupar uma das portas utilizadas pelo
Tomcat, por exemplo:
Java Servidor 8080
• E veja o que aparece nos logs ao tentar iniciar o
Tomcat
Cd ~
Cd apache-tomcat-*/bin ; ./startup.sh
More ../logs/catalina.out
Aplicações de Administração do
Tomcat
• Ativação das aplicações administrativas
• Aplicação Manager
• Aplicação Admin
Ativação das aplicações
• Para evitar riscos de segurança, a instalação padrão do

Tomcat não define nenhum usuário com acesso às
aplicações administrativas
• Para criar este usuário, deve ser editado o arquivo
conf/tomcat-users.xml
• Deve ser acrescentado um usuário contendo os roles
admin e manager
• Como acrescentar este usuário será auto-explicativo
pelos exemplos fornecidos no próprio arquivo.
• O Tomcat deve ser reiniciado para que o novo usuário
seja reconhecido
Editando o arquivo tomcat-
users.xml
<?xml version='1.0' encoding='utf-8'?>
<tomcat-users>
<role rolename="tomcat"/>
<role rolename="role1"/>
<role rolename=“admin"/>
<role rolename=“manager"/>
<user username="tomcat" password="tomcat" roles="tomcat"/>
<user username="both" password="tomcat"
roles="tomcat,role1"/>
<user username="role1" password="tomcat" roles="role1"/>
<user username=“admin" password=“senha"
roles=“admin,manager"/>
</tomcat-users>
Aplicação Manager
• É utilizada para ativar, desativar e recarregar
aplicações web (pacotes WAR) hospedadas
pelo Tomcat
• Também permite a obtenção de relatórios sobre
o status atual do Servidor
• Foi criada para ser acessada por scripts
(utilizando wget, por exemplo), e não por
humanos, por isso sua interface simples
• Entre nela pela URL:
http://127.0.0.1:8080/manager/html
Aplicação Admin
• Permite a configuração do próprio servidor
Tomcat por exemplo criando novos usuários,
mudando a porta onde são escutadas conexões,
ou definindo DataSources para banco de dados
• Desde a versão 5.5.9, ela deve ser baixada e
instalada á parte
• Os resultados são salvos na pasta conf/Catalina
em vez do arquivo conf/server.xml monolítico
• Nota: O Admin foi descontinuado no Tomcat 6
Baixando e Instalando o Admin
• Visite a página de downloads do Tomcat

http://tomcat.apache.org/downloads-55.cgi
• Baixe o arquivo zip da “Administration Web
Aplication”
• Descompacte o arquivo por sobre sua instalação
Tomcat, sobrescrevendo arquivos se necessário
• Reinicie o Tomcat
Usando o admin
• Entre na aplicação pela URL
http://127.0.0.1:8080/admin
• Forneça o login e senha configurados para o
perfil “admin” no arquivo tomcat-users.xml
• Depois do login, a parte esquerda da página é
uma estrutura de árvore (outline) que permite
navegar pelos elementos de configuração do
servidor
• Abra os elementos “Service (catalina)” e “host
(localhost)” para ver a relação de aplicações
hospedadas no servidor
Aula 2
• Aprendemos como instalar e configurar
aplicações web para execução sob o servidor de
aplicações
• Tópicos Deployment de aplicações Web JavaEE
• Configuração de aplicações Web / Contextos
Deployment de Aplicações Web JavaEE
• Pacotes WAR abertos e fechados

• Deployment via cópia de arquivos Auto-
deploy
• Uso de Apache Ant para construção de
pacotes War
• Deployment via aplicação Manager
O que é Deployment?
• É um processo de instalação de uma aplicação
web Java EE dentro de um container web,
tornando esta aplicação disponível para seus
usuários
• Envolve garantir que todas as configurações e
recursos requeridos pela aplicação estejam
disponíveis para seus usuários
• Há várias formas locais e remotas de realizar o
deployment com o Tomcat
Aplicação de Exemplo
• Para os exercícios desta aula, será utilizada
uma aplicação simples, que consiste de duas
classes Java (um servlet) e quatro páginas JSP
• O instrutor fornecerá o arquivo exemplo1.1.zip
contendo a aplicação que deverá ser
descompactado na pasta home do usuário
• As classes Java de exemplo terão que ser
compiladas antes de prosseguirmos
Compilando o Exemplo
• Configure o classpath do sistema para incluir a
API de Servlets, fornecida pelo Tomcat
• Entre na pasta que contém as classes do
exemplo
• Compile as classes
• Verifique que a pasta WEB-INF/classes/exemplo
da aplicação contém agora dois arquivos *.class
que correspondem aos dos arquivos java
presentes na mesma pasta
Comandos para Compilar o Exemplo
export
CLASSPATH=$CLASSPATH:$HOME/apache-
tomcat-5.5.16/common/lib/servlet-
api.jar
ed exemplo1.1
ed WEB-INF/classes
javac exemplo/*.java
Montando um Pacote WAR
• Estando na sua pasta home, execute o
comando:
jar –cvf exemplo1.1.war –C exemplo1.1 .
• Observe o uso da opção –C e que o último
argumento é um ponto, indicando o diretório
corrente
• Isto é necessário porque o pacote WAR não
deve contar a pasta de topo de aplicação (no
caso, exemplo 1.1)
Verificando um Pacote WAR
• Liste o conteúdo do pacote usando o
comando jar.
jar –tvf exemplo1.1.war
• Também pode ser usado o comando unzip

Unzip –t exemplo1.1.war
Exercício 1/4
• Copie o pacote WAR gerado anteriormente para
a pasta webapps do Tomcat
Cp exemplo1.1.war apache-tomcat-*/webapps
• Verifique os Logs
tail apache-tomcat-*/logs/catalina.out
• Verifique a presença da aplicação tanto no
Manager quanto no Admin
• O nome da aplicação será igual ao nome do
pacote WAR, ou seja “exemplo1.1”
Exercício 2/4
• Se tudo estiver ok, a
aplicação poderá ser
acessada pela URL:
http://127.0.01:8080/exem
plo1.1
• Note que uma
aplicação web (ou
contexto) é visto pelo
navegador como se
fosse uma pasta
• O resultado é exibido
na figura ao lado:
Exercício 3/4
• Para remover a aplicação (undeploy) , basta
remover o arquivo da pasta webapps
Rm apache-tomcat-*/webapps/exemplo1.1.war
Rm –rf apache-tomcat-*/webapps/exemplo1.1
• Confirme nos logs do tomcat e no Manager que
a aplicação foi desinstalada
• É necessário recarregar o Manager ou clicar no
link List Applications
• O Manager não é atualizado automaticamente
depois de um deployment ou undeployment
Exercício 4/4
• Faça novamente o deployment, desta vez
copiando o pacote abert:
• Cp –rfp exemplo1.1 apache-tomcat-*/webapps
• Observe que, embora o Manager reconheça a
presença da aplicação, não há registro do seu
deployment nos logs do Tomcat
• Agora use o link Undeployment do Manager
para desinstalar a aplicação
• Verifique que o Manager remove o “pacote
WAR” (na verdade o subdiretório) na pasta
webapps
Descritor web.xml
• O arquivo WEB-INF/web.xml da própria
aplicação configura uma série de parâmetros
para o container web
• Estes parâmetros são independentes do
servidor utilizado, mas não incluem
configurações globais como portas TCP
• É comum este arquivo estar com erros de
sintaxe ou com nome errado (por exemplo, o
nome da pasta WEB-INF escrito em minúsculas)
• Neste caso, o Tomcat irá usar a configuração
padrão na pasta conf/web.xml do servidor
Exercício 1/2
• O objetivo é mudar a página inicial da aplicação
• Faça o deployment da aplicação como um
pacote aberto, conforme as instruções do último
exercício
• Confirme que a aplicação está ok
• http://127.0.0.1/exemplo1.1
• Altere o arquivo WEB-INF/web.xml da aplicação,
trocando “index.jsp” por “hoje.jsp” dentro do
elemento <welcome-file-list>
Exercício 2/2
• Repita o deployment da aplicação com um
pacote aberto (copie a pasta e seu conteúdo
sobre a pasta já existente em webapps)
• O Tomcat irá detectar mudanças no descritor
web.xml e fazer o re-deployment da aplicação
• Os logs do Tomcat irão indicar a realização da
operação:
Info: Reloading context (/exemplo1.1)
• Depois de confirmada a mudança na página de
boas-vindas da aplicação, retorne a
configuração para a página index.jsp
Re-deployment Automático
• A instalação padrão do Tomcat monitora o
descritor web.xml de cada aplicação,
recarregando em caso de mudanças
• Este comportamento pode ser desabilitado, pois
é indesejável em servidores de produção
• Mudanças em páginas JSP são detectadas e
efetivas no próximo acesso a página
• Mudanças em classes Java exigem a recarga
manual da aplicação pelo Manager (link reload)
Construção de Pacotes WAR com o Ant
• Em uma aplicação real, a estrutura de pastas para

arquivos HTML/JSP, classes Java e bibliotecas pode ser
bastante complexa, inviabilizando a construção dos
pacotes WAR manualmente com o comando jar
• Além disso, muitos desenvolvedores não vão querer
enviar os fontes as classes Java juntamente com os
binários (pacote WAR) da aplicação
• O padrão de fato para estas atividades é o uso de scripts
Ant, pois eles são portáveis, ao contrário de scripts shell,
que rodam apenas em Unix e Linux
Instalação do Ant
• Visite http://ant.apache.org e clique no link “binary
Distritibutions”
• Baixe o arquivo apache-ant-1.6.5-bin.zip (ou uma
versão mais recente) e descompacte na sua pasta
home
• Defina a variável de ambiente ANT_HOME
apontando para o diretório de instalação do Ant
• Export ANT_HOME=$HOME/apache-ant-*
• Acrescente a pasta bin do Ant ao path de comandos
do shell
Export PATH=$ANT_HOME/bin:$PATH
Ant x JPackage
• O Fedora 6 traz o ant 1.6.5, então não é
necessário fazer o download e instalação
• Caso você deseje baixar e instalar um Ant mais
recente do que o incluso na distribuição,
verifique o arquivo /etc/ant.conf
• O conteúdo deste arquivo tem precedência
sobre a configuração da variável ANT_HOME,
então ele deverá ser editado para indicar a
instalação correta do Ant.
Verificando a Instalação do Ant
• Execute o comando ant
ant –version
• Confirme que você está usando o ant que você
instalou
which ant
/home/aluno/ant-1.6.5/bin/ant
• Se você está utilizando o anto da distribuição o
resultado será
/usr/bin/ant
Scripts Ant
• São chamados de buildfiles, e o comando ant
executa por padrão os scripts do arquivo build.xml
• Usam a sintaxe XML, organizando na hierarquia:
• Projeto (project)
– Alvo (target)
– Tarefa (task)
• Há tarefas pré-definidas para compilação,
empacotamento e execução de aplicação Java,
além de manutenção de arquivos
• Alvos podem depender uns dos outros, de modo
similar a um Makefile
Exemplo 1.2
• Entre na pasta exemplo 1.2
• Cd $HOME/exemplo1.2
• Abra o arquivo build.xml em um editor de textos e
altere a linha abaixo para indicar a localização
correta da sua instalação do Tomcat
<property name=“tomcat”
value=“/home/fernando/apache-tomcat-
5.5.16” />
• Use o Ant para compilar, empacotar e instalar a
aplicação no Tomcat
Ant all
Exercício 2/2
• Verifique o formato do pacote WAR gerado pelo Ant
jar tvf dist/exemplo1.2.war
• Verifique pelo Manager e pelos logs que a aplicação
foi instalada com sucesso
• Acesse a página inicial do exemplo
• http://127.0.0.1:8080/exemplo1.2
• Note que o título da página de boas-vindas foi
modificado para diferença do exemplo 1.1
• Note ainda que este exemplo define um display-
name no descriptor web.xml, e que este nome é
exibido pelo Manager
Deployment via Manager
• Além do auto-deploy pela cópia de arquivos, o
Tomcat suporta o deployment pelo Manager, que
pode inclusive ser feito remotamente
• Se for um deployment local, o manager pode
apontar o Tomcat diretamente para o pacote WAR
da aplicação, sem necessidade de copiar para a
pasta webapps
• O nome do contexto (nas URLS) pode inclusive ser
diferente do nome do pacote
• Se for um deployment remoto, deve ser
obrigatoriamente fornecido um pacote WAR fechado
para upload, que será salvo em webapps
Configuração de Aplicações
Web/Contextos
• Introdução ao server.xml
• Engines, hosts e contextos
• Configuração do contexto via server.xml
• Configuração do context via
conf/host/contex.xml
• Configuração do contexto via META-
INF/context.xml
• Configuração do ambiente JNDI
Introdução ao server.xml
• O arquivo conf/server.xml é o principal arquivo
de configuração do Tomcat
• Ele define os números de portas TCP, ativação
de recursos como criptografia e clustering, e
pools de conexões a bancos de dados
• Modificar no arquivo exigem o reinício do
servidor
• É fácil descobrir o que alterar uma vez entendida
a estrutura do arquivo, que corresponde a
própria arquitetura interna do Tomcat
Estrutura Server.xml
<Server>
é o próprio tomcat
<Service>
é um serviço oferecido para a rede (no momento
apenas o container web)
<Connector>
é um protocolo para acesso por clientes do
container web (HTTP ou AJP)
<Engine>
é o container em si
<host>
é um host virtual, baseado em
nome
ou IP
<context> é uma aplicação web
Engines, hosts e contextos
• São principais elementos de configuração
do Tomcat
• Dentro do engine são inseridas definições
globais para todos os hosts e contextos do
servidor
• Um host permite a configuração de
domínios virtuais atendidos pelo servidor
• Um contexto é uma aplicação web
Outros Elementos do server.xml
• A maioria destes elementos podem ser inseridos em
qualquer nível da estrutura do Tomcat
• <logger> configura a geração de logs, mas recomenda-
se o uso do Log4J em vez deste elemento
• <Realm> fornece configurações de autenticação de
login e senha
• <valve> modifica o processamento de requisições, por
exemplo para gerar logs de acesso ou depuração da
requisição HTTP
• <GlobalNamingResources> pré-configura objetos na
árvore JNDI
Exercício 1/3
• Mudar a porta 8080 para porta 80
<Connector port="80" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443" />
• Lembre-se de reiniciar o Tomcat para que

a mudança tenha efeito!
• Entretanto, será necessário rodar o tomcat
como root, pois usuários comuns no Linux
não podem escutar portas <1024
Exercício 2/3
• Agora não é mais preciso especificar o número de
porta ex: http://127.0.0.1/manager/html
• Pelo manager, faça o undeploy dos exemplos deste
curso, de modo a deixar o tomcat “limpo”
• Agora desligue o auto-deploy de pacotes WAR, de
modo que novas aplicações ou aplicações delas
tenha que ser ativadas explicitamente
<Host name="localhost"
appBase=“webapps"
unpackWARs="true" autoDeploy=“false"
xmlValidation="false"
xmlNamespaceAware="false">
Exercício 3/3
• Aplicações instaladas pela cópia de

arquivos não estaram mais acessíveis
• Confirme isto fazendo o deploy do
exemplo 1.2 pelo ant
• Verifique que a aplicação não aparece na
listatem do Manager, nem o seu
deployment é acusado nos logs do tomcat
Dicas
• Não esqueça de retornar o autoDeploy para
true!
• Salve uma cópia do server.xml original do
Tomcat, pois os modelos e comentários
inseridos nele serão úteis no futuro
• Administradores de sistema preocupados com a
segurança não irão querer misturar os arquivos
de aplicações com os arquivos do Tomcat, e
podem conseguir isto modificando o atributo
appbase do elemento <host>
Editando o Server.xml via Admin
• Como já vimos, a aplicação Admin server
essencialmente para modificar o server.xml e
outros arquivos de configuração do Tomcat
• Ele tem a vantagem de não exigir o reinício do
Tomcat na maioria das alterações
• Mas tem a desvantagem de remover todos os
comentários do arquivo server.xml e re-formatar
todo o seu conteúdo
• Além do botão “Save”, deve ser selecionado o
botão “Commit Changes” para que a maioria das
mudanças feitas via Admin tenham efeito
Exemplo do Admin
• Esta tela ilustra a segunda parte do último
exercício sendo realizada pelo Admin
Configuração de Contextos
• Há várias formas de se configurar uma aplicação
web (contexto) no Tomcat
• 1. Implicitamente, copiando o WAR para a pasta
webapps (é o que fizemos até o momento)
• Explicitamente, editando o server.xml
• Explicitamente, criando um arquivo dentro da
pasta conf/engine/host
• Explicitamente, acrescentando na aplicação o
descritor não padrão context.xml
Exercício 1/4
• Faça o undeploy de todos os exemplos no Tomcat via
Manager
• Edite o server.xml para incluir um contexto apontando
diretamente para o pacote WAR gerado pelo Ant na
pasta dist do exemplo1.2
<Host appBase=“webapps” autoDeploy=“false”
liveDeploy=“false” name=“localhost”>
<Context path=“/teste1.2”
docBase=“/home/aluno/exemplo1.2/dist/exemp
lo1.2.war” usenameing=“false” >
<context>
</Host>
• Lembre que não deve haver quebra de linha no docBase!
Exercício 2/4
• Reinicie o Tomcat e verifique se o novo contexto
(teste 1.2) é relacionado pelo Manager
• Acesse o contexto pelo url
http://127.0.01:8080/teste1.2
• Note que foi usado um nome de contexto
diferente do nome do pacote WAR, para evitar
que o aluno execute por engano o resultado dos
exercícios anteriores
Exercício 3/4
• Se for usado o nome de contexto “” (string vazia)
a aplicação se torna o default do servidor
• A aplicação default é aquela exibida quando a
URL contém apenas o nome do servidor
• Então edite o elemento <Context> no arquivo
server.xml para eliminar o texto “/teste1.2”,
deixando apenas “”
• Delete (ou mova para fora do webapps) a pasta
ROOT, pois não podem haver duas aplicações
com o mesmo nome de contexto
Exemplo 4/4
• Verifique que o exemplo 1.2 agora é

exibido em vez da página padrão do
Tomcat quando se pede a URL contendo
apenas o nome do servidor
http://127.0.0.1
Configurando o contexto via
conf/engine/host
• A hierarquia Engine / host / contexto pode ainda receber
arquivos de configuração isolados dentro da pasta conf,
baseados nos atributos name da cada um
• O objetivo é permitir a configuração individualizada de
contextos (aplicações) sem poluir demais o server.xml
• Veja que na instalação padrão o Admin e Manager são
configurados pelos arquivos
• Conf/Catalina/localhost/admin.xml
• Conf/Catalina/localhost/manager.xml
Exercício
• Crie o arquivo outro1.2.xml dentro de
conf/Catalina/localhost, com o conteúdo:
<?xml version="1.0" encoding="UTF-8"?>
<Context path=“xpto”
docBase=“/home/aluno/exemplo1.2/dist/exemplo1.2.war”
usenaming=“false” reloadable="true">
</Context>
• Verifique que a URL http://localhost:8080/outro1.2 passa
a exibir o exemplo1.2
• Note que o atributo path é ignorado dentro da pasta
conf/catalina/localhost
Configuração do contexto via META-
INF/context.xml
• Uma quarta forma de se configurar um contexto
/aplicação web no Tomcat é acrescentando na
aplicação o descritor META-INF/context.xml
• Ele segue a mesma sintaxe do elemento
<Context> dentro do server.xml ou do arquivo
contexto em conf/engine/host
• A configuração pelo descritor não padrão só
será reconhecida pelo Tomcat caso a aplicação
seja instalada explicitamente pelo Manager!
• Ou seja, o descritor context.xml será ignorado
pelo auto-deploy
O descritor context.xml
• O atributo path também é ignorado nesta
configuração (vale o nome do pacote
WAR)
• Seu principal uso é para embutir na
aplicação configurações que de outra
forma teriam que ser feita nos arquivos do
tomcat, como DataSources e Realms
• O exercício do próximo tópico ilustra o uso
do descritor proprietário context.xml
Configuração de ambiente JNDI
• A plataforma Java EE especifica o uso da API JNDI para

obtenção de objetos potencialmente compartilhados
entre aplicações diferentes ou entre elas e o servidor
• O uso mais comum deste recurso é delegar para o
servidor de aplicações o gerenciamento de conexões
com outros servidores, ex: banco de dados e e-mail
• Estas conexões devem ser descritas na configuração do
Tomcat, de modo que uma aplicação web deixa de ser
auto-contida
• O Descritor context.xml resolve este problema
Exercício 1/3
• O instrutor irá fornecer o arquivo exemplo1.3.zip
contendo uma versão modificada de Servlet dos
exemplos anteriores
• Este servlet repete várias vezes a data corrente,
de acordo com um valor obtido do ambiente
JNDI
• Descompacte o arquivo zip da sua pasta home e
execute o alvo default do buildfile incluso
• O resultado será a geração do pacote WAR
exemplo1.3/dist/exemplo1.3.war que deverá ser
instalado via Manager
Exercício 2/3
• Feito o deployment explícito pelo Manager, o Admin
deverá mostrar, dentro do contexto “exemplo1.3”, o
elemento de ambiente “NúmeroMágico”
Exercício 3/3
• Experimente modificar o valor do
“NumeroMagico” pelo admin e recarregar o
Servlet
• Não é preciso clicar em “Commit Changes”
• Note que a aplicação não vê a mudança
• Somente depois que a aplicação seja
recarregada pelo Manager o novo valor do
Número Mágico será utilizado
• Mas observe que esta mudança é volátil (já que
não foi confirmada /”comitada”) e será perdida
se o Tomcat for reiniciado
Aula 3
Pools de Conexão
• Pode-se estabelecer um mínimo de conexões, de modo
que picos repentinos possam ser atendidos prontamente
• Pode-se estabelecer um máximo, de modo que nem o
servidor de aplicações nem o banco de dados fiquem
sobrecarregados
• A aplicação, em vez de abrir e fechar conexões, requisita
conexões de pool e as devolve o mais cedo possível
• O servidor de aplicações é o responsável pelo
gerenciamento do pool
Sobre o HSQLDB
• Banco de dados relacional 100% Java que

será usado nos exercícios
• Pode operar em modo stand-alone,
embutido em outra aplicação, ou como um
servidor independente
• Poucas demandas de memória e
processador
Baixando e Instalando o
HSQLDB
• Baixe o arquivo http://www.hsqldb.org
• Descompacte em sua pasta home
• Configure o classpath para incluir as
classes do HSQLDB
export
CLASSPATH=$CLASSPATH:/$HOME/hdslqdb/bin/hsql
db.jar
Criando o Banco de Dados
• Crie uma pasta no seu home para armazenar os
arquivos do banco
• mkdir $home/bd
• Inicie o Database Manager do HSQLDB, que permite
executar interativamente os comandos SQL
java org.hsqldb.util.DatabaseManagerSwing –url
“jdbc:hsqldb:file:$HOME/bd/contatos;shutdown=true”
• O comando acima irá criar o banco “contatos” dentro da
pasta “bd” abaixo de home do usuário
Inicializando o Banco de Dados
• Dentro do Database Manager, execute o comando:
CREATE TABLE contatos (
id identity primary key,
nome varchar(40) not null,
email varchar(30) not null)
• Agora insira alguns dados de teste:
INSERT INTO contatos (nome,email) values
('marcos','marcospp@assessorpublico.com.br');
INSERT INTO contatos (nome,email) values
('fulano','fulano@assessorpublico.com.br');
• Estes comandos estão no script contatos.sql junto
aos exemplos do curso
Verificando o Banco de Dados
• Finalize o Data Manager, Da forma que ele foi
executado, fica com acesso exclusivo ao bd
• Reinicie o Database Manager, contectando ao mesmo
banco “contatos”, e verifique se é possível recuperar os
dados previamente armazenados, executando o
comando SQL
select * from contatos order by nome;
• Nota: apenas uma JVM pode acessar os arquivos do
banco de dados, então não será possível rodar o
Database Manager e o Tomcat ao mesmo tempo!
Criação de DataSources
• Podem ser definidas ao nível de Engine, Host ou
Context no Tomcat
• Deve ser inserido o elemento <Resource>
especificando os parâmetros de conexão JDBC:
<Resource name="jdbc/contatos“ auth=“Container”
type="javax.sql.DataSource“
maxIdle=“0“ maxWait=“-1“ MaxActive=“’1”
username=“sa“ password=“"
driverCassName=“org.hsqldb.jdbcDriver”
url="jdbc:hsqldb:file:/home/aluno/bd/contatos;shut
down=true”/>
• Lembre-se que não deve haver quebra de linha no
atributo URL
Instalação do Driver do Banco no
Tomcat
• Como o pool de conexões é mantido pelo próprio
Tomcat, mas a aplicação irá usa-lo para enviar
comandos SQL ao banco, as classes do driver
JDBC do HDSQLDB devem ser copiadas para a
pasta common/lib
• Cp $HOME/hsqldb/lib/hsqldb.jar $HOME/apache-
tomcat-*/common/lib
• Esta cópia deve ser feita mesmo que o DataSource
seja configurado no META-INF/context.xml da
aplicação em vez de no server.xml do Tomcat
• Lembre de reiniciar o Tomcat, para que ele
incorpore o novo JAR ao seu classloader
Uso de DataSources pela aplicação
via JNDI
• A aplicação usa pool de conexão por meio do JDNI, e
não torna conhecimento dos parâmetros de configuração
JDBC
• Eis o código para se obter uma conexão:
• (tratamento de exceções omitido para simplificar)
Initial Context ctx= new InitialContext();
Ds = (Datasource)
ctx.lookup(“java:comp/env/jdbc/Contatos”);
Connection com = ds.getConnection();
• E para devolver a conexão ao pool, basta fecha-la como
se fosse uma conexão comum
com.close();
Exemplo de DataSource
• O instrutor irá fornecer o arquivo exemplo3.3.zip que

contém uma aplicação que lista os registros do banco de
dados HSQLDB de contatos criado anteriormente
• O exemplo utiliza o arquivo META-INF/context.xml para
definir o DataSource, e contém um buildfile que faz a
compilação e deployment da aplicação no Tomcat
• É necessário editar o context.xml para indicar o caminho
correto para o banco de dados
• Após o deployment, verifique no Admin a presença do
DataSource dentro do contexto do exemplo3.3
Aula 4
Configurações de Segurança
• Introdução à segurança declarativa do Java EE
• Autenticação HTTP BASIC e DIGEST
• Usuários, roles e resource-collecions do Java
EE
• Encriptação de senhas
• Autenticação Form-based
Introdução a segurança declarativa do
Java EE
• A idéia é que o desenvolvedor escreva o mínimo
possível do código para autenticar usuários e
autorizar o acesso às páginas da aplicação
• Este controle deve ser delegado para o servidor
de aplicações, que poderá fazê-lo de forma mais
flexível e segura
• A configuração é feita em duas partes:
– No descritor da aplicação (web.xml) são definidas
regras de controle de acesso
– Na configuração do servidor (server.xml ou
context.xml) são definidos os bancos de dados de
usuários e roles
Autenticação HTTP BASIC e DIGEST
• O protocolo HTTP prevê três mecanismos de
autenticação
• BASIC envia a senha do usuário em texto
(codificada em UUENCODE)
• DIGEST envia um hash da senha
• CLIENT-CERT exige a instalação de um
certificado digital X-400 no navegador do cliente,
devidamente assinado por uma CA
• A senha fornecida pelo usuário no BASIC ou
DIGEST é mantida em memória pelo navegador,
que a retransmite a cada página requisitada
Qual mecanismo escolher?
• O BASIC é o único obrigatório, e é seguro apenas
se usado em conjunto com SSL / TLS
• Versões recentes do Firefox e IE suportam DIGEST,
que é seguro por si só
• O CLIENT-CERT é pouco usado na prática pelas
dificuldades logísticas de distribuição dos
certificados digitais para os usuários
• Em nenhum destes mecanismos a aplicação tem
controle sobre a aparência da janela de login exibida
pelo navegador
• Não existe um logout devido a natureza stateless do
HTTP
Usuários, roles e resource-
collections do Java EE
• No descritor da aplicação, é definido qual
o método de autenticação a ser utilizado
• Além disso, padrões de URLs são
agrupadas e são definidos os usuários e
roles (grupo de usuários) com acesso ao
conjunto de URLs
• Podem haver páginas públicas e restritas
na mesma aplicação
Definição do Mecanismo
• Não são especificados os usuários individuais, e sim
as roles as quais eles devem pertencer
<security-role>
<role-name>usuario</role-name>
</security-role>
<security-role>
<role-name>administrador</role-name>
</security-role>
• O web.xml também indica o mecanismo de
autenticação para a aplicação
<login-config>
<auth-method>BASIC</auth-method>
<relm-name>Exemplo de segurança</realm-name>
</login-config>
Páginas Protegidas
• Então um conjunto de <url-pattern> é vinculado a um ou mais
<role-name> dentro de um <security-constraint>, criando uma
área de páginas protegidas dentro da aplicação
• <security-constraint>
• <web-resource-collection>
• <web-resource-name>
• Paginas do usuário
• </web-resouce-name>
• <url-pattern>/usuarios/*</url-pattern>
• </web-resource-collection>
• <auth-constraint>
• <role-name>usuario</role-name>
• </auth-constraint>
• </security-constraint>
Exemplo de segurança BASIC
• O instrutor irá fornecer o exemplo de

configuração de segurança no arquivo
exemplo3.4.zip
• Este exemplo contém apenas páginas JSP, não
havendo necessidade de compilar classes Java,
por isso não inclui um buildfile para o Ant
• Basta copiar a pasta exemplo3.4 gera pela
descompactação do zip para a pasta webapps
do Tomcat:
Criação dos Usuários
• A configuração padrão do Tomcat já define no server.xml

um banco de dados de usuários e senhas, que é
utilizado pelas aplicações Manager e Admin
• Este banco de dados é o arquivo conf/tomcat-users.xml
• Acrescente dois usuários, um com cada perfil pedido
<user username=“chefe” password=“boss”
roles=”administrador”/>
<user username=“fulano” password=“testando”
roles=“usuario” />
• E reinicie o servidor
Configuração do Realm
• Um banco de dados de usuários e senhas no tomcat
é chamado de Realm. Eis a definição do Realm
padrão (já vem com o Tomcat)
<GlobalNamingResources>
<Resource name="UserDatabase" auth="Container"
type="org.apache.catalina.UserDatabase"
factory="org.apache.catalina.users.MemoryUserD
atabaseFactory"
pathname="conf/tomcat-users.xml" />
</GlobalNamingResources>
• Este realm pode ser editado pelo Admin sem a
necessidade de reiniciar o Tomcat
Vinculação do Realm
• Como configuração padrão vincula o Realm ao

Engine, ele está disponível a todos os Hosts e
consequentemente a todas as aplicações
(contexts)
<Engine name="Catalina"
defaultHost="localhost">
…
<Realm
className="org.apache.catalina.realm.UserDat
abaseRealm"
resourceName="UserDatabase"/>
Exercício
• O Tomcat já está configurado com um Realm
• Os usuários fulano e chefe já foram criados,
respectivamente com os perfis usuários e
administrador
• Já foi feita a instalação do exemplo3.4, via auto-
deploy como um pacote WAR aberto
• Então podemos entrar na aplicação
• http://127.0.0.1/exemplo3.4
• Escolha o link “Páginas dos usuários”
• Faça login como “fulano” senha “testando”
<Realm
className="org.apache.catalina.realm.UserDat
abaseRealm"
resourceName="UserDatabase"/>
Exercício
• Entre no admin e edite o usuário “boss”

para acrescentar a ele também o perfil
“usuario” (não é preciso reiniciar o Tomcat)
Encriptando Senhas
• Note que, no arquivo tomcat-user.xml, as senhas
estão em claro, o que na maioria dos casos não
é desejado
• Todos os realms do Tomcat reconhecem o
atributo digest para especificar o algoritmo de
hash utilizado para criptografar as senhas
• Para gerar as senhas encriptadas, utilize a
classe java.security.MessageDigest do Java SE
• Note que as senhas continuam sendo
transmitidas em claro do navegador para o
Tomcat se for usado o BASIC!
O que é um algoritmo de hash
• É um algoritmo que gera um número bem grande,

aparentemente aleatório, á partir de um bloco de
informações
• Qualquer mudança do bloco gera um novo número
(chamado valor hash)
• Não é matematicamente possível recriar o bloco de
informações original á partir do valor do hash
• De modo que mesmo o administrador Tomcat não
consegue ver as senhas cadastradas pelos usuários –
ele pode apenas configurar uma nova senha
Exercício 1/2
• Termine o Tomcat
• Edite o arquivo server.xml como se segue:
• <Realm
className="org.apache.catalina.realm.UserDatabas
eRealm" resourceName="UserDatabase“
digest=“MD5”/>
• Note que, embora o banco de dados de senhas seja
definido em um <Resouce>, quem valida as senhas
é um <Realm>
• Abra para edição o tomcat-users.xml
• Compile o programa CriptografaSenha.java,
fornecido pelo instrutor, para gerar as versões
criptografadas de cada senha no arquivo
Exercício 2/2
• Por exemplo, para criptografar a senha do
“fulano” faça:
java CriptografaSenha MD5 testando
E a entrada corresponde em tomcat-
users.xml ficaria assim
<user username=“fulano”
password=“ca9cslslasd383828944332”
roles=“usuarios”/>
• Com todas as senhas encriptadas, inicie o
Tomcat e use o exemplo3.4 para verificar que as
senhas criptografadas são reconhecidas
(parte II)
• Nesta aula, continuamos a apresentação
dos recursos de segurança do Java EE e
do Tomcat, incluindo o uso de SSL / TLS
(criptografia) e depois seremos
apresentados ás configurações de hosts
virtuais e de logging
• Tópicos:
– Configurações de segurança
– Configuração de hosts virtuais
• Autenticação via banco de dados

• Autenticação via diretório LDAP
(OpenLDAP)
• Segurança programática do Java EE
• Restrições de Ip / métodos HTTP pelo
Tomcat
• Conexões seguras (SSL / TLS) no Tomcat
Autenticação via Banco de Dados
• O elemento <Realm> permite que seja
especificada a classe responsável por fazer a
validação de login se senha
• Uma das opções é o DataSourceRealm, que
obtém usuários, senhas e roles de uma
DataSource JNDI
• É possível configurar o nome das tabelas e das
colunas consultadas, de modo que o Tomcat
pode ser configurado para utilizar praticamente
qualquer banco de dados de usuários gerado
por outros sistemas
Definição do DataSourceRealm
• Eis a definição de um realm baseado em banco de dados
<Realm debug=“0”
className=“org.apache.catalina.realm.DataSourc
eRealm”
dataSourceName=“jdbc/Contatos”
Digest=“MD5”
userTable=“usuarios”
userNameCol=“login” userCredCol=“senha”
userRoleTable=“grupos”
roleNameCol=“role”/>
• A definição do DataSource “jdbc/Contatos” é a mesma vista

na aula anterior
Exercício 1/5
• Aproveitando o banco de dados de contatos já
criado, use o Database Manager do HSQLDB para
criar as seguintes tabelas:
CREATE TABLE usuarios (
login varchar(15) not null primary key,
senha varchar(32) not null);
CREATE TABLE grupos (
login varchar(15) not null ,
role varchar(32) not null,
primary key (login,role) );
• Os Comandos SQL deste slide e do próximo estão
no arquivo usuários.sql junto aos exemplos do
curso)
Exercício 2/5
• Insira dois usuários de teste

insert into usuarios values ('sicrano',
'caa9c8f8620cbb30679026bb6427e11f'); insert into
usuarios values ('gerente',
'ceb8447cc4ab78d2ec34cd9f11e4bed2');
• As senhas são respectivamente “testando” e “boss”
• Além dos seu roles
insert into grupos values ('sicrano', 'usuario');
insert into grupos values ('gerente', 'usuario');
insert into grupos values ('gerente',
'administrador');
Exercício 3/5
que contém uma versão do exemplo 3.5 visto na
aula anterior
• A diferença é que este exemplo define um
DataSource e um Realm, obtendo as senhas do
banco de dados em vez do tomcat-users.xml
• Descompacte o arquivo em sua pasta home
• Ajuste o path para o banco de dados no arquivo
META-INF/context.xml do exemplo
• Como foi configurado um novo realm para o
contexto, ele não utiliza o realm do host
Exercício 4/5
• Remova o server.xml o <valve> de single sign-on e
reinicie o Tomcat
• Crie um pacote war contendo todo o conteúdo do
exemplo4.1
• Jar cvf exemplo4.1.war –C exemplo4.1
• Faça o deploy da aplicação pelo Manager ou pela
cópia do pacote war (auto-deploy)
• Só não pode ser usado o pacote aberto, pois neste
caso o descritor não-padrão context.xml não será
processado
• Então a aplicação não terá seu realm nem o
DataSource utilizado pelo realm
Exercício 5/5
• Finalmente teste a aplicação pela URL

• http://127.0.0.1/exemplo4.1
• Lembre-se de usar os logins
“sicrano/testando” e “gerente/boss”
Autenticação via diretório LDAP
(OpenLDAP)
• O Tomcat também fornece o JNDIRealm que
permite a autenticação contra serviços de
diretório LDAP como o OpenLDAP, Fedora
Directory Server, Novell NDS e Microsoft AD
• Entretanto a configuração deste ambiente de
testes é bastante intensiva e muito demorada
para a carga horária deste curso
• Consulte os manuais do Tomcat para mais
informações
Logout
• Como visto, só é possível fazer explicitamente
um logout com a autenticação form-based
• Neste caso, basta encerrar a sessão HTTP,
chamando HttpSession.invalidate()
• Mas nada obriga o usuário a fazer o logout, e o
servidor não tem como saber se o usuário
deixou o site ou fechou seu navegador
• As sessões HTTP (e consequentemente os
logins) são invalidados por inatividade, conforme
configuração do descritor (web.xml)
Logout por inatividade
• Eis como mudar o tempo de inatividade para 10
minutos (o padrão do Tomcat é de 30 minutos)
• Basta acrescentar no web.xml da aplicação em
WEB-INF ou então modificar o web.xml padrão
na pasta conf
<session-config>
<session-timeout>10</session-timeout>
</session-config>
• O tempo de inatividade pode ainda ser
configurado programaticamente chamando
HttpSession.setMaxInactiveInterval() e
passando o tempo em segundos
Restrições de IP / Métodos HTTP pelo
Tomcat
• Os recursos padrão de segurança do JavaEE
prevêem ainda:
• Restrição de métodos HTTP
• Restrição ao uso de uma conexão segura
• Além disso, o Tomcat pode ser configurado para
impor restrições de firewall baseado em:
• Nomes de host do navegador
• Endereço Ip do cliente
Exemplo de Restrições No Descritor
web.xml 1 / 2
• Muitos administradores querem garantir que certas
páginas não possam ser acessadas via GET, mas
apenas POST para evitar ataques de inserção de HTML
e de Cross-Site Scripting
• Relacione dentro do elemento <web-resource-collection>
os nomes dos métodos HTTP autorizados:
<security-constraint>
<web-resource-collection>
<url-pattern>/admin/*</url-pattern>
<web-resource-collection>
</security-constraint>
Exemplo de Restrições No Descritor
web.xml 1 / 2
• Para garantir que certas páginas só possam ser
acessadas por meio de conexões seguras
(criptografadas)
• Acresctente ao elemento <security-constraint> o
elemento <transport-garantee>
<security-constraint>
...
<user-data-constraint>
<transport-guarantee>
CONFIDENTIAL
</transport-guarantee>
</user-data-contraint>
</security-constraint>
Firewall Interno do Tomcat
• As válvulas RemoteAddrValve e RemotehostValve
permite definir regras de firewall em um engine, host
ou contexto
• Por exemplo, para aceitar apenas hosts do domínio
empresa.com.br
<Valve
className=“org.apache.catalina.valves.Re
moteHostValve”
allow=“.*.empresa\.”com\.br”/>
• Ou então, para aceitar apenas requisições da rede
local da empresa, 192.168.0.0/24
<Valve
className=“org.apache.catalina.valves.Re
moteAddrValve” allow=“192\.168\.0\..*”/>
Regras de Host e Endereço IP
• Note que os valores dos atributos allow e deny das
válvulas de firewall do Tomcat utilizam expressões
regulares do pacote Jakarta Regexp
• http://jakarta.apache.org/regexp
• Em geral elas seguem mesma sintaxe do grep e Perl
• Podem ser especificadas várias expressões, separadas
por vírgulas
• Se um dos atributos for omitido, assume-se a expressão
regular “.*” que aceita qualquer coisa
Exercício
• Verifique o endereço IP do computador vizinho com
o comando ifconfig
• Modifique o exemplo 4.1 para incluir uma válvula
negando o acesso dele ao exemplo (modifique o
context.xml da aplicação)
• Faça o undeploy e novo deploy pelo Manager para
efetivar a mudança
• Confirme a presença da válvula pelo Manager
• Verifique se o vizinho consegue ou não acessar a
aplicação
• Verifique também se o firewall local iptables não
está impedindo a conexão
Conexões seguras (SSL / TLS) no
Tomcat
• O Tomcat suporta, por meio do JSSE (Java Secure
Sockets Extensions) conexões encriptadas nos padrões
SSL e TLS, ou seja, conexões HTTPS:
• O JSSE é padrão no Java SE desde a versão 1.4
• Na maioria dos casos, prefere-se que a criptografia seja
realizada por um servidor web nativo atuando como
front-end, ou por um “acelerador web” (proxy reverso)
– Esta configuração serã vista nas próximas aulas (Integração do
Tomcat com o Apache httpd)
Certificados Auto-Assinados
• Sites de produção utilizam um certificado adquirido em

uma empresa reconhecida por padrão pelos
navegadores, como Verisign
• Para testes e intranets, é possível gerar um certificado
“auto-assinado” , que traz as mesmas garantias de
segurança que um certificado “oficial”
• O que o certificado “oficial” garante é que o usuário está
acessando o site real e não uma imitação
• Por isso o navegador irá alertar o usuário quanto a
certificados auto-assinados
Criando um Certificado para o
servidor 1/2
• Primeiro, é necessário criar um KeyStore usando o
keytool do JavaSE
keytool –genkey –alias tomcat –keyalg RSA
• Tome nota da senha fornecida
• Forneça os dados sobre sua empresa e localização,
que serão registrados no certificado
• Use a mesma senha para keystore (antes de
perguntar pelos dados pessoais) e depois para a
chave do Tomcat (depois de pedir pelos dados
pessoais)
• Lembre que estamos rodando o Tomcat com o
nosso usuário; em produção, o keystore seria do
próprio usuário Tomcat
Criando um Certificado para o
Servidor 2/2
• O resultado é o arquivo .keystore na pasta home
do usuário, que não deve ser acessível a
ninguém mais
ls –l $HOME/.keystore
• A opção –keystore do keytool permite indicar
um caminho diferente para o KeyStore
• Consulte os manuais do Tomcat para o
procedimento caso você queira utilizar um
certificado “oficial” em um servidor de produção
Ativando o Conector SSL 1/2
• O conector que aceita conexões criptografadas está
comentado no server.xml padrão do Tomcat, basta
descomentá-lo
<Connector port="8443" protocol="HTTP/1.1"
SSLEnabled="true" maxThreads="150"
scheme="https" secure="true"
keystorePass=“secreto”
keystoreFile=“/home/aluno/.keystore”
clientAuth="false" sslProtocol="TLS" />
• Ajuste os atributos destacados ao seu keystore
Ativando o Conector SSL 2/2
• Caso a porta 8443 seja alterada (por exemplo,
para o padrão 443) deve se alterado também o
redirectPort do conector HTTP não encriptado:
<Connector port="8080“
protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443" />
• Este parâmetro faz com que o Tomcat
automaticamente redirecione conexões para
páginas que exigem conexões seguras
Exercício 1/2
• Crie um keystore e ative o conector SSL conforme
apresentado nos slides anteriores
• Experimente acessar qualquer aplicação via SSL,
por exemplo o Manager:
• https://127.0.0.1:8443/manager/html
• O navegador irá reclamar duas vezes do certificado
auto-assinado
• A segunda reclamação é porque o certificado não
corresponde ao nome DNS oficial do servidor sendo
acessado
• Clique OK em ambas
Exercício 2/2
• Conseguindo o acesso criptografado ao Manager,
modifique o descritor web.xml do exemplo4.1 para
exigir conexões SSL para páginas do administrador,
usando o modelo apresentado anteriormente nesta
aula
• Gere um novo pacote war para a aplicação
• Faça o undeploy e novo deploy pelo Manager
• Confirme que, ao entrar nas páginas
administrativas, o navegador passará
automaticamente a usar URL´s HTTPS:
• (O navegador continuará a usar conexões SSL
quando sair das páginas administrativas)
Configuração de Hosts Virtuais
• O que é um host virtual

• Configuração de Hosts Virtuais
• Uso das aplicações administrativas em
hosts virtuais
O que é um Host Virtual
• As duas formas de se configurar hosts virtuais
são indiferentes para o Tomcat
• Nos dois casos, basta acrescentar um novo
elemento <Host> ao server.xml e decidir que
aplicações serão configuradas nele
• Cada host pode ser sua própria pasta para auto-
deploy
• É possível gerar logs separadas para cada host,
ou definir, válvulas e DataSources
Exercício 1/2
• Edite (como root) o arquivo etc/hosts e acrescente a linha:

127.0.0.1 hostvirtual
• Crie a pasta $HOME/maiswebapps
• Edite o arquivo server.xml e acrescente a seguinte definição
de Host, mas dentro do único elemento Engine
<Host name=“hostvirtual”
appBase=“home/aluno/maiswebapps”
autoDeploy=“true” />
• Verifique no Admin a presença de dois Hosts
Exercício 2/2
• Acesse uma aplicação qualquer no host padrão,
utilizando “127.0.0.1” ou “localhost” na URL
• Instale uma aplicação simples (como o exemplo1.1) no
novo host virtual, copiando seu pacote WAR para a
pasta $HOME/maiswebapps
• Não tente usar o Manager para o Deployment, pois ele
ainda não foi configurado para host virtual
• Acesse esta aplicação no host virtual usando uma URL
como: http://hostvirtual:8080/exemplo1.1
Aplicação administrativa X hosts
virtuais
• Cada host tem que ser configurado com sua
própria instância do Manager
• Por outro lado, um único Admin é capaz de
gerenciar a configuração de todos os hosts
• Há duas formas de ser acrescentar um Manager
a um host
– 1. Acrescentar um elemento <Context> apontando
para o WAR do Manager, em
server/webapps/manager ao host virtual no server.xml
– 2. Criar uma pasta conf/Catalina/hostvirtual e copiar
ela o arquivo conf/Catalina/localhost/manager.xml
Exercício
• Configure o Manager para o host virtual
recém-criado, conforme as instruções no
slide anterior
• Acesse o novo Manager, e observe que
ele relaciona um conjunto de aplicações
diferente do Manager do localhost
• Como o realm que autentica o acesso ao
Manager foi configurado no Engine, o
mesmo login e senha vale para o Manager
do host virtual
Aula 5
• Nesta aula somos apresentados aos
recursos de integração do Tomcat com
servidores web nativos, especialmente o
Apache, e vemos como estes recursos
podem ser utilizados para a construção de
clusters de servidores de aplicações
• Tópicos
– Integração com Apache Httpd
– Configurações de clustering (parte 1)
Integração com o Apache Httpd
• Vantagens de usar um servidor web nativo
como front-end para o Tomcat
• Conectores HTTP e AJP do Tomcat
• Como servir páginas estáticas com
Apache e Servlets / JSP com Tomcat
• Integração x Segurança e logging
Servidores Nativos x Tomcat 1/2
• Situações onde espera-se que servidores web
nativos tenham melhor performance que o
Tomcat
– Grandes quantidades de usuários simultâneos,
navegando em sites na sua maior parte estáticos
– Download de arquivos volumosos, como músicas,
vídeos e relatórios em PDF
– Grandes quantidades de conexões encriptadas
– Uso de aceleradores de hardware para criptografia
Servidores Nativos x Tomcat 2/2
• Soluções onde um servidor nativo se torna
necessário para complementar o Tomcat
– Partes do site usando outras tecnologias, por
exemplo CGI,PHP, ASP e Cold Fusion
– Uso de plug-ins de servidores web (módulos
de Apache ou ISAPI)
– Proxies reversos e aceleradores web
– Distribuidores de carga
Arquitetura do Tomcat
(Simplificada)
Servidor de Aplicações Tomcat
Navegador
Web Catalina
Coyote (Container Web)
(Conector HTTP)
Servidor
Web
Jasper
JK (Compilador de JSP)
mod_jk (Conector AJP)
Conectores HTTP e AJP
• Os conectores são os componentes do Tomcat
responsáveis por receber conexões de redes e
repassar os comandos recebidos para o
container web (Catalina)
• O Tomcat pode ser utilizado diretamente como
um servidor web apenas porque ele possui um
conector que entende diretamente o protocolo
HTTP
• Quando existe outro servidor web entre o
Tomcat e o navegador do usuário, o Conector
JK permite comunicação otimizada usando o
protocolo AJP
O mod_jk
• É um plug-in de servidor web que acrescenta o
suporte ao protocolo AJP
• Há versões para Apache, ISAPI e NSAPI
• Deve ser compilado em relação à versão
específica e plataforma do servidor web
• Com sorte, poderá ser encontrado um binário
pré-compilado para o seu servidor (mas
verifique a versão)
• Daqui em diante assume-se que o servidor
web é o Apache 2.x fornecido com sua
distribuição do Linux
Instalando o mod_jk
• Há três formas de se obter e instalar o mod_jk
em Linux
1. Utilizando um pacote fornecido pela sua
distribuição
2. Utilizando binários pré-compilados fornecidos pela
ASF
3. Compilando você mesmo à partir dos fontes
• Com o Fedora 6, teremos que usar a opção
(3), mas versões posteriores da ditribuição
voltaram a trazer pacotes do mod_jk
Instalando o Pacote 1/2
• Neste exemplo, considera-se o uso da
distribuição Fedora Core 4
• Visite
http://download.fedora.redhat.com/pub/fedora/lin
ux
• Entre na pasta core/4/i386/os/Fedora/RPMS/
• Baixe os arquivos mod_jk-1.2.6-
3jpp_4fc.i386.rpm e mod_jk-manual-1.2.6-
3jpp_4fc.i386.rpm para sua pasta home
• Como root (su), instale os pacotes
– # rpm –ivh mod_jk*
Instalando o Pacote 2/2
• Opcionalmente, baixe os pacotes na pasta de
atualizações, visitando o mesmo servidor mas
entrando na pasta core/updates/4/i386/
• Instale então os pacotes encontrados, mas
poderá ser necessário instalar também outras
atualizações
• Ou então, utilize o Yum, que instala
automaticamente dependências e atualizações:
– # yum install mod_jk mod_jk-manual
• Prossiga para a configuração do mod_jk
Instalando binários pré-
compilados 1/2
• Verifique a versão do Apache instalada em sua
distribuição
– # apachectl status
– # rpm –q httpd
• Visite http://www.apache.org/dist/tomcat-
connectors/jk/binaries/ e procure pelo binário
específico para a sua plataforma e versão do
Apache
• Por exemplo, para o Fedora Core 2 em
processador Intel, temos o arquivo jakarta-
tomcat-connectors-jk-1.2.6-linux-fc2-i386-
apache-2.0.50.so
Instalando binários pré-
compilados 2/2
• Como root, copie o arquivo para a pasta
de módulos de extensão da sua instalação
do Apache
• No Fedora Core, a pasta é
/usr/lib/httpd/modules
Compilando o mod_jk 1/2
• Visite http://www.apache.org/dist/tomcat/tomcat-
connectors/jk/source e localize o arquivo
contendo os fontes da versão mais recente
• Por exemplo , tomcat-connctors-1.2.23-src.tar.gz
• Descompacte em sua pasta home
• Localize o executável apxs, que é parte do
Apache: tome nota do caminho
• Na maioria das distribuições do Linux, será
necessário instalar o pacote httpd-devel ou
similar
Compilando o mod_jk 2/2
• Uma vez que o comando apxs esteja disponível,
entre na pasta onde foram compactados os
fontes do mod_jk e prossiga com a compilação
$ cd $HOME/tomcat-connectors-*-src
$ cd native
$ ./configure –with-apxs=/usr/sbin/apxs
$ make
$ su
# make install

Pacotes -devel
• O Apache em si não necessita ser recompilado
para a compilação de um módulo
• Mas são necessários, além das ferramentas
para desenvolvimento C (gcc, make, binutils) os
cabeçalhos e bibliotecas para a compilação de
módulos do Apache
• Elas são fornecidas por pacotes –devel
correspondentes aos pacotes do Apache, e suas
respectivas dependências. No Fedora 6:
– httpd-devel-2.2.3-5
– apr-devel-1.2.7-10
– apr-util-devel-1.2.7-3
Configuração do mod_jk 1/3
• Podemos ou editar diretamente o httpd.conf ou então
usar a pasta /etc/httpd/conf.d. A segunda opção é
considerada melhor prática
• Crie o arquivo /etc/httpd/cont.d/jk.cont.
LoadModule jk_module modules/mod)jk.sc
JKWorkersFile
/etc/httpd/conf.d/workers.properties
JKLogFile /var/log/httpd/mod_jk.log
JKLogLevel error
JkMount /exemplo4.2 no0
JkMount /exemplo4.2/* no0
• Note que a linha abaixo da diretiva JkWorkersFile é na
verdade continuação da mesma linha
• Agora é necessário fornecer o arquivo de
configuração do próprio mod_jk, indicado pela
diretiva JkWorkersFile no caso
/etc/httpd/conf.d/workers.properties:
worker.list=no0
worker.no0.type=ajp13
worker.no0.host=127.0.0.1
worker.no0.port=8009
• Inicie (ou reinicie) o Apache
#service http restar
• Garanta que o conector HTTP do tomcat esteja
escutando conexões na porta 8080, para não
entrar em conflito com o Apache
• Garanta também que o Conector AJP padrão
esteja configurado para a porta 8009
• Em distribuições com SELinux (como é o caso
do Fedora Linux) a política de segurança para o
Apache irá interferir com o mod_jk. Então
desabilite o SELinux com o comando:
# setenforce 0
Configuração do Apache
• Administradores do Apache estão acostumados
a editar diretamente o httpd.conf, ou então,
serm.conf
• Mas distribuições recentes (e nem tanto) do
Linux utilizam o diretório conf.d, cujo conteúdo é
incluido explicitamente pelo httpd.conf usando
comando:
– Include conf.d/*
• Não existe ordem entre as diretivas de
configuração dentro do httpd.conf ou qualquer
arquivo incluído; então as configurações do
mod_jk podem entrar em qualquer lugar
Testando o mod_jk
• Garanta que o exemplo 4.1 esteja instalado no
Tomcat, se necessário use o Manager,
acessando o Tomcat pela porta 8080
• Inicie o Tomcat, se ele não estiver rodando
• Acesse a URL http://127.0.0.1/exemplo4.2
• O exemplo 4.1 deverá funcionar normalmente,
inclusive a autenticação
• Acesse o exemplo 4.1 também pela porta 8080,
apenas para ter certeza de que as duas opções
estão disponíveis, e que não é o Tomcat
respondendo na porta 80
Se algo der errado
• Verifique o log de erros do Apache
(/var/log/httpd/error_log)
• Verifique o log de acesso do Apache
(/var/log/httpd/access_log); se ele responder 404 para
aplicações no Tomcat, é porque ele não passou estas
requisições para o mod_jk
• Aumente o nível de log do mod_jkm alterando a linha no
arquivo mod_jk.conf (ou httpd.conf)
– JKLogLevel debug
• Verifique o log do mod_jk (/var/log/httpd/access_log)
• E verifique se o SELinux está desabilitado
Dividindo tarefas entre o Apache
e o Tomcat
• A configuração que fizemos repassa para o
Tomcat todas as requisições direcionadas para
uma determinada aplicação web no Tomcat
• É possível ser mais seletivo, pelo uso das
diretivas JkMount e JkUmount, por exemplo
para deixar que o Apache cuide de arquivos
estáticos como páginas HTML e imagens
• Note que, se isto for feito, eventuais
configurações de controle de acesso terão que
ser duplicadas com os recursos do Apache
Exercício 1/6
• O instrutor fornecerá o arquivo exemplo exemplo5.1.zip
que contém uma aplicação simples, formada por
algumas páginas JSP e HTML
• Inicialmente, vamos acessar esta aplicação diretamente
pelo Apache
• Acrescente o arquivomod_jk.conf a linha
– Alias /exemplo5.1 /home/fernando/exemplo5.1
• E reinicie o Apache
– # service httpd restart
• Agora acesse a aplicação pela URL
http://127.0.0.1/exemplo5.1
Exercício 2/6
• Navegue pelos links exibidos pela aplicação
• Verifique que a página JSP não exibe a data
corrente, e que ela expõe para o navegador os
scriptlets
• Tenha certeza de ter configurado no Tomcat a
válvula de logs de acesso, conforme as
instruções na aula passada
• Verificando os logs de acesso do Tomcat e do
Apache, e verifique que os arquivos do exemplo
5.1 aparecem apenas no log de acessos do
Apache
Exercício 3/6
• Agora, vamos fazer com que o Tomcat execute
apenas as páginas JSP
• Edite o arquivo mod_jk.conf e acrescente a linha
– JkMount /exemplo5.1/*.jsp no0
• Reinicie o Apache
• Temos que fazer o deploy do exemplo 5.1 no
Tomcat, porém mantendo o pacote aberto e sua
localização na pasta home do usuário
• Então defina um elemento <Context> no
server.xml ou então use o Manager, conforme a
captura no próximo slide
Exercício 4/6
• Reinicie o Tomcat e navegue novamente pela
aplicação
• Verifique que apenas a página JSP aparece nos
logs de acesso do Tomcat
Exercício 5/6
• Usar extensões de arquivos na diretiva JkMount não é
muito prático para Servlets, por isso veremos uma outra
alternativa
• Edite o arquivo mod_jk.conf
#JkMount /exemplo5.1/*.jsp no0
JkMount /exemplo5.1/*.html no0
JkMount /exemplo5.1/*.gif no0
• Reinicie o Apache e teste novamente a aplicação.
Continuamos vendo no log de acesso do Tomcat apenas
a página JSP
Exercício 6/6
• Uma terceira variação consiste em usar os diretórios na
diretiva JkUnMount
JkUnMount /exemplo5.1/html/* no0
JkUnMount /exemplo5.1/imagens/* no0
• Note que, neste caso, a página inicial index.html será
servida pelo Tomcat
• OBS: a diretiva JkUnMount só existe no mod_jk 1.2.8
em diante
Integração x Segurança e
logging 1/2
• O uso do Apache como fornt-end para o Tomcat
oferece várias oportunidades de otimização de
desempenho (ex: mod_proxy), mas acaba
compilando um pouco a configuração e
administração de ambos
• Aplicações com controle de acesso devem
preferencialmente ser servidas inteiramente
pelo Tomcat, a não ser que as partes estáticas
(como imagens) possam ser consideradas de
acesso público
• Embora o Apache reconheça autenticação
HTTP, ele não reconhece form-based
Integração x Segurança e
logging 2/2
• Não á necessidade de habilitar SSL no Tomcat;
basta faze-lo no Apache
• Com o Tomcat na retaguarda do Apache, ele
pode ser melhor protegido por um firewall
• O Tomcat na retaguarda também facilita a
evolução do ambiente para clusters
• Basta o log de acessos do Apache, já que ele
registra tanto as URLs servidas por ele quanto
as servidas pelo Tomcat
• Erros de aplicação e banco de dados estarão
nos logs do Tomcat, não do Apache
Configurações de Clustering
(Parte I)
• Conceitos de clustering web Java EE
• Arquitetura de clustering do Tomcat 5
• Configuração de clusters para
balanceamento de carga
• Monitoração de Clusters
Conceitos de clustering web
Java EE
• A plataforma Java EE prevê desde a sua
concepção a execução de aplicações em
ambiente de cluster
• Este recurso vem quase “de graça” para o
desenvolvedor, enquanto que outras
plataformas ele exige programação cuidadosa e
especializada
• No caso de aplicações web, a natureza do
protocolo HTTP ao mesmo tempo facilita e
impõe restrições
Cluster Web Java EE
Navegador
Web
Balanceador ou
Distribuidor
Container Container
Web 1 Web 2
Balanceador ou Distribuidor
• É o componente que recebe as requisições do
navegador e as encaminha para um dos nós do
cluster
• Cria para o usuário no navegador a ilusão de
que existe apenas um único servidor em vez de
vários containers web independentes
• Há várias estratégias para sua implementação:
– Switches e roteadores especializados – “layer 7”
– Múltiplos endereços IP para um mesmo nome DNS
(DNS round-robin)
– Proxy reverso ou servidor front-end
Distribuição de Carga x
Tolerância a Falhas
• O cluster pode se limitar a distribuir a carga entre os
vários nós
• Por exemplo, um servidor atingiu o limite de sua
capacidade, então acrescenta-se um segundo servidor
• Ou então o cluster pode fornecer também a tolerância a
falhas
• Neste caso, os usuários que eram atendidos por um nó
falho serão automaticamente redirecionados para um
dos nós sobreviventes
• Não é trivial oferecer a tolerância a falhas sem perder
atividades “em progresso”
Estado da Aplicação no HTTP
• O HTTP é um protocolo sem estado, então
qualquer requisição poderia ser entregue a
qualquer nó do cluster
• Um mesmo usuário poderia ser a cada página
atendido por um servidor diferente
• Entretanto, aplicações web reais utilizam
artifícios como cookies e sessões HTTP para
manter o estado de um usuário particular (por
exemplo, uma cesta de compras)
• Este estado tem que ser replicado entre os nós
do cluster para que haja tolerância a falhas
Arquitetura de clustering do
Tomcat 5
• Sessões HTTP são implementadas por meio de
um cookie “identificador de sessão” conforme
manda a especificação JavaEE
• Para que um usuário possa recuperar as
informações armazenadas na sua sessão ele
deve ser atendido sempre pelo mesmo servidor
• Então o balanceador tem que reconhecer o
cookie um identificador do nó
• A arquitetura para tolerância a falhas será
apresentada na Aula 6
Clusters para balanceamento de
carga
• O mod_jk do Apache pode ser configurado para
atuar como um balanceador de carga entre
vários servidores Tomcat
• Ele inclusive é capaz de lidar com servidores de
capacidades diferentes e distribuir a carga
(usuários / sessões HTTP) proporcionalmente
• Os servidores não precisam nem mesmo usar o
mesmo SO!
Instalando os Nós do Cluster 1/3
• Para simular um cluster em um único computador,
precisamos de duas instalações do Tomcat
• Crie em sua pasta home o diretório cluster
– $mkdir $HOME/cluster
• Descompacte o Tomcat dentro desta pasta
– $ cd $HOME/cluster
$ unzip ../apache-tomcat*.zip
• Renomeie a primeira instalação para o no0 e
descompacte novamente o Tomcat
– $ mv apache-tomcat-* no0
$ unzip ../apache-tomcat*.zip
$ mv apache-tomcat-* no0
• Edite o conf/server.xml do segundo Tomcat (no1) para
mudar as portas TCP, evitando o conflito com o no0
<Server port=“8105” shutdown=“SHUTDOWN”>
...
<Connector port=“8180”
...
<Connector port=“8109”
...
• Nas duas instalações do Tomcat (no0 e no1), edite o
arquivo conf/tomcat-users.xml para permitir o uso do
Manager:
<user username=“tomcat” password=“tomcat”
roles=“admin,manager”/>
• Garanta que não haja nenhum outro Tomcat em
execução, e inicie cada um dos dois nós do cluster
$ cd no0/bin ; chmod a+x *.sh ; ./startup.sh
$ cd ../no1/bin ; chmod a+x *.sh ; .startup.sh
• Acesse a aplicação Manager em cada em cada nó,
confirmando que as duas instalações do Tomcat estão
funcionando
– http://127.0.0.1:8080/manager/html (no0)
– http://127.0.0.1:8180/manager/html (no1)
Exemplo de Teste dos Nós do
Cluster 1/4
• O instrutor irá fornecer o arquivo exemplo5.2.zip, que é
uma aplicação simples criada para testar o cluster
• Descompacte o zip dentro da pasta webapps do
primeiro nó do cluster
$ cd $HOME/cluster/no0/webapps
$ unzip $HOME/exemplo5.2.zip
• Compile as classes Java do exemplo, como visto na
Aula 1
$ cd exemplo5.2/WEB-INF/classes
$ export
CLASSPATH=$CLASSPATH:$HOME/cluster/no0/common/lib/se
rvlet-api.jar
$ javac exemplo/*.java
Cluster 2/4
• Copie a aplicação para o segundo nó
$ cd ../../..
$ cp –rf exemplo5.2 ../../no1/webapps
• Altere a página index.jsp no segundo Tomcat

($HOME/cluster/no1/exemplo5.2/index.jsp) para
que a mensagem indique que ela está no
segundo servidor (nó) do cluster
• Utilizando o manager, faça o Reload da
aplicação em ambos os nós do cluster
Cluster 3/4
• Acesse as duas cópias da aplicação:
– http://127.0.0.1:8080/exemplo5.2
– http://127.0.0.1:8180/exemplo5.2
• Verifique que cada URL exibe uma página ligeiramente
diferente, indicando o nome do nó do cluster em que ela
foi acessada
• Verifique ainda que, a cada recarga da página, a
contagem aumenta. O objetivo é simular uma aplicação
com estado armazenado.
• Quando os dois nós Tomcat forem reunidos em cluster,
será necessário ter navegadores diferentes para simular
usuários independentes
Cluster 4/4
• Observe que cada página exibe um
identificador de sessão diferente
Configurando o Distribuidor 1/5
• Agora que temos dois Tomcats e somos

capazes de reconhecer pela “cara” da página
qual dos dois foi acessado, vamos configurar o
mod_jk como distribuidor de carga
• Edite o arquivo mod_jk.conf para permitir o
acesso à aplicação, removendo todas as
diretivas JkMount e JkUnMount criadas
anteriormente, deixando apenas
– JkMount /exemplo5.2 cluster
– JkMount /exemplo5.2/* cluster
• Edite o arquivo workers.properties:
worker.list=cluster
worker.cluster.type=lb
worker.cluster.balance_workers=no0,no1
worker.cluster.sticky session=true
worker.no0.lbfactor=1
worker.no1.lbfactor=1
• Foram definidos dois nós, vinculados a um balanceador,
que é referenciado pelas diretivas JkMount vistas no
slide anterior
• É necessário informar ao Tomcat sobre o identificador
de nó que deve ser acrescentado ao cookie da sessão
HTTP
• Para tal, edite o server.xml de cada um dos dois nós do
cluster, acrescentando no elemento <Engine> o atributo
jvmRoute
<Engine name=“Catalina”
defaultHost=“localhost” debug=“0”
jvmRoute=“no0”>
<Engine name=“Catalina”
defaultHost=“localhost” debug=“0”
jvmRoute=“no1”>
• Termine os dois nós Tomcat do cluster usando o script
shutdown de cada um
• Remova os arquivos de trabalho na pasta work

em cada nó, de modo que sejam descartados
todos os dados armazenados em sessões HTTP
$ rm –rf $HOME/cluster/no0/work/*
$ rm –rf $HOME/cluster/no1/work/*
• Inicie os dois nós Tomcat e reinicie também o
Apache
• Acesse novamente a aplicação, usando agora a
mesma URL, referenciando o Apache, porém
utilizando dois navegadores diferentes:
– http://127.0.0.1/exemplo5.2
• Cada navegador tem que ser atendido por um
servidor diferente, e ter o identificador do nó
anexado ao identificador de sua sessão:
Se algo der errado
• Verifique que os dois servidores Tomcat estão
no ar, acessando-os diretamente pelas portas
8080 e 8180
• Confira os arquivos de configuração server.xml
em cada nó, atentando para os três números de
porta (8085, 8080 e 8009; 8185, 8180 e 8109) e
para o jvmRoute no Engine
• Confira também os arquivos de configuração do
mod_jk, em especial as configurações do cluster
e de cada nó no workers.properties
• Verifique os logs de cada nó Tomcat e do
Apache em busca de mensagens de erro
Status do Cluster 1/2
• O mod_jk é capaz de gerar por conta própria uma
página de status dos nós do cluster, útil para os
administradores
• Para ativar esta página, mapeie uma URL para o
“status” do mod_jk, editando o mod_jk.conf
– JkMount /jk status
• Em seguida, ative a geração da página de status no
worker.properties
– worker.list=cluster,status
– worker.status.type=status
– ...
• Reinicie o Apache (mas não o Tomcat)
Status do Cluster 2/2
• Veja a página de status acessando a URL
http://127.0.0.1/jk
Exercício Opcional 1/2
• Para entender a importância do identificador do
nó no cookie da sessão HTTP e do uso desta
informação pelo balanceador, vamos deixar o
balanceador alterar entre os nós como se
fossem servidores web estáticos, sem
aplicações
• Altere o arquivo workers.properties:
– worker.cluster.sticky_session=false
• Termine os dois Tomcats
• Limpe a pasta work de cada nó
Exercício Opcional 2/2
• Reinicie cada Tomcat e também o Apache

• Abra os dois navegadores e faça cada um acessar a
aplicação passando pelo Apache
(http://127.0.0.1/exemplo5.1)
• Observe como a contagem sempre fica em “1” com a
requisição sendo atendida alternadamente por
servidores diferentes no mesmo navegador
• Veja também que o id de sessão muda a cada recarga
da página, em ambos os navegadores
• O Tomcat não consegue manter o vínculo com a sessão
do usuário!
Aula 6
• Nesta aula finalizamos a apresentação dos recursos de
clustering do Tomcat e temos uma introdução ao
monitoramento e tunning do servidor para obter maior
performance.
• Tópicos:
- Configuração de clustering (parte 2)
- Tunning e monitoração de performance
Configuração de Clustering
(Parte 2)
• Configuração de clusters para tolerância a

falhas
• Erros de aplicação a evitar
• Clusters x Aplicações Administrativas
• Farming Deployer
Clusters Para Tolerância a
Falhas
• Recapitulando, o objetivo agora e simular um cluster
onde os usuários de um servidor Tomcat são
automaticamente e transparentemente migrados para
outro servidor
• Para que isto ocorra, as informações armazenadas na
sessão HTTP devem ser replicadas entre todos os nós
do clusters.
• Desta forma, qualquer nó pode dar continuidade a
atividades iniciadas por outro nó
Tomcat 5 1/2
• O Tomcat utiliza multicast IP para identificar os nós do
cluster que ainda estão ativos
• Na verdade cada nó anuncia sua presença aos demais
utilizando os multicasts
• As informações em si sao transferidas por meio de
conexões TCP regulares para os demais nós existentes
• Se um nó fica muito tempo sem anunciar sua presença,
os demais nós o consideram como inativo e deixam de
lhe enviar informações
Tomcat 5 2/2
• Havendo vários clusters independentes na mesma rede,
cada cluster deve ser configurado com um endereço IP
de multicast diferente
• Quando ocorrerem modificações nas sessões HTTP de
um nó, estas modificações são transferidas por meio de
conexões TCP regulares para os demais nós presentes
• Quando um novo nó entra no cluster (se torna ativo) ele
localiza os demais nós e pede que cada um lhe envie as
informações atuais de todas as sessões HTTP
Configuração de clusters para
Tolerância à Falhas
• O arquivo de configuração padrão server.xml do
Tomcat traz comentado o elemento <Cluster>
que cuida do multicast IP entre os nos de um
mesmo cluster
• Alem disso, deve ser configurado uma válvula
(<Valve>) que faz o envio das modificações
sobre as sessões para os demais membros do
cluster
Configuração de Multicast
no Linux
• Para que o cluster funcione, a rede local tem que estar
permitindo trafego em multicast
• Garanta que seus switches não estão bloqueando este
trafego
• O sistema operacional deve saber para onde enviar
pacotes destinados a um dado endereço de multicast, o
que e feito como parte das configurações de roteamento
estático
route add –net 224.0.0.0 netmask 224.0.0.0
gw 127.0.0.1
• Em um servidor real seria algo como:

route add –net 224.0.0.0 netmask 224.0.0.0
dev ETH0
Exercício 1/8
• Edite o serve.xml do no() e acrescente, dentro do
elemento <Host>
<Cluster className=“org.apache.catalina.cluster.tcp.SimpleTcpCluster”
managerClassName=“org.apache.catalina.cluster.session.DeltaManager”
expireSessionsOnShutDown=“false”
useDirtyFlag=“true”>
<Membership className=“org.apache.catalina.cluster.
mcast.McastService”
mcastAddr=“228.0.0.4”
mcastPort=“45564”
mcastFrequency=“500”
mcastDropTime=“3000” />
<!– continua -->

Exercício 2/8
• Cuidado para não colocar quebras de linha dentro dos
valores dos atributos!
<!– continuacao -->

<Receiver className=“org.apache.catalina.
cluster.tcp.ReplicationListener
tcpListenAddress=“127.0.0.1”
tcpListenPort=“4100”
tcpSelectorTimeout=“100”
tcpThreadCount=“6” />
<Sender className=“org.apache.catalina.cluster.tcp.ReplicationTransmitter”
replicationMode=“pooled”/>
<!–- continua -->

Exercício 3/8

<Valve
className=“org.apache.catalina.cluster.tcp.ReplicationValve”
filter=“.*\.gif;.*\.js;.*\.swf”/>
</Cluster>
• Se você perdeu o modelo, porque o Admin remove

todos os comentários do server.xml, recupere o modelo
original do arquivo ZIP de instalação do Tomcat
• É muita coisa para digitar na mão, a maioria nunca é
alterada pelo administrador
Exercício 4/8
• Edite o server.xml do segundo Tomcat (no1) e
crie o elemento <Cluster> exatamente como no
primeiro Tomcat (no0), exceto:
Receiver className=“org.apache.catalina.cluster.tcp.ReplicationListener”
tcpListenAddress=“127.0.0.1”
tcpSelectorTimeout=“100”
tcpThreadCount=“6” />
• Note que cada nó do cluster abre uma porta

TCP adicional (respectivamente 4100 e 4101)
• Reinicie os dois servidores Tomcat
Exercício 5/8
• Acesse o exemplo5.1 passando pelo Apache
(http://127.0.0.1/exemplo5.1)
• Ele deve se comportar exatamente como no
cluster de distribuição de carga
• Agora vem a parte interessante: termine o
primeiro Tomcat (no0) da forma regular, usando
o script shutdown
• Recarregue o navegador que estava usando
este servidor
• A captura no slide a seguir ilustra o resultado
esperado
Exercício 6/8
• Observe que a página foi gerada pelo no1, entretanto o
identificador da sessão e do no2
• Note que a contagem não se perdeu, indicando que o
estado da sessão HTTP foi preservado
Exercício 7/8
• A página de status do mod_jk deve indicar que o
nó falhou:
Exercício 8/8
• Reinicie o primeiro servidor Tomcat (no0)
• Após alguns segundos, o navegador que estava
sendo atendido por ele voltará
• A página de status do mod_jk não irá indicar o
nó do cluster novamente ativo até que alguma
requisição tenha sido entregue com sucesso a
ele
• Lembre-se de que leva algum tempo até a sua
presença ser notada pelos outros nós do cluster,
e até que ele tenha recebido as informações
das sessões em andamento
Se algo deu errado...
• Verifique com o comando route se existe uma
rota para a rede 224.0..0/3 (classe D, IP
multcast)
• Verifique nos logs dos dois Tomcat e do Apache
por mensagens de erro, como sintaxe inválida
nos arquivos de configuração
• Verifique se as partas quatro TCP utilizadas por
cada nó estão livres
• Páre todos os servidores, remova a pasta work
dos dois Tomcats, e reinicie todos os servidores
Seja Paciente! 1/2
• A simulação de um cluster em um mesmo
computador às vezes pode parecer errática
• O tempo de troca de contexto de um Tomcat
para o outro, especialmente em computadores
em com pouca RAM e vários outros processos
ativos, pode ser longo o suficiente para o
balanceador ou um dos nós acreditar que o
outro nó esteja fora do ar
• E o tempo de recuperação depois de uma
possível falha é de pelo menos um minuto
• Na dúvida, veja a página de status do mod_jk
Seja Paciente! 2/2
• Se acontecer dos dois navegadores serem
atendidos pelo mesmo servidor, porém ambos
os nós estão no ar e configurados corretamente
(mas o balanceador acredita que não)
– Feche o navegador que está no servidor “errado”
(para perder o cookie de sessão HTTP)
– Aguarde alguns segundos e tente novamente
– Ou então reinicie todos os servidores, removendo a
pasta work do Tomcat
• Conexões que migraram para fora de um mó
falho não voltam automaticamente quando este
nó retorna ao cluster
Erros de aplicação a evitar
• O suporte a clustering web do JavaEE é
transparente, desde que o programador não
cometa alguns erros básicos:
– Todos os objetos armazenados na sessão HTTP
devem ser serializáveis
– Uma requisição HTTP deve corresponder a uma
única transação no banco de dados
– Uma transação no banco de dados deve conter
dentro de uma única transação HTTP
– Não utilize singletons, atributos de classe ou atributos
de contexto como “caches”; em vez disso, use
bibliotecas de cache escritas especialmente para
operar em clusters
Otimizações do Tomcat
• O clusterweb JavaEE seria transparente para
aplicações escritas de forma correta
• Entretanto, esta “transparência” seria cara em
termos de rede, pois obriga os nós do cluster a
replicar o estado de sessões HTTP ao fim de
cada requisição
• Por isso o Tomcat implementa, em sua
configuração padrão, um custer “não-
transparente”
• Esta configuração espera que a aplicação
atualize explicitamente todos os atributos da
sessão HTTP que forem atualizados
Clusters x Aplicações
Administrativas
• O Manager e o Admin não tem
conhecimento do cluster, portanto eles
tem que ser ativados e acessados de
forma independente em cada nó
• Por isso nossa simulação não eliminou o
conector HTTP
Cluster Farming
• Até agora as aplicações foram instaladas
manualmente em cada nó do cluster
• Embora útil para a nossa simulação, pois
permite ter aplicações ligeiramente diferentes a
saber assim exatamente que nó atendeu a que
requisição, é trabalhoso para ambiente de
produção
• Por isso o Tomcat fornece suporte a farming,
que consiste em instalar (deploy)
automaticamente aplicações em todos os nós
do cluster
Restrições do Farming no Tomcat
• Apenas um nó pode estar configurado para

instalar aplicações nos demais nós em um dado
momento
• A aplicação será instalada apenas nos nós
ativos; se um nó falho volta à ativa, novas
aplicações e atualizações terão que ser
instaladas manualmente, antes de reativar o nó
• É obrigatório o uso de pacotes WAR
compactados / fechados
Como funciona
• O pacote WAR da aplicação é copiado para um
diretório especial, separado do webapps
• O FarmWarDeployer monitora este diretório, e
quando um pacote é adicionado ou removido,
ele é copiado ou removido do webapps, fazendo
assim o deploy ou undeploy local
• O pacote é enviado para os outros nós ativos do
cluster, que repetem o processo de copiar para
o webapps local
• A remoção de pacotes gera notificações para
que os demais nós ativos façam undeploy
Exercício 1/5
• Acrescente o FarmWar Deployer dentro do element
<Cluster> do no0
<Cluster>
...
<Deplyoer
className=“org.apache.catalina.cluster.deploy.FarmWarDep
loyer”
tempDir=“/home/fernando/cluster/no0/war-temp/”
deployDir=“/home/fernando/cluster/no0/webapps”
watchDir=“/home/fernando/cluster/no0/war-listen”
watchEnabled=“true”/>
<ClusterListener
className=“org.apache.catalina.cluster.session.ClusterSess
ionListener”/>
...
</Cluster>
Exercício 2/5
• Não esqueça de ajustar os caminhos absolutos
(/home/fernando) ao seu próprio diretório home
• O watchDir poderia ser qualquer coisa, mas o
deployDir tem que ser o webapps do servidor,
ou qualquer que esteja configurado para o
<Host> desejado
• Somente um nó pode ter o watchEnabled com
o valor true
• O no1 recebe as mesmas alterações, com os
caminhos devidamente ajustados, exceto pelo
watchEnabled com o valor false
Exercício 3/5
que contém uma pequena variação do exemplo
5.2
• Compile as classes e empacote o exemplo no
arquivo exemplo6.1.war
• Edite o mod_jk.conf para acrescentar o
mapeamento para a nova aplicação (o
FarmDeployer não afeta as configurações do
Apache)
JkMount /exemplo6.1 cluster
JkMount /exemplo6.1/* cluster
Exercício 4/5
• Termine ambos os nós, limpe suas pastas work
e reinicie ambos
• Reinicie também o Apache
• Verifique que ambos os nós individuais estão
funcionando pelo acesso aos respectivos
Manager, e que o cluster também está ok,
acessando o exemplo 5.2
• Copie o pacote WAR exemplo6.1.war para a
pasta watchDir do no0, ou seja,
$HOME/cluster/no0/war-listen
Exercício 5/5
• Acesse o Manager em cada nó, e confirme que
a nova aplicação foi acrescentada (pode
demorar alguns segundos)
• Acesse o exemplo 6.1 pelo cluster
http://127.0.0.1/exemplo6.1
• Acesse o exemplo 6.1 diretamente por cada nó,
comprovando que o FarmWarDeployer fez a
cópia do no0 para o no1
http://127.0.0.1:8080/exemplo6.1
http://127.0.0.1:8180/exemplo6.1
Tunning e Monitoração de
Performance
• Parâmetros de memória da JVM

• Uso de threads pelo Tomcat e conectores
• Dimensionamento dos pools de conexões
ao banco de dados
• Tunning do cluster
• Introdução ao JMX
• Gerenciamento do Tomcat via JMX
Uso de Memória pelo Tomcat
• A JVM não aloca memória livre do sistema
operacional
• Em vez disso, no início da JVM é estabelecido
um limite máximo para o heap, onde são
armazenadas instâncias de classes Java
• Dependendo da quantidade de usuários,
aplicações, páginas e informações na sessão
HTTP pode ser necessário aumentar o tamanho
do heap
• A página de status do servidor (no Manager)
informa a memória em uso e a máxima no heap
Consultando o uso de memória com o Manager
• A indicação de memória livre (Free Memory) é em relação ao
efetivamente alocado para o heap (Total memory), e não em
relação ao máximo possível (Max memory)
Server Information
Tomcat Version JVM Version JVM Vendor OS Name
Apache Tomcat/5.5.16 1.5.0_05-b05 Sun Microsystems Inc. Linux
JVM
Free memory: 1.09 MB Total memory: 5.73 MB Max memory: 254.06 MB
http-8080
Parâmetros de memória da JVM 1/2
• O comando java –X exibe as várias opções para

tunning de memória e coleta de lixo da JVM
• As opções mais usadas são:
• -Xms<size>
Tamanho inicial do heap
• -Xmx<size>
Tamanho máximo do heap
• -Xss<size>
Tamanho da pilha ()
Parâmetros de memória da JVM 2/2
• O máximo padrão do heap é de 64Mb
• Parece pouco, mas lembre que é apenas o
heap, outras partes da JVM ocupam centenas
de Mb mas estas partes não crescem com a
carga da aplicação, ao contrário do heap
• O comando abaixo exibe a memória total (vsz) e
em uso na RAM (rss) para os processos da JVM
que rodam uma JVM
– $ os axo pid,vsz,rss,cmd | grep java
• Para estabelecer o máximo em 256Mb use
– $ java –Xmx256M
Modificando o Script de Startup
• Embora seja possível modificar os scripts de

início do Tomcat para inserir opções da JVM, é
mais limpo usar a variável de ambiente
JAVA_OPTS
• Então, para iniciar o Tomcat com o heap
aumentado:
– $ JAVA_OPTS=-Xmx256M ./startup.sh
• Confira pela página de status do Manager, o
aumento do máximo para o heap
• Outra opção é inserir, no início do startup.sh
– Export JAVA_OPTS=-Xmx256M
Uso de threads pelo Tomcat
• Os conectores do Tomcat usam um pool de
threads para atender a requisições
• O pool permite eficiência no uso de processador
e memória, além de melhorar o tempo de
resposta
• Como o tempo de processador é muito inferior
ao tempo de disco, rede e dos humanos, ter um
thread por conexão (ou por usuário / sessão
HTTP) seria um desperdício de recursos
• A página de status do Manager também permite
ver o uso de threads por cada conector
Consultando o uso de Threads com o
Manager
• O Manager exibe os limites do pool de threads: máximo
(Max), reserva (spare), total (current) e ocupados (busy)
• Também fornece uma lista do que estão fazendo os
threads ocupados
Conector x Front-end
• Caso sua configuração use um servidor de frontend
seus parâmetros de pool de processos ou de threads
devem ser iguais ou inferiores aos do conector no lado
do Tomcat
• Por exemplo, MaxServers no Apache deve ser igual ou
inferior a MaxProcessors no Conector JK do Tomcat, se
for usado o mod_jk
• Em um ambiente de cluster, deve-se prever uma folga
para eventuais “desbalanceamentos”
– Ex: três Tomcats, um Apache. Um único Tomcat falho, e 10
usuários para cada Tomcat:
MaxServers=3*10, MaxProcessors=2.2*10
MasServers=30, MaxProcessors=22
Dimensionamento dos pools de
conexões
• O dimensionamento dos pools de conexões a
bancos de dados (DataSources) é um pouco
mais complicado porque:
1. O Manager não exibe informações sobre o status
atual dos pools
2. Conexões a bancos de dados tendem a estar em
uso por períodos mais longos do que threads, e
dependem de recursos de rede
• Valem os mesmos princípios de
dimensionamento (mínimo, reserva e máximo)
vistos para threads
• Estatísticas de uso podem ser obtidas via JMX
O que são DataSource Leaks
• Um dos problemas mais sérios de aplicações

são os “vazamentos” (leaks) de conexões ao
banco de dados
• Isto acontece por erro de programação, onde
conexões são abertas (retiradas do pool) mas
nunca fechadas (devolvidas ao pool)
• Então, após algum tempo, não haverão mais
conexões disponíveis para uso por novas
requisições
Detectando DataSource Leaks
• Dentro de um elemento <Resource> que
configura um DataSource, podem ser definidos
os atributos:
– removeAbandoned=“true”
Instrui o Tomcat a forçar a liberação de conexões que
pareçam ter sido “abandonadas” (portanto, “vazadas”)
– removeAbandonedTimeout=“300”
Após quanto tempo sem uso uma conexão é considerada
“abandonada”
– logAbandoned=“true”
Registra no log do Tomcat as conexões que foram
consideradas abandonadas
Tunning do cluster 1/3
• Os recursos de clustering do Tomcat fornecem uma série

de parâmetros que podem ser ajustados
• Por exemplo, a válvula de replicação pode ignorar
requisições por arquivos estáticos
• Mas a configuração padrão não inclui arquivos Flash
(*.swf)
<Valve
className=“org.apache.catalina.cluster.top.R
eplicationValve”
filter=“.*\.gif;.*\.js;.*\.jpg;.*\.png;.*\.h
tm; .*\.html; .*\.css; .*\.txt; .*\.swf;”
• Com uma grande quantidade de usuários simultâneos,

pode ser necessário aumentar a quantidade de threads
que recebem informações dos demais nós,
especialmente se o cluster envolver mais de dois nós
<Receiver
className=“org.apache.catalina.cluster.top
.ReplicationListener”
tcpListenAddress=“auto”
tcpSelectorTimeOut=“100”
tcpThreadCount=“8”/>
• Por padrão, o envio de modificações nas sessões de um
nó assíncrono, o que gera um pequeno risco de perda
das últimas modificações das sessões em caso de pane
• Mudar para envio síncrono evita este risco às custas de
maior consumo de processador, memória e rede
< Sender
className=“org.apache.catalina.cluster.top
.ReplicationTransmitter”
replicationMode=“synchronous”
ackTimeout=“15000”/>
Introdução ao JMX
• Especificação da plataforma Java que permite a
qualquer aplicação fornecer “objetos gerenciados”, os
MBeans
• Define também uma forma de se localizar e obter
informações de MBeans, ou até de executar ações
sobre eles
• É obrigatório em versões mais novas do JavaEE, que
também define conjuntos de MBeans padrão para os
servidores de aplicações
• O marcado oferece vários consoles para gerenciamento
e monitoração JMX, similar aos consoles SNMP
Monitoração do Tomcat via JMX
• O Tomcat deve ser iniciado com o agente JMX

da JVM ativado
• Em modo local, basta definir uma propriedade
de sistema
$ JAVA OPTS=“Dcom.sun.management.jmxremote”
./startup.sh
• Em seguida, verifique qual processo da JVM que roda o
Tomcat e conecte a este processo usando o jconsole do
JavaSE
$ os ax | grep java
22587 pts/5 RI:03;usr/java/jdk1.5.0/bin/java...
$ jconsole 22587
Sumário do JMX Console
Memória via JMX
DataSources via JMX
• Todos os componentes do Tomcat são expostos como MBeans,
então é possível localizar os DataSource dentro do contexto e
verificar a quantidade de conexões ativas (em uso)
Monitoração Remota via JMX
• Forneça as propriedades do sistema para o agente JMX
$ export JAVA_OPTS=“-
Dcom.sun.management.jmxremote \
-Dcom.sun.management.jmxremote.port=5000 \
-Dcom.sun.management.jmxremote.ssl=false \
-Dcom.sun.management.jmxremote.authenticate=false”
$ ./startup.sh
• (Não há quebra de linha antes do “authenticate”)
• Execute o jconsole indicando a porta TCP
– $ jconsole 127.0.0.1:5000
Aula 7
• Nesta aula apresentamos mais recursos

para monitoramento e tuning do servidor,
com foco no troubleshooting (depuração)
de problemas.
Monitoração e Troubleshooting
• Revisão das ferramentas vistas

anteriormente
• Thread Dumps da JVM
Troubleshooting
• Ao longo deste curso fomos apresentados a várias
ferramentas úteis para depuração de problemas com o
Tomcat, entre elas:
• Válvula de log de acesso
• Tomcat Manager
• JMX via Jconsole
• Mas duas ferramentas adicionais merecem destaque:
• JMX Proxy
• Thread Dumps
Quando o Servidor Parece Congelado
• Em casos extremos, como falta de memória ou

saturação de processador, o Tomcat pode demorar tanto
a responder requisições que parece estar travado
• Nestes casos, usar o Manager (incluindo o JMX) será
inviável, pois estas requisições também não serão
respondidas
• Utilitários do Sistema Operacional, por exemplo ps, top,
vmstat ou sar ajudam a identificar gargalos, assim como
logs de acesso do próprio Tomcat
• Mas, exatamente o que o Tomcat estava fazendo
quando “congelou”?
Thread Dump
• Ao se enviar um sinal SIGQUIT para o processo que

roda uma JVM, a JVM salva um Thread Dump textual na
saída padrão
• No tomcat, a saída padrão é redirecionada para o
log/catalina.out
• O Thread Dump contém um stack trace para cada
Thread da JVM, de modo que se sabe exatamente que
método estava sendo executado
• O Thread Dump também indica se o tread está
executando, pronto ou aguardando por E/S; ou se está
bloqueado em um semáforo
Gerando um Thread Dump
• Primeiro, identifique o processo do Tomcat

• Depois, envie o SIGQUIT
• Então abra o arquivo catalina.sh
• ps axf | grep tomcat
6512 pts/0 S+ 0:00 \_ grep tomcat
2058 ? Sl 7:08 /opt/java/bin/java -Xms128m -
Xmx768m -Xss2m
• kill –QUIT 2058
• Vi ../logs/catalina.out
Exemplos de Thread Dumps
• "http-8080-Monitor" prio=1 tid=0x729e4f08 nid=0x891 in Object.wait() [0x6f0e3000..0x6f0e40b0]
• at java.lang.Object.wait(Native Method)
• - waiting on <0x7c0a5858> (a org.apache.tomcat.util.threads.ThreadPool$MonitorRunnable)
• at org.apache.tomcat.util.threads.ThreadPool$MonitorRunnable.run(ThreadPool.java:564)
• - locked <0x7c0a5858> (a org.apache.tomcat.util.threads.ThreadPool$MonitorRunnable)
• at java.lang.Thread.run(Thread.java:595)
• "http-8080-Processor25" daemon prio=1 tid=0x729e4208 nid=0x890 in Object.wait()

[0x72c58000..0x72c59130]
• at java.lang.Object.wait(Native Method)
• - waiting on <0x7c0abe18> (a org.apache.tomcat.util.threads.ThreadPool$ControlRunnable)
• at java.lang.Object.wait(Object.java:474)
• at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:661)
• - locked <0x7c0abe18> (a org.apache.tomcat.util.threads.ThreadPool$ControlRunnable)
• "http-8080-Processor24" daemon prio=1 tid=0x729e35d0 nid=0x88f runnable [0x72e59000..0x72e59fb0]

• at java.net.SocketInputStream.socketRead0(Native Method)
• at java.net.SocketInputStream.read(SocketInputStream.java:129)
• at org.apache.coyote.http11.InternalInputBuffer.fill(InternalInputBuffer.java:738)
• at org.apache.coyote.http11.InternalInputBuffer.parseRequestLine(InternalInputBuffer.java:399)
• at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:828)
• at
org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11Base
Protocol.java:665)
• at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528)
• at
org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81)
• at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689)
Tomcat 6
• Cada versão maior do Tomcat (3,4,5 e 6) corresponde a
uma versão diferente das especificações de Servlets e
JSP elaboradas pelo JCP
• Ainda assim, a compatibilidade retroativa é garantida, de
modo que muitos desenvolvedores não aprenderam a
lidar com recursos de versões mais recentes, como a EL
do JSP 2.0
• Especificações Servlets 2.5 e JSP 2.1
• Conectores baseadas no NIO do Java (mas com a
mesma configuração das versões anteriores)
• Fim da aplicação Admin
• Simplificação da estrutura de diretórios para bibliotecas
(não existe mais diferenciação entre server, common e
shared)
• Aplicação Manager melhorada, com monitoração
individualizada de seções HTTP
Este curso e o Tomcat 6
• Este curso foca na versão 5.5 , porque é a
mais utilizada em ambiente de produção
na atualidade
• Mas todos os exemplos e configurações
permanecem válidos com o Tomcat 6,
bastando-se ajustar os paths de
bibliotecas (arquivos .jar)

Curso Tomcat

Caricato da

Informazioni sul documento

Descrizione originale:

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Curso Tomcat

Caricato da

Copyright:

Formati disponibili

Servidores de Aplicações

J2EE usando TomCat

Marcos Pedro Pinto

• Java EE ou JEE – Java Enterprise Edition

Bibliotecas APIs de Extensão

• Uma aplicação web em Java deve ser

• Acesse o endereço http://192.168.0.242/cd

• Se houverem várias instalações do “Java” no formato

• O tomcat espera que esteja definida a

• Edite o arquivo conf/catalina.sh

• Entre na pasta bin

• Para evitar riscos de segurança, a instalação padrão do

• Visite a página de downloads do Tomcat

• Pacotes WAR abertos e fechados

• Também pode ser usado o comando unzip

• Em uma aplicação real, a estrutura de pastas para

• Lembre-se de reiniciar o Tomcat para que

• Aplicações instaladas pela cópia de

• Verifique que o exemplo 1.2 agora é

• A plataforma Java EE especifica o uso da API JNDI para

• Banco de dados relacional 100% Java que

• O instrutor irá fornecer o arquivo exemplo3.3.zip que

• O instrutor irá fornecer o exemplo de

• A configuração padrão do Tomcat já define no server.xml

• Como configuração padrão vincula o Realm ao

• Entre no admin e edite o usuário “boss”

• É um algoritmo que gera um número bem grande,

• Autenticação via banco de dados

• Eis a definição de um realm baseado em banco de dados

• A definição do DataSource “jdbc/Contatos” é a mesma vista

• Insira dois usuários de teste

• Finalmente teste a aplicação pela URL

• Sites de produção utilizam um certificado adquirido em

• O que é um host virtual

• Edite (como root) o arquivo etc/hosts e acrescente a linha:

• Prossiga para a configuração do mod_jk

• Altere a página index.jsp no segundo Tomcat

• Agora que temos dois Tomcats e somos

• Remova os arquivos de trabalho na pasta work

• Reinicie cada Tomcat e também o Apache

• Configuração de clusters para tolerância a

• Em um servidor real seria algo como:

<!– continua -->

<!– continuacao -->

<!–- continua -->

• Se você perdeu o modelo, porque o Admin remove

• Note que cada nó do cluster abre uma porta

• Apenas um nó pode estar configurado para

• Parâmetros de memória da JVM

Apache Tomcat/5.5.16 1.5.0_05-b05 Sun Microsystems Inc. Linux

• O comando java –X exibe as várias opções para

• Embora seja possível modificar os scripts de

• Um dos problemas mais sérios de aplicações

• Os recursos de clustering do Tomcat fornecem uma série

• Com uma grande quantidade de usuários simultâneos,

• O Tomcat deve ser iniciado com o agente JMX

• Nesta aula apresentamos mais recursos

• Revisão das ferramentas vistas

• Em casos extremos, como falta de memória ou

• Ao se enviar um sinal SIGQUIT para o processo que

• Primeiro, identifique o processo do Tomcat

• "http-8080-Processor25" daemon prio=1 tid=0x729e4208 nid=0x890 in Object.wait()