Tomcat

Servidores de Aplicação JavaEE
usando Tomcat - 428
www.4linux.com.br
Sumário
Sumário 2
1 Introdução 9
1.1 Quem deve fazer? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2 Pré-requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3 Agenda 1/2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.4 Antes do Tomcat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.5 Verificando o Ambiente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.6 Programa Java Mı́nimo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2 Aula 1 12
2.1 Conceitos do JavaEE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2 JavaSE x JavaEE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3 Aplicações JavaEE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4 Containers JavaEE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.5 Aplicação Java EE x JVM x Container . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.6 Servlets, JSP, JSTL e JSF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.7 Outras APIs Java EE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.8 Frameworks Struts, Hibernate e outros . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.9 O formato WAR e deployment descriptors . . . . . . . . . . . . . . . . . . . . . . . . 14
2.10 Sobre o Tomcat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.11 Instalação do Tomcat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.11.1 Pré-Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.11.2 Versões do Tomcat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.11.3 Como e Onde Baixar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.11.4 Instalação em Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.12 Principais Arquivos e Diretórios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.13 Startup e Shutdown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.14 Iniciando e Terminando o Tomcat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.15 Testando o Tomcat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.16 Exemplos do Tomcat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.17 Se Algo Deu Errado... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.18 Exercı́cios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.19 Aplicações de Administração do Tomcat . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.20 Ativação das aplicações administrativas . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.21 Editando o arquivo conf/tomcat-users.xml . . . . . . . . . . . . . . . . . . . . . . . . 19
2.22 Aplicação Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.23 Aplicação Admin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.24 Baixando e Instalando o Admin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.25 Usando o Admin 1/2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2
Sumário
2.26 Usando o Admin 2/2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3 Aula 2 23
3.1 Deployment de Aplicações Web JavaEE . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.1.1 O Que é Deployment? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.1.2 Aplicação de Exemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2 Compilando o Exemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.3 Comandos para Compilar o Exemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.4 Pacotes WAR abertos e fechados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.5 Montando um Pacote WAR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.6 Verificando um Pacote WAR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.7 Auto-Deploy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.8 Exercı́cio 1/4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.9 Exercı́cio 2/4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.10 Exercı́cio 3/4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.11 Exercı́cio 4/4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.12 Undeployment manual x Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.13 O Descritor web.xml . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.14 Exercı́cio 1/2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.15 Exercı́cio 2/2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.16 Re-deployment Automático . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.17 Construção de Pacotes WAR com Ant . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.18 Instalação do Ant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.19 Verificando a Instalação do Ant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.20 $ ant -version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.21 Scripts Ant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.22 Exemplo com Ant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.23 Estrutura do Exemplo 1.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.24 Exercı́cio 1/2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.25 Exercı́cio 2/2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.26 Deployment via Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.27 Exercı́cio 1/2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.28 Exercı́cio 2/2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.29 Configuração de Aplicações Web / Contextos . . . . . . . . . . . . . . . . . . . . . . . 31
3.30 Introdução ao server.xml . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.31 Estrutura do server.xml . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.32 Engines, hosts e contextos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.33 Contextos implı́citos e explı́citos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.34 Outros Elementos do server.xml . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.35 Exercı́cio 1/2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.36 Dicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.37 Editando o server.xml via Admin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.38 Exemplo do Admin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.39 Configuração de Contextos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.40 Exercı́cio 1/4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.41 Exercı́cio 2/4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.42 Exercı́cio 3/4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.43 Exemplo 4/4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.44 Configuração do contexto via conf/engine/host . . . . . . . . . . . . . . . . . . . . . . 34
3.45 Exercı́cio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3
Sumário
3.46 Configuração do contexto via META-INF/context.xml . . . . . . . . . . . . . . . . . 35

3.47 O descritor context.xml . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.48 Configuração do ambiente JNDI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.49 Exercı́cio 1/4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.50 Exercı́cio 2/4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.51 Exercı́cio 3/4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.52 Exercı́cio 4/4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4 Aula 3 37
4.1 Instalação de Bibliotecas e APIs de Terceiros . . . . . . . . . . . . . . . . . . . . . . . 37
4.2 Bibliotecas Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.3 Onde Instalar Bibliotecas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.4 Bibliotecas fornecidas com o Tomcat . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.5 Conceitos de classloaders do Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.6 Uso das pastas server, shared e common . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.7 Exemplo de Bibliotecas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.8 Task Customizado para o Manager do Tomcat . . . . . . . . . . . . . . . . . . . . . . 38
4.9 Compilando o Exemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.10 Exercı́cio 1/4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.11 Exercı́cio 2/4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.12 Exercı́cio 3/4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.13 Exercı́cio 4/4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.14 Porque a Primeira Vez Foi Diferente? . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.15 Uso da pasta WEB-INF/lib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.16 Exemplo de Biblioteca Dentro do Pacote . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.17 Exercı́cio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.18 Configuração de DataSources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.19 Porque usar DataSources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.20 Pools de Conexão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.21 Sobre o HSQLDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.22 Baixando e Instalando o HSQLDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.23 Criando o Banco de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.24 Verificando o Banco de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.25 Inicializando e Verificando o BD do Exemplo . . . . . . . . . . . . . . . . . . . . . . . 43
4.26 Criação de DataSources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.27 Instalação do Driver do Banco no Tomcat . . . . . . . . . . . . . . . . . . . . . . . . 43
4.28 Uso de DataSources pela aplicação via JNDI . . . . . . . . . . . . . . . . . . . . . . . 43
4.29 Exemplo de DataSource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.30 DataSource no Contexto da Aplicação . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.31 Configurações de Segurança (Parte I) . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.32 Introdução à segurança declarativa do J2EE . . . . . . . . . . . . . . . . . . . . . . . 44
4.33 Autenticação HTTP BASIC e DIGEST . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.34 Qual Mecanismo Escolher? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.35 Usuários, roles e resource-collections do J2EE . . . . . . . . . . . . . . . . . . . . . . 45
4.36 Definição do Mecanismo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.37 Páginas Protegidas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.38 Exemplo de Segurança BASIC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.39 Estrutura do Exemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.40 Criação dos Usuários . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.41 Configuração do Realm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4
Sumário
4.42 Vinculação do Realm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.43 Exercı́cio 1/6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.44 Exercı́cio 2/6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.45 Exercı́cio 3/6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.46 Exercı́cio 4/6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.47 Exercı́cio 5/6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.48 Exercı́cio 6/6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.49 Encriptando Senhas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.50 O que é um algoritmo de hash? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.51 Exercı́cio 1/2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.52 Exercı́cio 2/2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.53 Autenticação Form-based . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.54 Configuração da Aplicação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.55 Configuração do Tomcat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.56 Single Sign-On . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.57 Exercı́cio 1/2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.58 Exercı́cio 2/2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5 Aula 4 52
5.1 Configurações de Segurança . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.2 Autenticação via banco de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.3 Definição do DatasourceRealm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.4 Exercı́cio 1/4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.5 Exercı́cio 2/4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.6 Exercı́cio 3/4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.7 Exemplo 4/4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.8 Autenticação via diretório LDAP (OpenLDAP) . . . . . . . . . . . . . . . . . . . . . 54
5.9 Exemplo de JNDI Realm 1/2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.10 Exemplo de JNDI Realm 2/2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.11 Segurança Programática do JavaEE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.12 APIs de Segurança do JavaEE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.13 Logout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.14 Logout por Inatividade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.15 Restrições de IP / métodos HTTP pelo Tomcat . . . . . . . . . . . . . . . . . . . . . 56
5.16 Exemplo de Restrições No Descritor web.xml 1/2 . . . . . . . . . . . . . . . . . . . . 56
5.17 Exemplo de Restrições No Descritor web.xml 2/2 . . . . . . . . . . . . . . . . . . . . 56
5.18 Firewall Interno do Tomcat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.19 Regras de Host e Endereço IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.20 http://jakarta.apache.org/regexp/ . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.21 Exercı́cio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.22 Exemplo 4.1 Visto Pelo Admin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.23 Conexões seguras (SSL/TLS) no Tomcat . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.24 Certificados Auto-Assinados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.25 Criando um Certificado para o Servidor 1/2 . . . . . . . . . . . . . . . . . . . . . . . 58
5.26 Criando um Certificado para o Servidor 2/2 . . . . . . . . . . . . . . . . . . . . . . . 58
5.27 Ativando o Conector SSL 1/2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.28 Ativando o Conector SSL 2/2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.29 Exercı́cio 1/3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.30 Exercı́cio 2/3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.31 Exercı́cio 3/3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5
Sumário
5.32 Segurança declarativa e encriptação . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

5.33 Configuração de Hosts Virtuais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.34 O Que É um Host Virtual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.35 Configuração de hosts no Tomcat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.36 Exercı́cio 1/2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.37 Exercı́cio 2/2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.38 Aplicações administrativas x hosts virtuais . . . . . . . . . . . . . . . . . . . . . . . . 61
5.39 Exercı́cio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.40 Configurações de Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.41 A importância do logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.42 Introdução ao Logging no J2EE e Log4J . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.43 Conceitos de Logging 1/2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.44 Categorias de log do Tomcat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.45 Nı́veis de Log do JavaSE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.46 Logs Padrão do Tomcat 1/2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.47 Logs Padrão do Tomcat 2/2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.48 Logs por Contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.49 Exemplo de Log por Contexto 1/2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.50 Exemplo de Log por Contexto 2/2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.51 Configuração de appenders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.52 Logs de Acesso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.53 Configurando Logs de Acesso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
6 Aula 5 66
6.1 Integração com o Apache Httpd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
6.2 Servidores Nativos x Tomcat 1/2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
6.3 Servidores Nativos x Tomcat 2/2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
6.4 Arquitetura do Tomcat(Simplificada) . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
6.5 Conectores HTTP e AJP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
6.6 O mod jk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
6.7 Instalando o mod jk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
6.8 Instalando o Pacote 1/2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
6.9 Instalando o Pacote 2/2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
6.10 Instalando Binários Pré-Compilados 1/2 . . . . . . . . . . . . . . . . . . . . . . . . . 68
6.11 Instalando Binários Pré-Compilados 2/2 . . . . . . . . . . . . . . . . . . . . . . . . . 68
6.12 Compilando o mod jk 1/2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
6.13 Compilando o mod jk 2/2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
6.14 Configuração do mod jk 1/4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
6.18 Se Algo Der Errado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
6.19 Dividindo Tarefas entre o Apache e o Tomcat . . . . . . . . . . . . . . . . . . . . . . 70
6.20 Exercı́cio 1/6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
6.21 Exercı́cio 2/6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.22 Exercı́cio 3/6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.23 Exercı́cio 4/6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.24 Exercı́cio 5/6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.25 Exercı́cio 6/6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
6.26 Integração x segurança e logging 1/2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
6
Sumário
6.27 Integração x segurança e logging 2/2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

6.28 Configurações de Clustering (Parte I) . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
6.29 Conceitos de clustering web JavaEE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6.30 Cluster Web JavaEE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6.31 O Balanceador ou Distribuidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6.32 Distribuição de Carga x Tolerância a Falhas . . . . . . . . . . . . . . . . . . . . . . . 73
6.33 Estado da Aplicação no HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6.34 Arquitetura de clustering do Tomcat 5 . . . . . . . . . . . . . . . . . . . . . . . . . . 74
6.35 Clusters para balanceamento de carga . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
6.36 Instalando um Segundo Tomcat 1/3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
6.39 Exemplo de Teste do Cluster 1/4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.43 Configurando o Distribuidor 1/5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
6.48 Se Algo Der Errado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
6.49 Status do Cluster 1/2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
6.50 Status do Cluster 2/2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
6.51 Exercı́cio Opcional 1/2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
6.52 Exercı́cio Opcional 2/2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
7 Aula 6 80
7.1 Configurações de Clustering (Parte II) . . . . . . . . . . . . . . . . . . . . . . . . . . 80
7.2 Clusters Para Tolerância à Falhas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
7.3 Arquitetura de clustering do Tomcat 5 1/2 . . . . . . . . . . . . . . . . . . . . . . . . 80
7.4 Arquitetura de clustering do Tomcat 5 2/2 . . . . . . . . . . . . . . . . . . . . . . . . 80
7.5 Configuração de clusters para Tolerância à Falhas . . . . . . . . . . . . . . . . . . . . 81
7.6 Exercı́cio 1/8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
7.7 Exercı́cio 2/8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
7.8 Exercı́cio 3/8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
7.9 Exercı́cio 4/8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
7.10 Exercı́cio 5/8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
7.11 Exercı́cio 6/8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
7.12 Exercı́cio 7/8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
7.13 Exercı́cio 8/8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
7.14 Se Algo Deu Errado... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
7.15 Seja Paciente! 1/2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
7.16 Seja Paciente! 2/2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
7.17 Erros de Aplicação a Evitar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
7.18 Otimizações do Tomcat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
7.19 Clusters x Aplicações Administrativas . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
7.20 Cluster Farming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
7.21 Restrições do Farming no Tomcat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
7.22 Exercı́cio 1/5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
7
Sumário
7.23 Exercı́cio 2/5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

7.24 Exercı́cio 3/5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
7.25 Exercı́cio 4/5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
7.26 Exercı́cio 5/5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
7.27 Tunning e Monitoração de Performance . . . . . . . . . . . . . . . . . . . . . . . . . . 86
7.28 Introdução ao JMX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
7.29 Parâmetros de memória da JVM 1/2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
7.30 Parâmetros de memória da JVM 2/2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
7.31 Modificando o Script de Startup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
7.32 Uso de Threads pelo Tomcat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
7.33 Conector x Front-end . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
7.34 Dimensionamento dos pools de conexões . . . . . . . . . . . . . . . . . . . . . . . . . 89
7.35 O Que São DataSource Leaks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
7.36 Tunning do cluster 1/3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
7.39 Introdução ao JMX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
7.40 REFERÊNCIAS 1/4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
7.41 REFERÊNCIAS 2/4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
7.42 REFERÊNCIAS 3/4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
7.43 REFERÊNCIAS 4/4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Referências Bibliográficas 94
8
Capı́tulo 1
Introdução
Este curso visa capacitar profisssionais para a administração e gerenciamento de servidores de

aplicação Tomcat, tanto em ambiente de desenvolvimento quanto em ambiente de produção
1.1 Quem deve fazer?

• Administradores de rede responsáveis por manter um servidor TomCat como parte de um
Portal, Intranet ou Extranet;
• Programadores e analistas de sistemas responsáveis pelo desenvolvimento de aplicações Web

utilizando a plataforma Java EE;
• Administradores de rede e desenvolvedores interessados em obter conhecimentos sobre como

construir, manter e otimizar uma infraestrutura de servidores de aplicação Java EE.
1.2 Pré-requisitos
• Leitura básica em Inglês Técnico;
• Conhecimentos básicos de Linguagem de programação Java
• Desejáveis, embora não indispensáveis:
• Compilação de programas na linha de comando utilizando o JDK;
• Acesso a bancos de dados utilizando JDBC;
• Construção de servles e páginas JSP.
• Conhecimentos básicos de HTML e HTTP (navegadores e servidores Web);
• Conhecimentos básicos de TCP/IP.
1.3 Agenda 1/2

• Aula 1:
– Conceitos do JavaEE
– Instalação do Tomcat
9
Capı́tulo 1. Introdução
– Aplicações de administração do Tomcat
• Aula 2:
– Deployment de aplicações Web JavaEE

– Configuração de aplicações Web / Contextos
• Aula 3:
– Instalação de bibliotecas e APIs de terceiros

– Configuração de DataSources
– Configurações de segurança (parte 1)
• Aula 4:
– Configurações de segurança (parte 2)

– Configuração de hosts virtuais
– Configurações de logging
• Aula 5:
– Integração com Apache Httpd

– Configurações de clustering (parte 1)
• Aula 6:
– Configurações de clustering (parte 2)

– Tunning e monitoração de performance
1.4 Antes do Tomcat

Necessitamos de um ambiente de desenvolvimento JSE 5.0 (JDK 1.5.0) devidamente configurado
para uso pela linha de comando
Compile uma classe Java mı́nima com o comando javac e depois execute esta classe com o comando
java
Embora IDEs como Eclipse e NetBeans sejam úteis para o desenvolvimento de aplicações, eles
não serão utilizados neste curso, que tem como público-alvo o administrador de sistemas e não o
programador Java
1.5 Verificando o Ambiente

Verifique se a versão correta da JVM está disponı́vel na linha de comando:
$ java -version
java version 1.5.0
Verifique se o compilador Java também está disponı́vel na linha de comando:
10
Capı́tulo 1. Introdução
$ javac
Usage: javac <options> <source files>
Verifique o classpath:
$ echo $CLASSPATH
.
(observe que o resultado deve ser um ponto)
1.6 Programa Java Mı́nimo

Eis o programa Oi.java
public class Oi
{
static public void main(String[] args) {
System.out.println("Oi do Java!");
}
}
Para compilar, gerando o arquivo Oi.class
$ javac Oi.java
Para executar:
$ java Oi
Oi do Java!
11
Capı́tulo 2
Aula 1
Nesta aula temos um primeiro contato com o servidor Tomcat, sua instalação e sua “cara” para o
usuário e administrador, além de ver os conceitos essenciais para sua utilização
Tópicos:
• Conceitos do JavaEE
• Instalação do Tomcat
• Aplicações de administração do Tomcat
2.1 Conceitos do JavaEE

• JavaSE x JavaEE
• Containers Web, EJB e de Aplicação
• Servlets, JSP, JSTL e JSF
• Frameworks Struts, Hibernate e outros
• O formato WAR e deployment descriptors
2.2 JavaSE x JavaEE

Java SE ou JSE – Java Standard Edition (antigo J2SE)
• Fornece a JVM (máquina virtual Java) e as APIs essenciais para coleções, E/S, reflexão, seri-
alização, XML, interfaces gráficas e redes
Java EE ou JEE – Java Enterprise Edition(antigo J2EE):
• Tecnologias e APIs da plataforma Java para computação baseada em servidor
• Conectividade com bancos de dados, serviços de diretórios, correio eletrônico e outros serviços
• São previstos servidores especializados para aplicações Java EE
12
Capı́tulo 2. Aula 1
2.3 Aplicações JavaEE
Figura 2.1:
2.4 Containers JavaEE

Um servidor de aplicações JavaEE é formado por um ou mais containers:
• Container Web: hospeda aplicações web, acessadas por meio de um navegador padrão
• Container EJB: hospeda componentes / objetos distribuı́dos construı́dos segundo o padrão

EJB (Enterprise Java Beans) e compatı́veis com padrões CORBA
• Container de aplicação: hospeda aplicações cliente stand-alone, fornecendo o ambiente ne-

cessário para conexão aos serviços fornecidos por um servidor de aplicações
2.5 Aplicação Java EE x JVM x Container
Figura 2.2:
13
2.6 Servlets, JSP, JSTL e JSF

• Aplicações Web do JavaSE são formadas por diversos componentes, a saber
• Servlets são classes Java criadas para serem gerenciadas por um container web.
• Páginas JSP são páginas HTML contendo comandos Java e tags customizadas, que são
transformadas em Servlets para execução pelo Container Web
• JSTL é um conjunto padrão de tags customizados para uso em páginas JSP
• JSF é um framework que fornece um modelo de componentes e de eventos dentro de Servlets

e páginas JSP semelhante ao utilizado em aplicações gráficas tradicionais
2.7 Outras APIs Java EE

• JTA cuida de transações distribuı́das
• JNDI permite acesso a serviços de diretório e objetos compartilhados entre aplicações e os

containers
• JDBC para acesso a bancos de dados relacionais
• JavaMail para acesso a servidores de e-mail Internet
• JMS para acesso a filas de mensagens
• JMX para gerenciamento local ou remoto
• JAXP para processamento de documentos XML
2.8 Frameworks Struts, Hibernate e outros

Uma série de frameworks se tornaram populares no desenvolvimento de aplicações Java EE, mesmo
sem ser formalmente parte do padão, entre eles:
• Struts permite a construção de aplicações segundo o modelo MVC (Model-View-Controller)

onde é fornecido um Servlet controlador e o desenvolvedor cria suas páginas JSP como visões
e classes JavaBeans como modelo
• Hibernate permite o uso de um banco relacional de forma orientada a objetos
• Spring e WebWorks são outros frameworks populares para o JavaEE
2.9 O formato WAR e deployment descriptors

Uma aplicação web em Java deve ser empacotada em um formato chamado WAR
O WAR e um JAR (que por sua vez é um ZIP) onde existe uma pasta WEB-INF contendo as
classes Java da aplicação e o descritor de deployment
Outros arquivos são tratados como páginas HTML estáticas ou páginas JSP dinâmicas
Apenas pacotes WAR podem ser entregues para execução pelo Container Web
14
2.10 Sobre o Tomcat

É um servidor de aplicações JavaEE que fornece apenas o Container Web para execução de aplicações
Web Java EE
Fornece ainda serviços JNDI e JMX, de modo que aplicações Web (sem uso de EJBs ou JMS)
criadas originalmente para servidores de aplicações mais “parrudos” como o JBoss devem rodar sem
modificações no Tomcat
Apresenta recursos avançados, como suporte nativo a clustering (desde a versão 5.0)
2.11 Instalação do Tomcat

• Pré-requisitos
• Versões do Tomcat
• Onde e como baixar
• Principais arquivos e diretórios do Tomcat
• Startup e shutdown do Tomcat
2.11.1 Pré-Requisitos
Tomcat 5.0.x e anteriores
• JDK 1.3 ou superior
• O Tomcat necessita do compilador Java fornecido pelo JDK para compilar os servlets gerados
pelo processamento de pá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
2.11.2 Versões do Tomcat

A versão do Tomcat a ser utilizada depende da versão das especificações de Servlets e JSP a ser
adotada
Consulte http://tomcat.apache.org/ para ver a relação versões do Tomcat x especificações de
Servlets e JSP
Versões mais novas do Tomcat suportam versões mais antigas das especificações
As séries 3.x, 4.x e 5.0.x ainda são suportadas em termos de correções de bugs
O desenvolvimento hoje ocorre na série 5.5.x
15
2.11.3 Como e Onde Baixar

Visite http://tomcat.apache.org e siga o link para download da versão desejada
Baixe a distribuição Core, em formato zip
A versão em formato “Windows executable” cria atalhos no menu iniciar e configura um o Tomcat
para execução como serviço do Windows
A criação dos atalhos e serviço também pode ser feito manualmente pela versão zip, que inclui
ainda os scripts para execução em Linux e Unix
2.11.4 Instalação em Linux

Descompacte o zip do Tomcat no seu diretório home, preservando os subdiretórios contidos no zip:
$ unzip apache-tomcat-5.5.16.zip
Entre na pasta bin e dê permissão de execução para todos os shell scripts
$ cd apache-tomcat-*/bin
$ chmod a+x *.sh
2.12 Principais Arquivos e Diretórios

jakarta-tomcat-versao (até o 5.0)
apache-tomcat-versao (5.5.0 em diante)
• bin (scritps de inicialização e shutdown)
• conf (arquivos de configuração)
• webapps (deployment de WARs)
• server (classes internas do servidor)
• common (classes usadas tanto pelo servidor quanto por aplicações, como a API de servlets)
• shared (classes compartilhadas por várias aplicações, como drivers JDBC)
• logs, temp e work (arquivos voláteis)
2.13 Startup e Shutdown

Dentro da pasta bin, os scripts startup e shutdown (em versões .sh para Linux / Unix e .bat para
Windows) são usados, respectivamente, para iniciar e encerrar o servidor
Há ainda executáveis (.exe) para atalhos e serviços Windows
Scripts de inı́cio e término no padrão System V (/etc/init.d) não são fornecidos, devem ser criados
pelo administrador
A configuração padrão do Tomcat escuta as portas 8080 (web), 8009 (AJP) e 8085 (shutdown)
16
2.14 Iniciando e Terminando o Tomcat

Para iniciar:
Entre na pasta bin do Tomcat
$ cd ~/apache-tomcat-*/bin
Execute o script startup
$ ./statup.sh
Para terminar:
Entre na pasta bin do Tomcat
$ cd ~/apache-tomcat-*/bin
Execute o script shutdown
$ ./shutdown.sh
Após cada operação (inı́cio e término) confirme a presença do processo Java e verifique que as
três portas abertas pelo Tomcat
2.15 Testando o Tomcat

Entre na pasta bin
Execute o script startup
Após alguns segundos, deverá ser possı́vel acessar o Tomcat
Visite a URL http://127.0.0.1:8080
O resultado deverá ser como visto abaixo:
Figura 2.3:
17
2.16 Exemplos do Tomcat

No final do menu de navegação (laranja) na parte esquerda da página inicial, haverão links para
exemplos de servlets e páginas JSP
Os links para documentação acessam páginas fornecidas com o próprio Tomcat, e que podem ser
acessadas sem que o mesmo esteja em execução
Os links na categoria “Tomcat on-line” são páginas no site oficial do Tomcat na Apache Software
Foundation (ASF)
2.17 Se Algo Deu Errado...

Verifique os logs do Tomcat, em especial logs/catalina.out
Verifique se o comando java pode ser executado diretamente pela linha de comando
Verifique se as portas 8080, 8009 e 8085 estavam livres antes do inı́cio do Tomcat
Verifique se a estrutura de diretórios do Tomcat foi preservada depois da descompactação do
arquivo zip
Se tudo o mais falhar, encerre todos os processos “java” ativos e reinstale o Tomcat do zero
2.18 Exercı́cios
Encerre o Tomcat, e acesse as páginas de documentação sem ter o Tomcat executando
Localize na documentação os release notes
Pelo Tomcat, a URL seria:
http://127.0.0.1:8080/tomcat-docs/RELEASE-NOTES.txt
Diretamente pelo navegador, seria:
file:///home/fernando/apache-tomcat-5.5.16/webapps/tomcat-docs/RELEASE-NOTES.txt
Lembre que não há quebras de linha nas URLs e comandos!

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
...
SEVERE: Error initializing endpoint
java.net.BindException: Address already in use:8080
18
2.19 Aplicações de Administração do Tomcat

• Ativação das aplicações administrativas
• Aplicação Manager
• Aplicação Admin
2.20 Ativação das aplicações administrativas

Para evitar riscos de segurança, a instalação padrão do Tomcat não define nenhum usuário com
acesso às aplicações administrativas
Para criar este usuário, deve ser editado o arquivo conf/tomcat-users.xml
Deve ser acrescentado um usuário contendo os roles admin e manager.
Como acrescentar este usuário será auto-explicativo pelos exemplos fornecidos no próprio arquivo.
O Tomcat deve ser reiniciado para que o novo usuário seja reconhecido
2.21 Editando o arquivo conf/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>
2.22 Aplicação Manager

É utilizada para ativar, desativar e recarregar aplicações web (pacotes WAR) hospedados pelo Tomcat
Também permite a obtenção de relatórios sobre o status atual do servidor
Foi criada para ser acessada por scripts (utilizando wget, por exemplo), e não por humanos, por
isso sua interface simples
Entre nela pela URL http://127.0.0.1:8080/manager/html
Exemplos do Manager:
19
Figura 2.4:
Figura 2.5:
2.23 Aplicação Admin

Permite a configuração do próprio servidor Tomcat, por exemplo criando novos usuários, mudando
a porta onde são escutadas conexões, ou definindo DataSources para bancos de dados
Desde a versão 5.5.9, ela deve ser baixada e instalada à parte
Os resultados são salvos na pasta conf/Catalina, em vez de no arquivo conf/serverl.xml monolı́tico
20
2.24 Baixando e Instalando o Admin

Visite a página de downloads do Tomcat
http://tomcat.apache.org/download-55.cgi
Baixe o arquivo zip da “Administration Web Application”

Descompacte o arquivo por sobre sua instalação do Tomcat, sobreescrevendo arquivos se ne-
cessário
Reinicie o Tomcat
2.25 Usando o Admin 1/2

Entre na aplicação pela URL
http://127.0.0.1:8080/admin
Forneça o login e senha configurados para o perfil “admin” no arquivo tomcat-users.xml

Depois do login, a parte esquerda da página é uma estrutura de árvore (outline) que permite
navegar pelos elementos de configuração do servidor
Abra os elementos “Service (Catalina)” e “Host (localhost)” para ver a relação de aplicações
hospedadas no servidor
2.26 Usando o Admin 2/2

Clique então no contexto raiz – “Context (/)” para ver a aplicação que exibe a página inicial do
servidor
Navege por outros elementos, mas tome o cuidado de não modificar nenhum parâmetro de confi-
guração
Enquanto não clicar em “Commit Changes”, nenhuma modificação será feita sobre o servidor
Tomcat
Veremos mais adiante detalhes sobre cada parâmetro exibido por esta aplicação
Exemplo do Admin:
21
Figura 2.6:
22
Capı́tulo 3
Aula 2
Nesta aula, aprendemos como instalar e configurar aplicações web para execução sob o servidor de
aplicações Tomcat
Tópicos:
• Deployment de aplicações Web JavaEE
• Configuração de aplicações Web / Contextos
3.1 Deployment de Aplicações Web JavaEE

• Pacotes WAR abertos e fechados
• Deployment via cópia de arquivos: Auto-deploy
• Uso do Apache Ant para construção de pacotes War
• Deployment via aplicação Manager
3.1.1 O Que é Deployment?

É o processo de instalação de uma aplicação web Java EE dentro de um container web, tornando
esta aplicação disponı́vel para seus usuários
Envolve garantir que todas as configurações e recursos requeridos pela aplicação estejam dis-
ponı́veis no servidor onde ela é instalada
Há várias formas locais e remotas de realizar o deployment com o Tomcat
3.1.2 Aplicação de Exemplo

Para os exercı́cios desta aula, será utilizada uma aplicação simples, que consiste de duas classes Java
(um Servlet) e quatro páginas JSP
O instrutor fornecerá o arquivo exemplo1.1.zip contendo a aplicação, que deverá ser descompac-
tado na pasta home do usuário
As classes Java do exemplo terão que ser compiladas antes de prosseguirmos
Arquivos do Exemplo
• exemplo1.1
– bean.jsp
– el.jsp
23
– hoje.jsp
– index.jsp
– WEB-INF
∗ classes
· exemplo
∗ HojeBean.java
∗ HojeServlet.java
– web.xml
3.2 Compilando o Exemplo

Configure o classpath do sistema para incluir a API de Servlets, fornecida pelo Tomcat
Entre na pasta que contém as classes do exemplo
Compile as classes
Verifique que a pasta WEB-INF/classes/exemplo da aplicação contém agora dois arquivos *.class
que correspondem aos dois arquivos Java presentes na mesma pasta
3.3 Comandos para Compilar o Exemplo

(Cada comando deve ser digitado em uma única linha!)
$ export CLASSPATH=$CLASSPATH:$HOME/apache-tomcat-5.5.16/common/lib/servlet-api.jar
$ cd exemplo1.1
$ cd WEB-INF/classes
$ javac exemplo/*.java
3.4 Pacotes WAR abertos e fechados

Observe que o exemplo já está organizado na estrutura de diretórios especificada pelo formato WAR
Embora formalmente o formato WAR seja um arquivo compactado, a maioria dos servidores de
aplicação Java EE aceita uma pasta contendo subdiretórios na mesma estrutura
Mas vamos montar o pacote assim mesmo, pois ele é exigido por alguns servidores Java EE e
pelas ferramentas para deployment remoto do Tomcat
3.5 Montando um Pacote WAR

Estando na sua pasta home, execute o comando
$ jar cvf exemplo1.1.war -C exemplo1.1 .
Observe o uso da opção -C e que o últim argumento é um ponto, indicando o diretório corrente
Isto é necessário porque o pacote WAR não deve contar a pasta de topo da aplicação (no caso,
exemplo1.1)
24
3.6 Verificando um Pacote WAR

Liste o conteúdo do pacote usando o comando jar:
$ jar tvf exemplo1.1.war

0 Wed Mar 29 00:12:40 BRT 2006 META-INF/
44 Wed Mar 29 00:12:40 BRT 2006 META-INF/MANIFEST.MF
0 Tue Mar 28 07:23:10 BRT 2006 ./
423 Tue Mar 28 06:49:58 BRT 2006 index.jsp
166 Tue Mar 28 06:53:04 BRT 2006 el.jsp
289 Tue Mar 28 06:53:26 BRT 2006 hoje.jsp
0 Tue Mar 28 06:49:16 BRT 2006 WEB-INF/
0 Tue Mar 28 06:44:40 BRT 2006 WEB-INF/classes/
...
Também pode ser usado o comando unzip
$ unzip -t exemplo1.1.war
3.7 Auto-Deploy
A maneira mais fácil de fazer a instalação (deployment) de uma aplicação no Tomcat é copiar seu
pacote WAR (seja aberto ou fechado) para a pasta webapps
Feito a cópia, os logs do Tomcat deverão indicar que o novo pacote foi detectado e instalado
O novo pacote deverá então ser automaticamente listado como uma nova aplicação no Manager
e como um novo contexto no Admin
3.8 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
...
INFO: Deploying web application archive exemplo1.1.war

Verifique a presença da aplicação tanto no Manager quanto no Admin
O nome da aplicação será igual ao nome do pacote WAR, ou seja, “exemplo 1.1”

Se tudo estiver ok, a aplicação poderá ser acessada pela URL
http://127.0.0.1:8080/exemplo1.1
25
Note que uma aplicação web (ou contexto) é visto pelo o navegador como se fosse uma pasta
O resultado é exibido na figura ao lado:
Figura 3.1:

Para remover a aplicaçã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 aplicação foi desinstalada
$ tail apache-tomcat-*/logs/catalina.out
...
INFO: Undeploying context [/exemplo1.1]

É necessário recarregar o Manager ou clicar no link List Applications
O Manager não é atualizado automaticamente depois de um deployment ou undeployment!

Faça novamente o deployment, desta vez copiando o pacote aberto:
$ cp -rfp exemplo1.1 apache-tomcat-*/webapps
Observe que, embora o Manager reconheça a presença da aplicação, não há registro do seu
deployment nos logs do Tomcat
Agora use o link Undeploy do Manager para desinstalar a aplicação
Verifique que o Manager remove o “pacote WAR” (na verdade o subdiretório) da aplicação na
pasta webapps
26
3.12 Undeployment manual x Manager

Embora seja possı́vel fazer o undeployment (ou mesmo a atualização – redeployment) de uma
aplicação pela simples cópia de arquivos, isto pode deixar “rastros” da aplicação na pasta webapps
ou na pasta work do Tomcat
Isto porque o Tomcat, em sua configuração padrão, descompacta os pacotes WAR, e passa a usar
a versão “aberta” deste pacote
Assim pode ocorrer do Tomcat não perceber que o pacote WAR fechado foi atualizado
Fazer o undeployment pelo Manager garante que não foi deixado nenhum “rastro” do pacote
3.13 O Descritor web.xml

O arquivo WEB-INF/web.xml da própria aplicação configura uma série de parâmetros para o con-
tainer web
Estes parâmetros são independentes do servidor utilizado, mas não incluem configurações globais
como portas TCP
É comum este arquivo estar com erros de sintaxe ou com o nome errado (por exemplo, o nome
da pasta WEB-INF escrito em minúsculas)
Neste caso, o Tomcat irá usar a configuração padrão na pasta conf/web.xml do servidor

O objetivo é mudar a página inicial da aplicação
Faça o deployment da aplicação como um pacote aberto, conforme as instruções do último
exercı́cio
Confirme que a aplicação esteja ok (a URL http://127.0.0.1:8080/exemplo1.1 exibe uma página
inicial contendo vários links)
Altere o arquivo WEB-INF/web.xml da aplicação, trocando “index.jsp” por “hoje.jsp” dentro do
elemento <welcome-file-list>

Repita o deployment da aplicação como um pacote aberto (copie a pasta e seu conteúdo por sobre a
pasta já existente em webapps)
O Tomcat irá detectar mudanças no descritor web.xml e fazer o re-deployment da aplicação
Os logs do Tomcat irão indicar a realização da operação:
INFO: Reloading context [/exemplo1.1]
Depois de confirmada a mudança na página de boas-vindas da aplicação, retorne a configuração
para a página index.jsp
3.16 Re-deployment Automático

A instalação padrão do Tomcat monitora o descritor web.xml de cada aplicação, recarregando (re-
deployment) em caso de mudanças
Este comportamento pode ser desabilitado, pois é indesejável em servidores de produção
Mudanças em páginas JSP são detectadas e efetivas no próximo acesso a página
Mudanças em classes Java exigem a recarga manual da aplicação pelo Manager (link Reload)
27
3.17 Construção de Pacotes WAR com Ant

Em uma aplicação real, a estrutura de pastas para arquivos HTML / JSP, classes Java e bibliote-
cas pode ser bastane complexa, inviabilizando a construção dos pacotes WAR manualmente com o
comando jar
Além disso, muitos desenvolvedores não vão querer enviar os fontes das classes Java juntamente
com os binários (pacote WAR) da aplicação
O padrão de fato para estas atividades é o uso de scripts Ant, pois eles são portáveis, ao contrário
de scripts shell, que rodam apenas em Unix e Linux
3.18 Instalação do Ant

Visite http://ant.apache.org e clique no link “Binary Distributions”
Baixe o arquivo apache-ant-1.6.5-bin.zip (ou uma versão mais recente) e descompacte na sua
pasta home
Defina a variável de ambiente ANT HOME apontando para o diretório de instalação do Ant
$ export ANT_HOME=$HOME/apache-ant-*
Acrescente a pasta bin do Ant ao path de comandos do shell
$ export PATH=$PATH:$ANT_HOME/bin
3.19 Verificando a Instalação do Ant

Execute o comando ant:
3.20 $ ant -version

Apache Ant version 1.6.5 compiled on Jun 02 2005
Não precisamos dizer para os administradores e desenvolvedores com experiência em Linux para
configura o profile do usuário (ou do sistema) de modo a embutir a configuração para o Ant
Distribuições do Linux baseadas no JPackage (como o Fedora) poderão exigir também a edição do
arquivo /etc/ant.conf, caso contrário será usado o Ant fornecido com a distribuição (possivelmente
incompatı́vel com o JDK 1.5)
3.21 Scripts Ant

São chamados de buildfiles, e o comando ant executa por padrão o script no arquivo build.xml
Usam a sintaxe XML, organizado na hierarquia:
Projeto (project)
Alvo (target)
Tarefa (task)
Há tarefas pré-definidas para compilação, empacotamento e execução de aplicações Java, além de
manipulação de arquivos
Alvos podem depender uns dos outros, de modo similar a um Makefile
28
3.22 Exemplo com Ant

O instrutor fornecerá o arquivo exemplo1.2.zip contendo uma versão do primeiro exemplo organizada
da forma usual em projetos de desenvolvimento Java
Está incluso também um buildfile para compilar as classes e gerar o pacote WAR para deployment
no Tomcat
Na verdade, o próprio buildfile contém um alvo para fazer o deployment!
Observe que a nova versão do exemplo separa os fontes Java dos seus bytecodes, gerando um
pacote WAR mais “limpo”
3.23 Estrutura do Exemplo 1.2

• exemplo1.2
– build.xml
– dist
– html
∗ bean.jsp
∗ el.jsp
∗ ...
– src
∗ exemplo
∗ HojeServlet.java
∗ HojeBean.java
– WEB-INF
∗ classes
∗ web.xml

Entre na pasta exemplo1.2
$ cd $HOME/exemplo1.2
Abra o arquivo build.xml em um editor de textos e altere a linha abaixo para indicar a localização
correta da sua instalação do Tomcat
<property name="tomcat" value="/home/fernando/apache-tomcat-5.5.16" />
Use o Ant para compilar, empacotar e instalar a aplicação no Tomcat
$ ant all
29

Verifique o formato do pacote WAR gerado pelo Ant
$ jar tvf dist/exemplo1.2.war
Verifique pelo Manager e pelos logs que a aplicação foi instalada com sucesso
Acesse a página inicial do exemplo
http://127.0.0.1:8080/exemplo1.2
Note que o tı́tulo da página de boas-vindas foi modificado para diferencia-lo do exemplo 1.1
Note ainda que este exemplo define um display-name no descritor web.xml, e que este nome é
exibido pelo Manager
3.26 Deployment via Manager

Além do auto-deploy pela có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 aplicaçã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 será salvo em webapps

Faça com o Manager o undeploy de todas as aplicações de exemplo, deixando o Tomcat “limpo”
Confirme que a pasta webapps não contém mais nenhuma das aplicações de exemplo
Use o Ant para montar o pacote WAR do exemplo 1.2, como já foi visto
Use a captura no próximo slide como guia para o deployment do pacote WAR via Manager
O Manager deverá gerar uma página indicando “OK” e incluindo a nova aplicação na lista de
aplicações hospedadas pelo servidor

Confirme que a aplicação pode ser vista pelo navegador
Confirme a presença do pacote WAR na pasta webapps
Figura 3.2:
30
3.29 Configuração de Aplicações Web / Contextos

• Introdução ao server.xml
• Engines, hosts e contextos
• Configuração do contexto via server.xml
• Configuração do contexto via conf/host/context.xml
• Configuração do contexto via
• META-INF/context.xml
• Configuração do ambiente JNDI
3.30 Introdução ao server.xml

O arquivo conf/server.xml é o principal arquivo de configuração do Tomcat
Ele define os números de portas TCP, ativação de recursos como criptografia e clustering, e pools
de conexões a bancos de dados
Modificações no arquivo exigem o reinı́cio do servidor
É fácil descobrir o que alterar uma vez entendida a estrutura do arquivo, que corresponde a
própria arquitetura interna do Tomcat
3.31 Estrutura do server.xml

<Server> </item>é o próprio Tomcat
<Service></item> é um serviço oferecido para a rede (no momento apenas o container we
<Conector></item> é um protocolo para acesso por clientes do container web (HTTP o

<Engine></item> é o container em si
<Host></item> é um host virtual, baseado em nome ou IP

<Context> é uma aplicaç~
ao web
3.32 Engines, hosts e contextos

São os principais elementos de configuração do Tomcat
Dentro do engine são inseridas definições globais para todos os hosts e contextos do servidor
Um host permite a configuração de domı́nios virtuais atendidos pelo mesmo servidor
Um contexto é uma aplicação web, ou seja, um pacote WAR
3.33 Contextos implı́citos e explı́citos

Pacotes WAR (abertos ou fechados) copiados para a pasta webapps ou deployados via Manager são
configurados por contextos implı́citos, isto é, com configurações default
É possı́vel definir contextos explicitamente, armazenando o pacote WAR correspodente fora da
pasta webapps do Tomcat
31
3.34 Outros Elementos do server.xml

A maioria destes elementos podem ser inseridos em qualquer nı́vel da estrutura do Tomcat:
• configura a geração de logs, mas recomenda-se o uso do Log4J em vez deste elemento
• fornece configurações de autenticação de login e senha
• modifica o processamento de requisições, por exemplo para gerar logs de acesso ou depuração
da requisição HTTP
• pré-configura objetos na árvore JNDI

Mudar a porta 8080 para a porta padrão 80


<Connector port="80"
maxThreads="150" minSpareThreads="25"
maxSpareThreads="75"
enableLookups="false" redirectPort="8443"
acceptCount="100"
debug="0" connectionTimeout="20000"
disableUploadTimeout="true" />
Lembre de reiniciar o Tomcat para que a mudança tenha efeito!

Agora não é mais preciso especificar o número de porta, ex:
http://127.0.0.1/manager/html
3.36 Dicas
Não se esqueça de retornar o autoDeploy para true!
Salve uma cópia do server.xml original do Tomcat, pois os modelos e comentários inseridos nele
serão úteis no futuro!
Administradores de sistema preocupados com a segurança não irão querer misturar os arquivos
de aplicações com os arquivos do Tomcat, e podem conseguir isto modificando o atributo appBase
do elemento
3.37 Editando o server.xml via Admin

Como já vimos, a aplicação Admin serve essencialmente para modificar o server.xml e outros arquivos
de configuração do Tomcat
Ele tem a vantagem de não exigir o reinı́cio do Tomcat na maioria das alterações
Mas tem a desvantagem de remover todos os comentários do arquivo server.xml e re-formatar
todo o seu conteúdo
Além do botão “Save”, deve ser selecionado o botão “Commit Changes” para que as a maioria
das mudanças feitas via Admin tenham efeito
32
3.38 Exemplo do Admin

Esta captura ilustra a segunda parte do último exercı́cio sendo realizada pelo Admin em vez de pela
edição direta do server.xml
Figura 3.3:
3.39 Configuração de Contextos

Há várias formas de se configurar uma aplicação web (contexto) no Tomcat
Implicitamente, copiando o WAR para a pasta webapps (é o que fizemos até o momento)
Explicitamente, editando o server.xml
Explicitamente, criando um arquivo dentro da pasta conf/engine/host
Explicitamente, acrescentando na aplicação o descritor não-padrão context.xml

Faç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 exemplo 1.2
<Host appBase="webapps" autoDeploy="false"

liveDeploy="false" name="localhost">
<Context path="/teste1.2"
docBase="/home/fernando/exemplo1.2/dist/
exemplo1.2.war"
useNaming="false">
</Context>
</Host>
Lembre que não deve haver quebra de linha no docBase!

Reinicie o Tomcat e verifique se o novo contexto (teste1.2) é relacionado pelo Manager
Acesso o contexto pela URL http://127.0.0.1/teste1.2
33
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

Se for usado o nome de contexto “” (string vazia) a aplicação se torna a aplicação default do servidor
A aplicação default é aquela exibida quando a URL contém apenas o nome do servidor
Então edite o elemento no arquivo server.xml para eliminar o texto “/teste1.2”, deixando apenas
“”
Delete (ou mova para fora de webapps) a pasta ROOT, pois não podem haver duas aplicações
com o mesmo nome de contexto!
Reinicie o Tomcat
3.43 Exemplo 4/4

Reinicie o Tomcat
Verifique que o exemplo 1.2 agora é exibido em vez da página padrão do Tomcat quando se pede
a URL contendo apenas o nome do servidor:
http://127.0.0.1
3.44 Configuração do contexto via conf/engine/host

A hierarquia Engine / Host / Contexto pode ainda receber arquivos de configuração isolados dentro
da pasta conf, baseados nos atributos name de cada um
O objetivo é permitir a configuração individualizada de contextos (aplicações) sem poluir demais
o server.xml
Veja que na instalação padrão o Admin e Manager são configurados pelos arquivos
conf/Catalina/localhost/admin.xml
conf/Catalina/localhost/manager.xml
3.45 Exercı́cio
Crie o arquivo outro1.2.xml dentro de conf/Catalina/localhost, com o conteúdo:
<?xml version="1.0" encoding="UTF-8"?>

<Context
path="xpto"
docBase="/home/fernando//exemplo1.2/dist/
exemplo1.2.war"
useNaming="false">
</Context>
Reinicie o Tomcat
Verifique que a URL http://127.0.0.1/outro1.2 passa a exibir o conteúdo do exemplo 1.2
Note que o atributo path é ignorado dentro a pasta conf/engine/host
34
3.46 Configuração do contexto via META-INF/context.xml

Uma quarta forma de se configurar um contexto / aplicação web no Tomcat é acrescentando na
aplicação o descritor META-INF/context.xml
Ele segue a mesma sintaxe do elemento dentro do server.xml ou do arquivo do contexto em
conf/engine/host
A configuração pelo descritor não-padrão só será reconhecida pelo Tomcat caso a aplicação seja
instalada explicitamente pelo Manager!
Ou seja, o descritor context.xml será ignorado pelo auto-deploy
3.47 O descritor context.xml

O atributo path também é ignorado nesta configuração (vale o nome do pacote WAR)
Seu principal uso é para embutir na aplicação configurações que de outra forma teriam que ser
feitas nos arquivos do Tomcat, como DataSources e Realms (que serão apresentados na próxima
aula)
O exercı́cio do próximo tópico ilustra o uso do descritor proprietário context.xml
3.48 Configuração do ambiente JNDI

A plataforma Java EE especifica o uso da API JNDI para obtenção de objetos potencialmente
compartilhados entre aplicações diferentes ou entre elas e o servidor
O uso mais comum deste recurso é delegar para o servidor de aplicações o gerenciamento de
conexões com outros servidores, ex: bancos de dados e e-mail
Estas conexões devem ser descritas na configuração do Tomcat, de modo que uma aplicação web
deixa de ser auto-contida
O descritor context.xml resolve este problema

O instrutor irá fornecer o arquivo exemplo1.3.zip contendo uma versão modificada do Servlet dos
exemplos anteriores
Este servlet repete várias vezes a data corrente, de acordo com um valor obtido do ambiente
JNDI
Descompacte o arquivo zip na sua pasta home e execute o alvo default do buildfile incluso
O resultado será a geração do pacote WAR exempo1.3/dist/exemplo1.3.war que deverá ser ins-
talado via o Manager

Feito o deployment explı́cito pelo Manager, o Admin deverá mostrar, dentro do contexto “exem-
plo1.3”, o elemento de ambiente “NumeroMagico”
35
Figura 3.4:

A execução do exemplo pelo navegador deverá ser como nesta captura
Figura 3.5:

Experimente modificar o valor do “NumeroMagico” pelo admin e recarregar o Servlet
Não é preciso clicar em “Commit Changes!”
Note que a aplicação não vê a mudança
Somente depois que a aplicação seja recarregada pelo Manager o novo valor do NúmeroMágico
será utilizado
Mas observe que esta mudança é volátil (já que não foi confirmada / “commitada”) e será perdida
se o Tomcat for reiniciado
36
Capı́tulo 4
Aula 3
Nesta aula, aprendemos como configurar aplicações e o próprio servidor para aplicações que neces-
sitam acesso a recursos externos, como bancos de dados e bibliotecas. Em seguida, iniciamos a
apresentação dos recursos de segurança do Java EE
Tópicos:
• Instalação de bibliotecas e APIs de terceiros
• Configuração de DataSources
• Configurações de segurança (parte 1)
4.1 Instalação de Bibliotecas e APIs de Terceiros

Bibliotecas fornecidas com o Tomcat
Conceitos de classloaders do Java
Uso das pastas server, shared e common do Tomcat
Uso da pasta WEB-INF/lib
4.2 Bibliotecas Java

Bibliotecas Java são em geral fornecidas como pacotes JAR, que são arquivos ZIP contendo classes
Java compiladas (arquivos .class)
Muitas são utilizadas internamente pelo Tomcat
Outras são mandatórias em aplicações JavaEE
Além disso, qualquer aplicação pode necessitar de bibliotecas adicionais
4.3 Onde Instalar Bibliotecas

Conforme já visto na Aula 1, o Tomcat fornece vários diretórios onde podem ser colocadas bibliotecas
fornecidas como arquivos jar, mas cada um tem uma finalidade:
common/lib para bibliotecas que devam estar disponı́veis tanto para o container quanto para as
aplicações
shared/lib para bibliotecas que sejam compartilhadas por várias aplicações
Além disso, uma aplicação pode incluir bibliotecas para uso interno na sua própria pasta WEB-
INF/lib
37
4.4 Bibliotecas fornecidas com o Tomcat

Conforme já visto na Aula 1, o Tomcat fornece vários diretórios onde podem ser colocadas bibliotecas
fornecidas como arquivos jar, mas cada um tem uma finalidade:
common/lib para bibliotecas que devam estar disponı́veis tanto para o container quanto para as
aplicações
shared/lib para bibliotecas que sejam compartilhadas por várias aplicações
Além disso, uma aplicação pode incluir suas próprias bibliotecas na pasta WEB-INF/lib do seu
pacote WAR
4.5 Conceitos de classloaders do Java

Esta separação de diretórios permite ao Tomcat criar classloaders separados para o container web e
para cada aplicação
Um classloader na JVM indica quais classes podem ser vistas por que outras classes
Desta forma, classes internas ao Tomcat ficam “invisı́veis” para as aplicações
E classes de uma aplicação também ficam invisı́veis para outras aplicações
Isto evita conflitos de nomes de classes, e previne potenciais bugs de segurança
4.6 Uso das pastas server, shared e common

A pasta server não deve ser modificada pelo administrador ou desenvolvedor, pois contém apenas
classes internas ao próprio Tomcat
A pasta commons pode ter que ser modificada em alguns casos, por exemplo quando o próprio
Tomcat necessita acesso a uma biblioteca adicional, por exemplo o driver JDBC para autenticação
ou DataSources
Se o objetivo é apenas evitar a duplicação de bibliotecas em várias aplicações, por exemplo as
classes dos frameworks Struts ou JSF, deve ser usada a pasta shared
4.7 Exemplo de Bibliotecas

Vamos compilar uma classe em uma biblioteca e usar esta classe em uma página JSP, experimentando
a sua visibilidade de acordo com a pasta do Tomcat ond ela é instalada
O instrutor deverá fornecer o arquivo exemplo3.1.zip que contém os fontes para o exemplo
Este exemplo também traz um buildfile que ilustra como o Ant pode se comunicar diretamente
com o Manager para fazer o deploy, em vez de depender do Host estar configurado para auto-deploy
4.8 Task Customizado para o Manager do Tomcat

<taskdef name="deploy"
classpath="${tomcat}/server/lib/catalina-ant.jar"
classname="org.apache.catalina.ant.DeployTask"
/>
<taskdef name="undeploy"
classpath="${tomcat}/server/lib/catalina-ant.jar"
classname="org.apache.catalina.ant.UndeployTask"
/>
38
<target name="instala" depends="variaveis">

<deploy url="${url}"
username="${username}"
password="${password}"
path="/${war}" war="dist/${war}.war"/>
</target>
Lembre de modificar as propriedades username e password conforme sua configuração em tomcat-

users.xm
4.9 Compilando o Exemplo

Descompacte o arquivo exemplo3.1.zip na sua pasta home e configure o ambiente para o Ant, con-
forme visto na Aula 2 Edite o build.xml (pasta de instalação do Tomcat) e use o Ant para gerar o
pacote WAR da aplicação e o pacote JAR da biblioteca
$ ant
...
biblioteca:
[jar] Building jar: /home/fernando/ap-tomcat.src/exemplo3.1/dist/hoje.jar
empacota:
[jar] Building jar: /home/fernando/ap-tomcat.src/exemplo3.1/dist/exemplo3.1.war

...
BUILD SUCCESSFUL

Faça o deployment da aplicação usando o Ant
$ ant instala
Se preferir, use o Manager para fazer o deploymento do arquivo dist/exemplo3.1.war

Verifique pelo Manager ou pelos logs do Tomcat que a aplicação está disponı́vel
Entre na aplicação, pela URL http://127.0.0.1/exemplo3.1
O resultado deverá ser uma página de erro do Tomcat, que inclui a mensagem:
The value for the useBean class attribute biblioteca.HojeBean is invalid.
39

Agora instale a biblioteca na pasta shared/lib do Tomcat
$ cp dist/hoje.jar ~/apache-tomcat-*/shared/lib
Reinicie o Tomcat e acesse novamente a aplicação. Desta vez ela irá funcionar, exibindo a data
corrente
Remova a biblioteca da pasta shared/lib e reinicie o Tomcat
Confirme que a aplicação deixou de funcionar, exibindo em vez da data corrente a mensagem:
java.lang.NoClassDefFoundError: biblioteca/HojeBean

Agora instale a biblioteca na pasta common/lib do Tomcat
$ cp dist/hoje.jar ~/apache-tomcat-*/common/lib
Reinicie o Tomcat e acesse novamente a aplicação. Ela irá funcionar, exibindo a data corrente,
da mesma forma como funcionou utilizando a pasta shared
Remova a biblioteca da pasta common/lib e reinicie o Tomcat
Confirme que a aplicação novamente deixou de funcionar

Agora instale a biblioteca na pasta server/lib do Tomcat
$ cp dist/hoje.jar ~/apache-tomcat-*/server/lib
Reinicie o Tomcat e acesse novamente a aplicação. Desta vez ela não irá funcionar, ao contrário
de quando foram utilizadas as pastas shared e common
Remova a biblioteca da pasta server/lib, apenas para não deixar “lixo” no servidor
4.14 Porque a Primeira Vez Foi Diferente?

Na primeira vez que a aplicação foi executada (sem a presença da biblioteca hoje.jar) o erro informado
pelo navegador foi:
The value for the useBean class attribute biblioteca.HojeBean is invalid.
Mas nas tentativas seguintes, o erro foi:
java.lang.NoClassDefFoundError: biblioteca/HojeBean
A diferença ocorre porque da primeira vez a página JSP ainda não havia sido compilada, mas
nas tentativas seguintes a página já estava compilada, pois havia sido executada uma vez com a
biblioteca presente
40
4.15 Uso da pasta WEB-INF/lib

Aplicações web JavaEE tem sua própria pasta de bibliotecas, dentro do seu próprio pacote WAR,
chamada WEB-INF/lib
Isto permite que aplicações diferentes, em um mesmo servidor, possam usar versões diferentes da
mesma biblioteca
Para que uma aplicação seja auto-contida (possa ser instalada sem configurações prévias do
servidor de aplicações) todas as bibliotecas necessárias devem estar dentro do pacote WAR
Mas isto pode gerar desperdı́cio de espaço em disco e maior consumo de memória
4.16 Exemplo de Biblioteca Dentro do Pacote

O instrutor fornecerá o arquivo exemplo3.2.zip, que é uma versão modificada do exemplo 3.1 para
incluir a biblioteca dentro do próprio pacote WAR
Também muda a formatação da data/hora para que seja possı́vel reconhecer a versão da biblioteca
em uso por cada aplicação
A idéia é rodar simultaneamente duas versões do mesmo programa (exemplo 3.1 e exemplo 3.2)
porém cada um usando versões diferentes da biblioteca hoje.jar
4.17 Exercı́cio
Refaça a primeira parte do exercı́cio anterior, de modo que o exemplo 3.1 esteja funcionando
Compile e instale o exemplo 3.2 usando o ant
$ ant
Note que, neste exemplo, o alvo default (all) já faz o deployment usando o Manager
Execute as duas aplicações, e verifique que cada uma exibe um formato de data / hora diferente,
comprovando que cada uma está usando a versão correta da biblioteca
Para o 3.1 é a biblioteca na pasta shared, para o 3.2 é a biblioteca dentro do WEB-INF
4.18 Configuração de DataSources

Porque usar DataSources
Criação de DataSource com pool de conexões
Uso de datasources pela aplicação via JNDI
4.19 Porque usar DataSources

Conexões a bancos de dados são recursos caros computacionalmente, pode ser inviável manter várias
conexões abertas em aplicações com grande quantidades de usuários, sendo que em um dado momento
a maioria delas estarão ociosas
Abrir e fechar conexões conforme a demanda (a cada página requisitada) é demorado, e iria
prejudicar o tempo de resposta do usuário
Um DataSource mantém um pool onde conexões ociosas podem ser requeridas e utilizadas por
outro processo
41
4.20 Pools de Conexão

Pode-se estabelecer um mı́nimo de conexões, de modo que picos repentinos possam ser atendidos
prontamente
Pode-se estabelecer um máximo, de modo que nem o servidor de aplicações nem o banco de dados
fiquem sobrecarregados
A aplicação, em vez de abrir e fechar conexões, requisita conexões do pool e as devolve o mais
cedo possı́vel
O servidor de aplicações é o responsável pelo gerenciamento do pool
4.21 Sobre o HSQLDB

Banco de dados relacional 100% Java que será usado nos exercı́cios
Pode operar em modo stand-alone, embutido em outra aplicação, ou como um servidor indepen-
dente
Poucas demandas de memória e processador
4.22 Baixando e Instalando o HSQLDB

Baixe o arquivo hsqldb 1 8 0 5.zip de http://www.hsqldb.org
Descompacte em sua pasta home
Configure o classpath para incluir as classes do HSQLDB
$ export CLASSPATH=$CLASSPAH:$HOME/hsqldb/lib/hsqldb.jar
Lembre que não há quebra de linha!
4.23 Criando o Banco de Dados

Crie uma pasta no seu home para armazenar os arquivos do banco de dados
$ mkdir $HOME/bd
Inicie o Database Manager do HSQLDB, que permite executar interativamente comandos SQL
java org.hsqldb.util.DatabaseManagerSwin
-url "jdbc:hsqldb:file:$HOME/bd/contatos;shutdown=true"
O comando acima irá criar o banco “contatos” dentro da pasta “bd” abaixo do home do usuário
4.24 Verificando o Banco de Dados

Finalize o Database Manager. Da forma ele foi executado, fica com acesso exclusivo ao banco de
dados
Reinicie o Database Manager, conectando ao mesmo banco “contatos”, e verifique se é possı́vel
recuperar os dados previamente armazenados, executando o comando SQL
select * from contatos order by nome
42
4.25 Inicializando e Verificando o BD do Exemplo
Figura 4.1:
4.26 Criação de DataSources

Podem ser definidas ao nı́vel de Engine, Host ou Context no Tomcat
Deve ser inserido o elemento especificando os parâmetros de conexão JDBC:
<Resource name="jdbc/Contatos" auth="Container"

type="javax.sql.DataSource"
maxActive="1" maxIdle="0" maxWait="-1"
username="sa" password=""
driverClassName="org.hsqldb.jdbcDriver"
url="jdbc:hsqldb:file:/home/fernando/bd/contatos;
shutdown=true"
/>
Lembre que não deve haver quebra de linha dentro do atributo url
4.27 Instalação do Driver do Banco no Tomcat

Como o pool de conexões é mantido pelo próprio Tomcat, mas a aplicação irá usa-lo para enviar
comandos SQL ao banco, as classes do driver JDBC do HSQLDB devem ser copiadas para a pasta
common/lib
$ cp $HOME/hsqldb/lib/hsqldb.jar $HOME/apache-tomcat-*/common/lib
Esta cópia deve ser feita mesmo que o DataSource seja configurado no META-INF/context.xml
da aplicação em vez de no server.xml do Tomcat
4.28 Uso de DataSources pela aplicação via JNDI

A aplicação usa o pool de conexão por meio do JNDI, e não toma conhecimento dos parâmetros de
configuração JDBC
Eis o código para se obter uma conexão: (tratamento de excessões omitido para simplificar)
43
InitialContext ctx = new InitialContext();

ds = (DataSource)ctx.lookup(
"java:comp/env/jdbc/Contatos");
Connection con = ds.getConnection();
E para devolver a conexão ao pool, basta fecha-la como se fosse uma conexão comum con.close();
4.29 Exemplo de DataSource

O instrutor irá fornecer o arquivo exemplo3.3.zip que contém uma aplicação que lista os registros do
banco de dados HSQLDB de contatos criado anteriormente
O exemplo utiliza o arquivo META-INF/context.xml ara definir o DataSource, e contém um
buildfile que faz a compilação e deployment da aplicação no Tomcat
É necessário editar o context.xml para indicar o caminho para os arquivos do banco de dados
Após o deployment, verifique no Admin a presença do DataSource dentro do contexto do exemplo
3.3
4.30 DataSource no Contexto da Aplicação
Figura 4.2:
4.31 Configurações de Segurança (Parte I)

Introdução à segurança declarativa do J2EE
Autenticação HTTP BASIC e DIGEST
Usuários, roles e resource-collections do J2EE
Encriptação de senhas
Autenticação Form-based
4.32 Introdução à segurança declarativa do J2EE

A idéia é que o desenvolvedor escreva o mı́nimo possı́vel de código para autenticar usuários e autorizar
o acesso às páginas da aplicação
44
Este controle deve ser delegado para o servidor de aplicações, que poderá faze-lo de forma mais
flexı́vel e segura
A configuração é feita em duas partes:
No descritor da aplicação (web.xml) são definidas regras de controle de acesso
Na configuração do servidor (server.xml ou context.xml) são definidos os bancos de dados de
usuários e roles
4.33 Autenticação HTTP BASIC e DIGEST

O protocolo HTTP prevê três mecanismos de autenticação
• BASIC envia a senha do usuário em claro (codificada em UUENCODE)
• DIGEST envia um hash da senha
• CLIENT-CERT exige a instalação de um certificado digital X-400 no navegador do cliente,

devidamente assinado por uma CA
A senha fornecida pelo usuário no BASIC ou DIGEST é mantida em memória pelo navegador,
que a retransmite a cada página requisitada
4.34 Qual Mecanismo Escolher?

O BASIC é o único obrigatório, e é seguro apenas se usado em conjunto com SSL / TLS
Versões recentes do Firefox e IE suportam DIGEST, que é seguro por si só
O CLIENT-CERT é pouco usado na prática pelas dificuldades logı́sticas de distribuição dos
certificados digitais para os usuários
Em nenhum destes mecanismos a aplicação tem controle sobre a aparência da janela de login
exibida pelo navegador
Não existe um logout devido à natureza stateless do HTTP
4.35 Usuários, roles e resource-collections do J2EE

No descritor da aplicação, é definido qual o método de autenticação a ser utilizado
Além disso, padrões de URLs são agrupadas e são definidos os usuários e roles (grupos de usuários)
com acesso ao conjunto de URLs
Podem haver páginas públicas e restritas na mesma aplicação
4.36 Definição do Mecanismo

Não são especificados usuá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>
45
O web.xml também indica o mecanismo de autenticação para a aplicação
<login-config>
<auth-method>BASIC</auth-method>
<realm-name>
Exemplo de Segurança J2EE
</realm-name>
</login-config>
4.37 Páginas Protegidas

Então um conjunto de <url-pattern> é vincuado a um ou mais <role-name> dentro de um <security-
contraint>, criando uma área de páginas protegidas dentro da aplicação
<security-constraint>
<web-resource-collection>
<web-resource-name>
Paginas do Usuario
</web-resource-name>
<url-pattern>/usuarios/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>usuario</role-name>
</auth-constraint>
</security-constraint>
4.38 Exemplo de Segurança BASIC

O instrutor irá fornecer o exemplo de configuração de segurança no arquivo exemplo3.4.zip
Este exemplo contém apenas páginas JSP, não havendo necessidade de compilar classes Java, por
isso não inclui um buildfile para o Ant
Basta copiar a pasta exemplo3.4 gerada pela descompactação do zip para a pasta webapps do
Tomcat:
Lembre-se de reativar o auto-deploy do Host localhost, que foi desativado na Aula 1!
Ou então faça manualmente o empacotamento e deployment
4.39 Estrutura do Exemplo

exemplo3.4
index.jsp (página pública)
erro404.jsp (página pública)
Admin
index.jsp (página restrita ao role \administrador")
usuarios
index.jsp (página restrita ao role \usuarios")
WEB-INF
web.xml (define as regras de controle de acesso)
46
4.40 Criação dos Usuários

A configuração padrão do Tomcat já define no server.xml um banco de dados de usuários e senhas,
que é utilizado pelas aplicações Manager e Admin
Este banco de dados é o arquivo conf/tomcat-users.xml
Acrescente dois usuários, um com cada perfil pedido
<user username="chefe" password="boss" roles="administrador"/>

<user username="fulano" password="testando" roles="usuario"/>
E reinicie o servidor
4.41 Configuração do Realm

Um banco de dados de usuários e senhas no Tomcat é chamado de Realm. Eis a definição do Realm
padrão (já vem com o Tomcat!):
...
<GlobalNamingResources>
...
<Resource auth="Container"
name="UserDatabase"
type="org.apache.catalina.UserDatabase"
pathname="conf/tomcat-users.xml"
factory="org.apache.catalina.users.
MemoryUserDatabaseFactory"/>
</GlobalNamingResources>
...
Este realm pode ser editado pelo Admin sem necessidade de reinicar o Tomcat
4.42 Vinculação do Realm

Como a configuração padrão vincula o Realm ao Engine, ele está disponı́vel a todos os Hosts e
consequentemente a todas as aplicações (Contexts)
...
<Engine
defaultHost="localhost"
name="Catalina">
<Realm className="org.apache.catalina.realm.
UserDatabaseRealm"/>
<Host
...
47

O Tomcat já esta configurado com um Realm
Os usuários fulano/testando e chefe/boss já foram criados, respectivamente com os perfis usuarios
e administrador
Já foi feita a instalação do exemplo3.4, via auto-deploy como um pacote WAR aberto
Então podemos entrar na aplicação (http://127.0.0.1/exemplo3.4)
Escolha o link “Páginas dos usuários”
Faça o login como “fulano” senha “testando”

Note que o nome exibido na janela de login (“Exemplo de Segurança J2EE”) provém do <login-
config> no web.xml da aplicação
Figura 4.3:

O resultado será a página contendo o texto “restrita a usuários autenticados”
É possı́vel voltar para a página inicial e dela para a página de usuários sem ter que digitar
novamente a senha
Mas a tentativa de acessar a página dos administradores irá gerar uma página dizendo “Você não
tem acesso à página:”
Note que a página de erro de acesso é uma página da aplicação (erro404.jsp) e que obviamente
não pode estar em uma área protegida

Não existe forma segura de se fazer um logout pelo HTTP, então para que seja possı́vel testar o
usuário “chefe” será necessário fechar TODAS as janelas do navegador que estejam abertas
Então retorne à aplicação, escolha o link “Páginas dos Administradores” e então faça o login
como “chefe” senha “boss”
Note que o “chefe” não tem acesso às páginas dos usuários, porque ele não tem o role “usuario”
– vamos corrigir isso!
48

Entre no Admin e edite o usuário “boss” para acrescentar a ele também o perfil “usuário” (não é
preciso reiniciar o Tomcat)
Figura 4.4:

Ou então edite manualmente o arquivo conf/tomcat-users.xml e reinicie o Tomcat
Confirme que agora o “chefe” pode navegar tanto nas páginas dos usuários quanto nas páginas
dos administradores
4.49 Encriptando Senhas

Note que, no arquivo tomcat-users.xml, as senhas estão em claro, o que na maioria dos casos não é
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 JavaSE
Note que as senhas continuam sendo trasmitidas em claro do navegador para o Tomcat se for
usado o BASIC!
4.50 O que é um algoritmo de hash?

É um algoritmo que gera um número bem grande, aparentemente aleatório, à partir de um bloco de
informações
Qualquer mudança no bloco gera um novo número (chamado valor do hash)
Não é matematicamente possı́vel recriar o bloco de informações original à partir do valor do hash
De modo que mesmo o administrador do Tomcat não consegue ver as senhas cadastradas pelos
usuários – ele pode apenas configurar uma nova senha
49

Termine o Tomcat
Edite o arquivo server.xml como se segue:
<Realm className="org.apache.catalina.realm.
UserDatabaseRealm" digest="MD5" />
Note que, embora o banco de dados de senhas seja definido em um , quem valida as senhas é um
Abra para edição o arquivo tomcat-users.mxl
Compile o programa CriptografaSenha.java, fornecido pelo instrutor, para gerar as versões crip-
tografadas de cada senha no arquivo

Por exemplo, para criptografar a senha do “fulano”, faça:
$ java CriptografaSenha MD5 testando

caa9c8f8620cbb30679026bb6427e11f
E a entrada correspondente em tomcat-users.xml ficaria assim:
<user username="fulano"
password="caa9c8f8620cbb30679026bb6427e11f"
roles="usuarios"/>
Com todas as senhas encriptadas, inicie o Tomcat e use o exemplo3.4 para verificar que as senhas
criptografadas são reconhecidas
4.53 Autenticação Form-based

Como os mecanismos de autenticação previstos pelo HTTP não fornecem à aplicação controle sobre
a aparência da janela de login, o JavaEE fornece como alternativa um quarto mecanismo
O mecanismo “form-based” utiliza cookies para registrar no navegador quando um usuário já foi
autenticado ou não pelo container
Este cookie é seguro mesmo sem o uso de SSL / TLS, mas a senha é transmitida em texto claro
durante o login – Portanto verifique se o desenvolvedor tomou o cuidado de colocar a página de login
em https:
4.54 Configuração da Aplicação

Muda apenas o <login-config>, que deve especificar as páginas de login e de erro de login (que não
devem ser protegidas!)
<login-config>
<auth-method>FORM</auth-method>
<form-login-config>
<form-login-page>/login.jsp
50
</form-login-page>
<form-error-page>/loginInvalido.jsp
</form-error-page>
</form-login-config>
</login-config>
Definições de roles e <security-constraints> permanecem inalteradas
4.55 Configuração do Tomcat

Não muda pelo uso da autenticação form-based, na verdade os mesmos Realms podem ser compar-
tilhados por aplicações utilizando métodos de autenticação diferente
O instrutor fornecerá o arquivo exemplo3.5.zip que é igual ao exemplo 3.4 exceto por usar auten-
ticação form-based
Os alunos agora devem ser capazes de fazer o deployment deste exemplo e de validar o seu
funcionamento sem necessidade de instruções detalhadas
Note que agora é possı́vel ter um logoff explı́cito – basta finalizar a sessão HTTP
4.56 Single Sign-On

Na configuração padrão, o Tomcat irá tratar de forma independente a autenticação para cada
aplicação / contexto, mesmo que seja utilizado um mesmo realm
Sites mais complexos podem ser compostos por várias aplicações e neste caso seria interessante
fazer o login uma única vez para todo o container web
Acrescente esta definição no para ativar o login único para o container
<Valve className="org.apache.catalina.authenticator.
SingleSignOn" />

Antes de ativar o de SingleSignOn, confirme que é possı́vel logar com usuários diferentes nos exemplo
3.4 e 3.5
Acrescente o conforme as instruções do slide anterior
Reinicie o Tomcat
Entre primeiro no exemplo 3.4, e faça o login como “fulano”
Entre agora no exemplo 3.5, e veja que ele permite o acesso às páginas restritas sem pedir o login
form-based

Faça o logoff no exemplo 3.5
Verifique que o exemplo 3.5 agora pede senha para as páginas restritas
Retorne ao exemplo 3.4 e verifique que ele permanece logado, apesar do logoff feito pela outra
aplicação
O motivo desta aparente incoerência é que o navegador não toma conhecimento do logoff no
Tomcat, e mantém sua senha em memória para o BASIC
Portanto, o single sign-on exige que todas as aplicações usem autenticação form-based
51
Capı́tulo 5
Aula 4
Nesta aula, continuamos a apresentação dos recursos de segurança do Java EE e do Tomcat, incluindo
o uso de SSL / TLS (criptografia) e depois seremos apresentados às configurações de hosts virtuais
e de logging
Tópicos:
• Configurações de segurança (parte 2)
• Configuração de hosts virtuais
• Configurações de logging
5.1 Configurações de Segurança

• Autenticação via banco de dados
• Autenticação via diretório LDAP (OpenLDAP)
• Segurança programática do J2EE
• Restrições de IP / métodos HTTP pelo Tomcat
• Conexões seguras (SSL/TLS) no Tomcat
5.2 Autenticação via banco de dados

O elemento permite que seja especificada a classe responsável por fazer a validação de login e senha
Uma das opções é o DatasourceRealm, que obtém usuários, senhas e roles de uma DataSource
JNDI
É 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 usuários gerado por outros
sistemas
5.3 Definição do DatasourceRealm

Eis a definição de um realm baseado em banco de dados
52
<Realm debug="0" className="org.apache.catalina.realm.DataSourceRealm"

dataSourceName="jdbc/Contatos"
digest="MD5"
userTable="usuarios"
userNameCol="login" userCredCol="senha"
userRoleTable="grupos"
roleNameCol="role"/>
A definição do DataSource “jdbc/Contatos” é a mesma vista na aula anterior

Aproveitando o banco de dados de contatos já criado, use 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(15) not null,
primary key (login, role) );
(Os comandos SQL deste slide e do próximo estão no arquivo usuarios.sql junto aos exemplos do
curso)

E insira dois usuários de teste
insert into usuarios values (’sicrano’,
’caa9c8f8620cbb30679026bb6427e11f’);
insert into usuarios values (’gerente’,

’ceb8447cc4ab78d2ec34cd9f11e4bed2’);
As senhas são respectivamente “testando” e “boss”

Além dos seus roles
insert into grupos values (’sicrano’,
’usuario’);
insert into grupos values (’gerente’,

’usuario’);
insert into grupos values (’gerente’,

’administrador’);
53

O instrutor fornecerá o arquivo exemplo4.1.zip que contém uma versão do exemplo 3.5 visto na aula
anterior
Descompacte o arquivo em sua pasta home
A diferença é que este exemplo define um DataSource e um Realm, obtendo as senhas do banco
de dados em vez do tomcat-users.xml
Como foi configurado um novo realm para o contexto, ele sobrepõe o realm do host para esta
aplicação apenas, não afetando o Manager e o Admin
5.7 Exemplo 4/4

Remova do server.xml o de single sign-on e reinicie o Tomcat
Crie um pacote war contendo todo o conteúdo do exemplo 4.1
$ jar cvf exemplo4.1.war -C exemplo4.1 .
Faça o deploy da aplicação pelo Manager, pois se usar o auto-deploy o descritor não-padrão
context.xml não será processado
Finalmente teste a aplicação pela URL http://127.0.0.1/exemplo4.1
Lembre de usar os logins “sicrano/testando” e “gerente/boss”
5.8 Autenticação via diretório LDAP (OpenLDAP)

O Tomcat também fornece o JNDIRealm que permite a autenticação contra serviços de diretório
LDAP como o OpenLDAP, Fedora Directory Server, Novell NDS e Microsoft AD
Entretanto, a configuração deste ambiente de testes é bastante intensiva e muito demorada para
a carga horária deste curso
Consulte os manuais do Tomcat para mais informações
5.9 Exemplo de JNDI Realm 1/2

O próximo slide ilustra um exemplo de Realm que seria adequado para o OpenLDAP em configuração
padrão, utilizando o schema inetOrgPerson
O Tomcat tenta se conectar (binding) ao OpenLDAP usando o login do usuário como o atributo
uid do diretório
Se o dn do usuário for encontrado no atributo uniqueMember de algum objetos dentro da ou
“grupos”, este objeto é considerado como sendo um role do usuário
Além disso, o próprio objeto usuário pode relacionar roles no atributo memberOf
5.10 Exemplo de JNDI Realm 2/2

<Realm
className="org.apache.catalina.realm.JNDIRealm"
connectionURL="ldap://localhost:389"
userBase="ou=people,dc=mycompany,dc=com"
54
userSearch="(uid={0})"
roleBase="ou=groups,dc=mycompany,dc=com"
roleName="cn"
roleSearch="(uniqueMember={0})"
userRoleName="memberOf"
/>
5.11 Segurança Programática do JavaEE

O modelo de segurança declarativa do J2EE, baseado em roles e URLs não atende a todas as neces-
sidades das aplicações
Isto leva muitos desenvolvedores a desenvolverem seus próprios sistemas de autenticação e controle
de acesso, que geralmente acabam sendo inflexı́veis ou contendo vulnerabilidades graves
Não há necessidade destes sistemas de segurança ad-hoc porque o JavaEE prevê APIs para obter
informações sobre o usuário autenticado e seus roles, o que é suficiente para a grande maioria dos
casos
5.12 APIs de Segurança do JavaEE

HttpServletRequest
• getRemoteUser() retorna o nome de login autenticado pelo protocolo HTTP
• getUserPrincipal() retorna o nome de login autenticado pelo container, seja pelos mecanismos
do HTTP ou pelo form-based
• isUserInRole() indica se o usuário corrente pertence ao role especificado
ServletRequest isSecure() indica se a conexão corrente é ou não criptografada
5.13 Logout
Como visto na Aula 3, só é possı́vel fazer explicitamente um logout com a autenticação form-based
Neste caso, basta encerrar a sessão HTTP, chamando HttpSession.invalidate()
Mas nada obriga o usuário a fazer o logout, e o servidor não tem como saber se o usuário deixou
o site ou fechou seu navegador
As sessões HTTP (e consequentemente os logins) são invalidados por inatividade, conforme con-
figuração no descritor web.xml
5.14 Logout por Inatividade

Eis como mudar o tempo de inatividade para 10 minutos (o padrão do Tomcat é de 30 minutos)
Basta acrescentar ao web.xml da aplicação em WEB-INF ou então modificar o web.xml padrão
na pasta conf
55
<session-config>
<session-timeout>10</session-timeout>
</session-config>
O tempo de inatividade pode ainda ser configurado progamaticamente chamando HttpSession.setMaxIna

e passando o tempo em segundos
5.15 Restrições de IP / métodos HTTP pelo Tomcat

Os recursos padrão de segurança do JavaEE prevêem ainda:
• Restrição de métodos HTTP
• Restição ao uso de uma conexão segura
Além disso, o Tomcat pode ser configurado para impor restrições de firewall baseado em:
• Nomes de host do navegador
• Endereço IP do cliente
5.16 Exemplo de Restrições No Descritor web.xml 1/2

Muitos administradores querem garantir que certas páginas não possam ser acessadas via GET, mas
apenas por POST para evitar ataques de inserção de HTML e de Cross-Site Scripting Relacione
dentro do elemento <web-resource-collection> os nomes dos métodos HTTP autorizados:
<web-resource-collection>
<url-pattern>/admin/*</url-pattern>
<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint>
...
5.17 Exemplo de Restrições No Descritor web.xml 2/2

Para garantir que certas páginas só possam ser acessadas por meio de conexões seguras (criptogra-
fadas)
Acrescenteo aoelemento <security-constraints> o elemento <transport-guarantee>
...
<user-data-constraint>
<transport-guarantee>
CONFIDENTIAL
</transport-guarantee>
</user-data-constraint>
56
5.18 Firewall Interno do Tomcat

As válvulas RemoteAddrValve e RemoteHostValve permitem 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.
RemoteHostValve"
allow=".*.empresa\.com\.br"/>
Ou então, para aceitar apenas requisições da rede local da empresa, 192.168.0.0/24
<Valve className="org.apache.catalina.valves.
RemoteAddrValve"
allow="192\.168\.0\..*"/>
5.19 Regras de Host e Endereço IP

Note que os valores dos atributos allow e deny das válvulas de firewall do Tomcat utilizam expressões
regulares do pacote Jakarta Regexp
5.20 http://jakarta.apache.org/regexp/
Em geral elas seguem mesma sintaxe do grep e Perl
Podem ser especificadas várias expressões, separadas por vı́rgulas
Se um dos atributos for omitido, assume-se a expressão regular ”.*”que aceita qualquer coisa
5.21 Exercı́cio
Verifique o endereço IP do computador vizinho com o comando ifconfig
Modifique o exemplo 4.1 para incluir uma válvula negando o acesso dele ao exemplo (modifique
o context.xml da aplicação)
Faça um undeploy e novo deploy pelo Manager para efetivar a mudança
Confirme a presença da válvula pelo Manager
Verifique se o vizinho consegue ou não acessar a aplicação
Verifique também se o firewall local iptables não está impedindo a conexão
5.22 Exemplo 4.1 Visto Pelo Admin

Esta captura mostra o exemplo 4.1 conforme visto pelo Admin do Tomcat, exibindo o seu Realm e
válvula de firewall. Clicando em DataSources poderá ser vsita também a configuração para o acesso
ao HSQLDB
57
Figura 5.1:
5.23 Conexões seguras (SSL/TLS) no Tomcat

O Tomcat suporta, por meio do JSSE (Java Secure Sockets Extensions) conexões encriptadas nos
padrões SSL e TLS, ou seja, conexões https:
O JSSE é padrão no JavaSE desde 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 configuração será vista na Aula 5 (Integração do Tomcat com o Apache httpd)
5.24 Certificados Auto-Assinados

Sites de produção utilizam um certificado adquirido em uma empresa reconhecida por padrão pelos
navegadores, como a Verisign
Para testes e Intranets, é possı́vel gerar um certificado “auto-assinado”, que traz as mesmas
garantias de segurança que um certificado “oficial”
O que o certificado “oficial” garante é que o usuário está acessando o site real e não uma imitação
Por isso o navegador irá alertar o usuário quanto a certificados auto-assinados
5.25 Criando um Certificado para o Servidor 1/2

Primeiro, é necessário criar um KeyStore usando o keytool do JavaSE
$ keytool -genkey -alias tomcat -keyalg RSA
Tome nota da senha fornecida

Forneça os dados sobre sua empresa e localização, que serão registrados no certificado
O resultado é o arquivo .keystore na pasta home do usuário, que não deve ser acessı́vel a ninguém
mais
$ ls -l $HOME/.keystore
-rw-rw-r-- 1 fernando fernando 1373 Jan 23 13:57 /home/fernando/.keystore
5.26 Criando um Certificado para o Servidor 2/2

A opção -keystore do keytool permite indicar um caminho diferente para o KeyStore
Consulte os manuais do Tomcat para o procedimento caso você queira utilizar um certificado
“oficial” em um servidor de produção
58
5.27 Ativando o Conector SSL 1/2

O conector que aceita conexões criptografadas está comentado no server.xml padrão do Tomcat,
basta descomenta-lo:


minProcessors="5" maxProcessors="75"
enableLookups="true"
disableUploadTimeout="true"
acceptCount="100" debug="0"
scheme="https" secure="true"
keystorePass="secreto"
keystoreFile="/home/fernando/.keystore"
clientAuth="false" sslProtocol="TLS"/>
Ajuste os atributos destacados ao seu keystore
5.28 Ativando o Conector SSL 2/2

Caso a porta 8443 seja alterada (por exemplo, para o padrão 443) deve se alterado também o
redirectPort do conector HTTP não-encriptado:


MaxHttpHeaderSize="8192"
maxThreads="150" minSpareThreads="25"
maxSpareThreads="75"
enableLookups="false" redirectPort="8443"
acceptCount="100" connectionTimeout="20000"
disableUploadTimeout="true" />
Este parâmetro faz com que o Tomcat automaticamente redirecione conexões para páginas que
exigem conexões seguras

Crie o keystore e ative o conecto SSL conforme apresentado nos slides anteriores
Reinicie o Tomcat
Experimente acessar qualquer aplicação via SSL, por exemplo o Manager: https://127.0.0.1:8443/manag
O navegador irá reclamar duas vezes do certificado auto-assinado
A segunda reclamação é porque o certificado não corresponde ao nome DNS oficial do servidor
sendo acessado
Clique Ok em ambas
59

Eis os exemplos das duas janelas de advertências emitidos pelo Firefox:
Figura 5.2:

Conseguindo o acesso criptografado ao Manager, modifique o descritor web.xml do exemplo 4.1 para
exigir conexões SSL para páginas do administrador, usando o modelo apresentado anteriormente
nesta aula
Gere um novo pacote war para a aplicação
Faça o undeploy e novo depoloy pelo Manager
Confirme que, ao entrar nas páginas administrativas, o navegador passará automaticamente a
usar URLs https:
(O navegador continuará a usar conexões SSL quando sair das páginas administrativas)
5.32 Segurança declarativa e encriptação

Caso seja definido um <web-resource-collection> exigindo conexões encriptadas (CONFIDENTIAL),
qualquer tentativa de acessar as páginas da coleção em conexões não-encriptadas irá fazer com que
o Tomcat redirecione o usuário para uma conexão SSL
Então uma coleção com url-pattern “/*” irá garantir que todas as páginas são acessadas via SSL
Infelizmente não é possı́vel usar este artifı́cio para garantir que a página de login (form-based)
seja encriptada, porque o navegador nunca referencia diretamente esta página
5.33 Configuração de Hosts Virtuais

O que é um host virtual
Configuração de hosts no Tomcat
Uso das aplicações administrativas em hosts virtuais
5.34 O Que É um Host Virtual

É a configuração onde um mesmo servidor web atende a requisições cujas URLs informem nomes de
hosts diferentes
Para o usuário, eles são indistinguı́veis de hosts “reais”, hospedados por servidores independentes
60
Podem ser configurados de duas formas:
1. Um mesmo servidor é configurado com vários endereços IP diferentes

2. Vários nomes DNS diferentes são configurados para o mesmo endereço IP
5.35 Configuração de hosts no Tomcat

As duas formas de se configurar hosts virtuais são indiferentes para o Tomcat
Nos dois casos, basta acrescentar um novo elemento ao server.xml e decidir que aplicações serão
configuradas nele
Cada host pode ser sua própria pasta para auto-deploy
É possı́vel gerar logs separados para cada host, ou definir outras configurações em separado como
realms, válvulas e DataSources

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 definição de Host, mas dentro do único elemento
Engine
<Host name="hostvirtual"
appBase="/home/fernando/maiswebapps"
autoDeploy="true" />
Reinicie o Tomcat
Verifique no Admin a presença de dois Hosts

Acesse uma aplicação qualquer no host padrão, utilizando “127.0.0.1” ou “localhost” na URL
Instale uma aplicação simples (como o exemplo 1.1) no novo host virtual, copiando seu pacote
WAR para a pasta $HOME/maiswebapps
Não tente usar o Manager para o deployment, pois ele ainda não foi configurado para o host
virtual!
Acesse esta aplicação no host virtual usando uma URL como http://hostvirtual:8080/exemplo1.1
5.38 Aplicações administrativas x hosts virtuais

Cada host tem que ser configurado com sua própria instância do Manager
Por outro lado, um único Admin é capaz de gerenciar a configuração de todos os hosts
Há duas formas de se acrescentar um Manager a um host
Acrescentar um elemento apontando para o WAR do Manager, em server/webapps/manager ao
host virtual no server.xml
Criar a pasta conf/Catalina/hostvirtual e copiar para ela o arquivo conf/Catalina/localhostmanager.xml
61
5.39 Exercı́cio
Configure o Manager para o host virtual recém-criado, conforme as instruções no slide anterior
Acesse o novo Manager, e observe que ele relaciona um conjunto de aplicações diferente do
Manager para o 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
5.40 Configurações de Logging

A importância do logging
Introdução ao Logging no J2EE e Log4J
Categorias e nı́veis de logs
Configuração de appenders
5.41 A importância do logging

A manutenção de um registro de atividades do servidor é fundamental para identificar e isolar
problemas de segurança, instabilidade ou performance
Por outro lado, logs de servidores web podem crescer rapidamente
E misturam informações referentes a vários usuários e aplicações distintos, além das informações
referentes ao próprio servidor de aplicações
5.42 Introdução ao Logging no J2EE e Log4J

O Tomcat utiliza a biblioteca Commons Logging do Projeto Jalarta (http://jakarta.apache.org/commons/lo
Desta forma, ele pode ser configurado tanto para a Logging API padrão do JavaSE quanto para
o mais popular Log4J
Ambos os pacotes oferecem grande flexibilidade em relação a filtros, nı́vel de detalhes e separação
das informações de log em arquivos separados ou mesmo em servidores remotos
Vale à pena estudar com cuidado a documentação das duas bibliotecas de logging
5.43 Conceitos de Logging 1/2

Categoria (category) identifica o componente que gera a mensagem de log, de modo que seja possı́vel
registrar as mensagens de alguns componentes mas não de outros
Nı́vel (level, severity) identifica a criticidade da mensagem e o seu nı́vel de detalhamento. Nı́veis
mais altos registram menos informações nos log, e nı̃veis mais baixos registram mais
Saı́da (handler, appender) indica o local onde o log será registrado, em geral um arquivo texto
Formatador (formatter, layout) diz como uma saı́da deve formatar as informações recebidas
5.44 Categorias de log do Tomcat

O Tomcat nomeia suas categorias de log com o prefixo org.apache.catalina.core.ContainerBase
E depois dele podem ser especificados [Engine].[Host].[Contexto]
62
5.45 Nı́veis de Log do JavaSE

O nı́vel INFO pode ser mudado, por exemplo, para:
• SEVERE (menos detalhes, registra apenas erros crı́ticos)
• FINEST (mais detalhes, exibe informações sobre o funcionamento interno do Tomcat)
• ALL (registra todas as mensagens, sem descartar nada)
• OFF (não registra nada)
Consulte os JavaDocs da classe java.util.logging.Level para saber sobre todos os nı́veis possı́veis
no JavaSE
5.46 Logs Padrão do Tomcat 1/2

A configuração padrão do Tomcat gera um conjunto de arquivos de log na pasta log
A configuração padrão para a Logging API está na pasta conf, no arquivo logging.properties
O Tomcat substitui o LogManager do JDK pelo sua própria implementação, chamada JULI
O JULI permite um prefixar os nomes de classe dos handlers, simplificando a configuração (não
é mais necessário declarar explicitamente aliases para handlers da mesma classe)
5.47 Logs Padrão do Tomcat 2/2

A configuração padrão gera os arquivos:
catalina.out contém a saı́da padrão e de erros da JVM, além de uma duplicata das mensagens do
Tomcat
catalina..log contém as mensagens do Tomcat em si
localhost..log contém mensagens especı́ficas para o host “localhost” e seus contextos
manager..log e admin..log contém as mensagens das duas aplicações administrativas, separadas
das aplicações do usuário no host “localhost”
5.48 Logs por Contexto

É fácil usar o modelo fornecido pelo logging.properties para gerar um arquivo de log separado para
uma aplicação web
O processo consiste em:
1. Acrescentar um novo handler na relação no inı́cio do arquivo
2. Configurar este handler informando o nı́vel de severidade das mensagens registradas e o prefixo
do nome do arquivo
3. Vincular o hander a um contexto
63
5.49 Exemplo de Log por Contexto 1/2

Alterações em conf/logging.properties
handlers = 1catalina.org.apache.juli.FileHandler, 2localhost.org.apache.juli.FileHandl

3manager.org.apache.juli.FileHandler, 4admin.org.apache.juli.FileHandler,
5host-manager.org.apache.juli.FileHandler,
6exemplo.org.apache.juli.FileHandler, java.util.logging.ConsoleHandler
...
6exemplo.org.apache.juli.FileHandler.level = INFO
6exemplo.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
6exemplo.org.apache.juli.FileHandler.prefix = exemplo.
5.50 Exemplo de Log por Contexto 2/2

...
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/exemplo].level = INFO
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/exemplo].handlers = 6ex
Cada “bullet” indica uma linha do arquivo de propriedades, que nao deve ser quebrada
O resultado destas modificações é a geração do arquivo exemplo..log contendo apenas as mensa-
gens para o contexto “/exemplo”
5.51 Configuração de appenders

O Tomcat não usa os appenders padrões do JavaSE, porque eles não fornecem capacidades impor-
tantes como a rotação de logs
Rotação de logs consiste em se mudar periodicamente o nome do arquivo de log, evitando que ele
fique cheio demais
É responsabilidade do administrador remover ou copiar para backup logs antigos
Para necessidades mais especı́ficas, recomenda-se configura o Tomcat para usar o Log4J em vez
da Logging API do JavaSE
5.52 Logs de Acesso

Os logs de acesso formam um conjunto diferente de logs, que não são tratados pelo Commons Logging
mas sim por uma válvula do Tomcat
Os logs abordados anteriormente informam sobre o funcionamento do próprio Tomcat
Logs de acesso registram páginas visitadas pelos usuários, permitindo gerar estatı́sticas de uti-
lização e tempo de resposta para o site ou aplicações isoladas
5.53 Configurando Logs de Acesso

Acrescente no nı́vel desejado (Engine, Host ou Context) uma válvula segundo o modelo:
<Valve className="org.apache.catalina.valves.AccessLogValve"
directory="logs"
64
prefix="localhost_access_log."
suffix=".txt"
pattern="common"
resolveHosts="false" />
O padrão “common” segue o modelo do Apache Httpd e reconhecido por ferramentas de análise
como o Webalizer
65
Capı́tulo 6
Aula 5
Nesta aula, somos apresentados aos recursos de integração do Tomcat com servidores web nativos,
especialmente o Apache, e vemos como estes recursos podem ser utilizados para a construção de
clusters de servidores de aplicações
Tópicos:
• Integração com Apache Httpd
• Configurações de clustering (parte 1)
6.1 Integraçã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 páginas estáticas com Apache e Servlets / JSP com Tomcat
Integração x segurança e logging>
6.2 Servidores Nativos x Tomcat 1/2

Situações onde espera-se que servidores web nativos tenham melhor performance que o Tomcat
Grandes quantidades de usuários simultâneos, navegando em sites na sua maior parte estáticos
Download de arquivos volumosos, como músicas, vı́deos e relatórios em PDF
Grandes quantidades de conexões encriptadas
Uso de aceleradores de hardware para criptografia
6.3 Servidores Nativos x Tomcat 2/2

Situações onde um servidor nativo se torna necessário para complementar o Tomcat
Partes do site usando outras tecnologias, por exemplo CGI, PHP, ASP ou Cold Fusion
Uso de plug-ins de servidores web (módulos do Apache ou ISAPI)
Proxies reversos e aceleradores web
Distribuidores de carga
66
6.4 Arquitetura do Tomcat(Simplificada)
Figura 6.1:
6.5 Conectores HTTP e AJP

Os conectores são os componentes do Tomcat responsáveis por receber conexõ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 usuário, o Conector Jk permite
comunicação otimizada usando o protocolo AJP
6.6 O mod jk
É um plug-in de servidor web que acrescenta o suporte ao protocolo AJP
Há versões para Apache, ISAPI e NSAPI
Deve ser compilado em relação à versão especı́fica e plataforma do servidor web
Com sorte, poderá ser encontrado um binário pré-compilado para o seu servidor (mas verifique a
versão!)
Daqui em diante assume-se que o servidor web é o Apache 2.x fornecido com sua distribuição do
Linux
6.7 Instalando o mod jk

Há três formas de se obter e instalar o mod jk em Linux
Utilizando um pacote fornecido pela sua distribuição
Utilizando binários pré-compilados fornecidos pela ASF
Compilando você mesmo à patir dos fontes
6.8 Instalando o Pacote 1/2

Neste exemplo, considera-se o uso da distribuição Fedora Core 4
Visite http://download.fedora.redhat.com/pub/fedora/linux/
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
67
# rpm -ivh mod_jk*
6.9 Instalando o Pacote 2/2

Opcionalmente, baixe os pacotes na pasta de atualizações, visitando o mesmo servidor mas entrando
na pasta core/updates/4/i386/
Instale então os pacotes encontrados, mas poderá ser necessário instalar também outras atua-
lizações
Ou então, utilize o Yum, que instala automaticamente dependências e atualizações:
# yum install mod_jk mod_jk-manual
Prossiga para a configuração do mod jk
6.10 Instalando Binários Pré-Compilados 1/2

Verifique a versão do Apache instalada em sua distribuição
# apachectl status
# rpm -q httpd
Visite http://www.apache.org/dist/tomcat/tomcat-connectors/jk/binaries/ e procure pelo binário

especı́fico para a sua plataforma e versã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
6.11 Instalando Binários Pré-Compilados 2/2

Como root, copie o arquivo para a pasta de módulos de extensão da sua instalação do Apache
No Fedora Core, a pasta é /usr/lib/httpd/modules
6.12 Compilando o mod jk 1/2

Visite http://www.apache.org/dist/tomcat/tomcat-connectors/jk/source e localize o arquivo con-
tendo os fontes da versão mais recente
Por exemplo, jakarta-tomcat-connectors-1.2.15-src.tar.gz
Descompacte em sua pasta home
Localize o executável apxs, que é parte do Apache; tome nota do caminho
Na maioria das distribuições do Linux, será necessário instalar o pacote httpd-devel ou similar
68
6.13 Compilando o mod jk 2/2

Uma vez que o comando apxs esteja disponı́vel, entre na pasta onde foram descompactados os fontes
do mod jk e prossiga com a compilação
$ cd $HOME/jakarta-tomcat-connectors-*-src
$ cd jk/native
$ ./configure --with-apxs=/usr/sbin/apxs
$ make
$ su
# make install
6.14 Configuração do mod jk 1/4

Podemos ou editar diretamente o httpd.conf ou então usar a pasta /etc/httpd/conf.d
Editando o arquivo httpd.conf do Apache (em geral na pasta /etc/httpd/conf) e acrescente as
linhas:
LoadModule jk_module modules/mod_jk.so
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 é na verdade continuação da mesma linha!

Em vez de editar o httpd.conf, o conteúdo indicado no slide anterior pode ser colocado no arquivo
mod jk.conf, na pasta /etc/httpd/conf.d
Neste caso, o httpd.conf deve ter uma diretiva Include referenciando explicitamente este arquivo
ou sua pasta
Include conf.d/*
Agora é necessário fornecer o arquivo de configuração do próprio mod jk, indicado pela diretiva
JkWorkersFile, no caso /etc/httpd/conf.d/workers.properties

O arquivo workers.properties deve ter o seguinte conteúdo:
worker.list=no0
worker.no0.type=ajp13
worker.no0.host=127.0.0.1
worker.no0.port=8009
69
Inicie (ou reinicie) o Apache
# service httpd restart
Garanta que o Conector HTTP do Tomcat esteja escutando conexões na porta 8080, para não
entrar em conflito com o Apache
Garanta também que o Conector AJP padrão esteja configurado para a porta 8009

Garanta que o exemplo 4.2 esteja instalado no Tomcat, se necessário use o Manager, acessando o
Tomcat pela porta 8080
Inicie o Tomcat, se ele não estiver rodando
Acesse a URL http://127.0.0.1/exemplo4.2
O exemplo 4.2 deverá funcionar normalmente, inclusive a autenticação
Acesse o exemplo 4.2 também pela porta 8080, apenas para ter certeza de que as duas opções
estão disponı́veis, e que não é o Tomcat respondendo na porta 80
6.18 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
aplicações no Tomcat, é porque ele não passou estas requisições para o mod jk
Aumente o nı́vel de log do mod jk, alterando a linha no arquivo mod jk.conf (ou httpd.conf)
JkLogLevel debug
E verifique o log do mod jk (/var/log/httpd/access log)

Confira a digitação dos arquivos!
6.19 Dividindo Tarefas entre o Apache e o Tomcat

A configuração que fizemos repassa para o Tomcat todas as requisições direcionadas para uma de-
terminada aplicação web no Tomcat
É possı́vel ser mais seletivo, pelo uso das diretivas JkMount e JkUmount, por exemplo para deixar
que o Apache cuide de arquivos estáticos como páginas HTML e imagens
Note que, se isto for feito, eventuais configurações de controle de acesso terão que ser duplicadas
com os recursos do Apache

O instrutor fornecerá o arquivo exemplo5.1.zip que contém uma aplicação simples, formada por
algumas páginas JSP e HTML
Inicialmente, vamos acessar esta aplicação diretamente pelo Apache
Acrescente ao arquivo mod jk.conf a linha
Alias /exemplo5.1 /home/fernando/exemplo5.1
70
E reinicie o Apache
# service httpd restart
Agora acesse a aplicação pela URL http://127.0.0.1/exemplo5.1

Navegue pelos links exibidos pela aplicação
Verifique que a página JSP não exibe a data corrente, e que ela expõe para o navegador os
scriptlets
Tenha certeza de ter configurado no Tomcat a válvula de logs de acesso, conforme as instruções
na aula passada
Verificando os log de acesso do Tomcat e do Apache, e verifique que os arquivos do exemplo 5.1
aparecem apenas no log de acessos do Apache

Agora, vamos fazer com que o Tomcat execute apenas as pá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, porém mantendo o pacote aberto e sua
localização na pasta home do usuário
Então defina um elemento no server.xml ou então use o Manager, conforme a captura no próximo
slide

Reinicie o Tomcat e Navegue novamente pela aplicação
Verifique que apenas a página JSP aparece nos logs de acesso do Tomcat
Figura 6.2:

Usar extensões de arquivos na diretiva JkMount não é muito prático para Servlets, por isso veremos
uma outra alternativa
Edite o arquivo mod jk.conf conforme se segue:
71
#JkMount /exemplo5.1/*.jsp no0

JkUnMount /exemplo5.1/*.html no0
JkUnMount /exemplo5.1/*.gif no0
Reinicie o Apache e teste novamente a aplicação. Continuamos vendo no log de acesso do Tomcat
apenas a página JSP

Uma terceira variação consiste em usar os diretórios na diretiva JkUnMount

JkUnMount /exemplo5.1/html/* no0
JkUnMount /exemplo5.1/imagens/* no0
Note que, neste caso, a página inicial index.html será servida pelo Tomcat!
Obs:
A diretiva JkUnMount só existe no mod jk 1.2.8 em diante!
6.26 Integração x segurança e logging 1/2

O uso do Apache como front-end para o Tomcat oferece várias oportunidades de otimização de
desempenho (ex: mod proxy), mas acaba complicando um pouco a configuração e administração de
ambos
Aplicações com controle de acesso devem preferencialmente ser servidas inteiramente pelo Tomcat,
a não ser que as partes estáticas (como imagens) possam ser consideradas de acesso público
Embora o Apache reconheça autenticação HTTP, ele não reconhece form-based
6.27 Integração x segurança e logging 2/2

Não há 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 também facilita a evolução do ambiente para clusters
Basta o log de acessos do Apache, já que ele registra tanto as URLs servidas por ele quanto as
servidas pelo Tomcat
Erros de aplicação e banco de dados estarão nos logs do Tomcat, não do Apache
6.28 Configurações de Clustering (Parte I)

Conceitos de clustering web JavaEE
Arquitetura de clustering do Tomcat 5
Configuração de clusters para balanceamento de carga
Monitoração de Clusters
72
6.29 Conceitos de clustering web JavaEE

A plataforma JavaEE prevê desde a sua concepção a execução de aplicações em ambiente de cluster
Este recurso vem quase “de graça” para o desenvolvedor, enquanto que outras plataformas ele
exige programação cuidadosa e especializada
No caso de aplicações web, a natureza do protocolo HTTP ao mesmo tempo facilita e impõe
restrições
6.30 Cluster Web JavaEE
Figura 6.3:
6.31 O Balanceador ou Distribuidor

É o componente que recebe as requisições do navegador e as encaminha para um dos nós do cluster
Cria para o usuário no navegador a ilusão de que existe apenas um único servidor em vez de
vários containers web independentes
Há várias estratégias para sua implementação:
Switches e roteadores especializados - “layer 7”
Múltiplos endereços IP para um mesmo nome DNS (DNS round-robin)
Proxy reverso ou servidor font-end
6.32 Distribuição de Carga x Tolerância a Falhas

O cluster pode se limitar a distribuir a carga entre os vários nós
Por exemplo, um servidor atingiu o limite de sua capacidade, então acrescenta-se um segundo
servidor
Ou então o cluster pode fornecer também tolerância a falhas
Neste caso, os usuários que eram atendidos por um nó falho serão automaticamente redirecionados
para um dos nós sobreviventes
Não é trivial oferecer a tolerância a falhas sem perder atividades “em progresso”
6.33 Estado da Aplicação no HTTP

O HTTP é um protocolo sem estado, então qualquer requisição poderia ser entregue a qualquer nó
do cluster
73
Um mesmo usuário poderia ser a cada página atendido por um servidor diferente
Entretanto, aplicações web reais utilizam artifı́cios como cookies e sessões HTTP para manter o
estado de um usuário particular (por exemplo, uma cesta de compras)
Este estado tem que ser replicado entre os nós do cluster para que haja tolerância a falhas
6.34 Arquitetura de clustering do Tomcat 5

Sessões HTTP são implementadas por meio de um cookie “identificador de sessão” conforme manda
a especificação JavaEE
Para que um usuário possa recuperar as informações armazenadas na sua sessão ele deve ser
atendido sempre pelo mesmo servidor
Então o balanceador tem que reconhecer o cookie e “amarrar” as sessões ao mesmo nó
Para facilitar o balanceador, o Tomcat insere no cookie um identificador do nó
A arquitetura para tolerância a falhas será apresentada na Aula 6
6.35 Clusters para balanceamento de carga

O mod jk do Apache pode ser configurado para atuar como um balanceador de carga entre vários
servidores Tomcat
Ele inclusive é capaz de lidar com servidores de capacidades diferentes e distribuir a carga (usuários
/ sessões HTTP) proporcionalmente
Os servidores não precisam nem mesmo usar o mesmo SO!
6.36 Instalando um Segundo Tomcat 1/3

Para simular um cluster em um único computador, precisamos de duas instalação do Tomcat
Crie em sua pasta home o diretório cluster
$ mkdir $HOME/cluster
Descompacte o Tomcat dentro desta pasta
$ cd $HOME/cluster
$ unzip ../apache-tomcat*.zip
Renomeie a primeira instalação para no0 e descompacte novamente o Tomcat
$ mv apache-tomcat-* no0
$ unzip ../apache-tomcat*.zip
$ mv apache-tomcat-* no1

Edite o conf/server.xml do segundo Tomcat (no1) para mudar as portas TCP, evitando o conflito
com o no0
74
<Server port="8105" shutdown="SHUTDOWN">

...
...
...
Nas duas instalações do Tomcat (no0 e no1), altere edite o arquivo conf/tomcat-users.xml para
permitir o uso do Manager, conforme visto na Aula 1
<user username="tomcat" password="tomcat"

roles="admin,manager"/>

Garanta que não haja nenhum outro Tomcat em execução, e inicie cada um dos dois nós do cluster
$ cd no0/bin ; chmod a+x *.sh ; ./startup.sh

$ cd ../no1/bin ; chmod a+x *.sh ; ./startup.sh
Acesse a aplicação Manager em cada nó, confirmando que as duas instalações do Tomcat estão
funcionando
http://127.0.0.1:8080/manager/html (no0)
http://127.0.0.1:8180/manager/html (no1)
6.39 Exemplo de Teste do Cluster 1/4

O instrutor irá fornecer o arquivo exemplo5.2.zip, que é uma aplicação simples criada para testar o
cluster.
Descompacte o zip dentro da pasta webapps do primeiro nó 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/servlet-api.jar
$ javac exemplo/*.java
75

Copie a aplicação para o segundo nó
$ cd ../../..
$ cp -rf exemplo5.2 ../../no1/webapps
Altere a página index.jsp no segundo Tomcat ($HOME/cluster/no1/exemplo5.2/index.jsp) para

que a mensagem indique que ela está no segundo servidor (nó) do cluster
Utilizando o Manager, faça o Reload da aplicação em ambos os nós do cluster

Acesse as duas cópias da aplicação, mas utilizando navegadores web diferentes para cada uma, por
exemplo:
Firefox para http://127.0.0.1:8080/exemplo5.2
Mozilla para http://127.0.0.1:8180/exemplo5.2
Verifique que cada navegador exibe uma página diferente, indicando o nome do nó do cluster em
que ela foi acessada
Verifique ainda que, a cada recarga da página, a contagem aumenta. O objetivo é simular uma
aplicação com estado armazenado

Outros navegadores disponı́veis no Linux são Galeon, Epiphany e Konqueror, ou mesmo os navega-
dores de modo texto Lynx e Links
É necessário usar navegadores diferentes para simular usuários simultâneos – não basta abrir
outra janela!
Figura 6.4:
6.43 Configurando o Distribuidor 1/5

Agora que temos dois Tomcats e somos capazes de reconhecer pela pá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 à aplicação, removendo todas as diretivas
JkMount e JkUmount ciradas anteriormente, deixando apenas:
76
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 nós, vinculados a um balanceador, que é referenciado pelas diretivas JkMount
vistas no slide anterior

É necessário informar ao tomcat sobre o identificador de nó que deve ser acrescentado ao cookie da
sessão HTTP
Para tal, edite o sever.xml de cada nó do cluster, acrescentando no elemento o atributo jvmRoute:
<Engine name="Catalina" defaultHost="localhost"

debug="0" jvmRoute="no0">
<Engine name="Catalina" defaultHost="localhost"
debug="0" jvmRoute="no1">
Termine os dois nós Tomcat do cluster usando o script shutdown de cada um

Remova os arquivos de trabalho na pasta work em cada nó, de modo que sejam descartados todos
os dados armazenados em sessões HTTP
$ rm -rf $HOME/cluster/no0/work/*
$ rm -rf $HOME/cluster/no1/work/*
Inicie os dois nós Tomcat, e reinicie também o Apache

Acesse novamente a aplicação, usando agora a mesma URL, referenciando o Apache, nos dois
navegadores diferentes:
http://127.0.0.1/exemplo5.2
77

Note que cada navegador tem que ser atendido por um servidor diferente, e ter o identificador do nó
anexado ao seu identificador de sessão
Figura 6.5:
6.48 Se Algo Der Errado

Verifique que os dois servidores Tomcat estão no ar, acessando-os diretamente pelas portas 8080 e
8180
Confira os arquivos de configuração server.xml em cada nó, atentando para os três números de
porta (8085, 8080 e 8009; 8185, 8180 e 8109) e para o jvmRoute no Engine
Confira também os arquivos de configuração do mod jk, em especial as configurações do cluster
e de cada nó no workers.properties
Verifique os logs de cada nó Tomcat e do Apache em busca de mensagens de erro
6.49 Status do Cluster 1/2

O mod jk é capaz de gerar por conta própria uma página de status dos nós do cluster, útil para
administradores
Para ativar esta página, mapeie uma URL para o “status” do mod jk, editando o mod jk.conf
JkMount /jk status
Em seguida, ative a geração da página de status no worker.properties
worker.list=cluster,status
worker.status.type=status
...
Reinicie o Apache, apenas
78
6.50 Status do Cluster 2/2

Veja a página de status acessando a URL http://127.0.0.1/jk
Figura 6.6:
6.51 Exercı́cio Opcional 1/2

Para entender a importância do identificador do nó no cookie da sessão HTTP e do uso desta in-
formação pelo balanceador, vamos deixar o balanceador alterar entre os nós como se fossem servidores
web estáticos, sem aplicações
Altere o arquivo workers.properties:
worker.cluster.sticky_session=false
Termine os dois Tomcats

Limpe a pasta work de cada nó
6.52 Exercı́cio Opcional 2/2

Reinicie cada Tomcat e também o Apache
Abra os dois navegadores e faça cada um acessar a aplicação passando pelo Apache (http://127.0.0.1/exe
Observe como a contagem sempre fica em “1”, com a requisição sendo atendida alternadamente
por servidores diferentes no mesmo navegador
Veja também que o id de sessão muda a cada recarga da página, em ambos os navegadores
O Tomcat não consegue manter o vı́nculo com a sessão do usuário!
79
Capı́tulo 7
Aula 6
Nesta aula finalizamos a apresentação dos recursos de clustering do Tomcat e temos uma introdução
ao monitoramento e tunning do servidor para obter maior performance
Tópicos:
• Configurações de clustering (parte 2)
• Tunning e monitoração de performance
7.1 Configurações de Clustering (Parte II)

Configuração de clusters para tolerância à falhas
Erros de aplicação a evitar
Clusters x Aplicações Administrativas
Farming Deployer
7.2 Clusters Para Tolerância à Falhas

Recapitulando, o objetivo agora é simular um cluster onde os usuários de um servidor Tomcat são
automaticamente e transparentemente migrados para outro servidor
Para que isto ocorra, as informações armazenadas na sessão HTTP devem ser replicadas entre
todos os nós do clusters
Desta forma, qualquer nó pode dar continuidade a atividades iniciadas por outro nó
7.3 Arquitetura de clustering do Tomcat 5 1/2

O Tomcat utiliza multicast IP para identificar os nós do cluster que ainda estão ativos
Na verdade cada nó anuncia sua presença aos demais utilizando os multicasts
As informações em si são transferidas por meio de conexões TCP regulares para os demais nós
existentes
Se um nó fica muito tempo sem anunciar sua presença, os demais nós o consideram como inativo
e deixam de lhe enviar informações
7.4 Arquitetura de clustering do Tomcat 5 2/2

Havendo vários clusters independentes na mesma rede, cada cluster deve ser configurado com um
endereço IP de multicast diferente
80
Quando ocorrerem modificações nas sessões HTTP de um nó, estas modificações são transferidas
por meio de conexões TCP regulares para os demais nós presentes
Quando um novo nó entra no cluster (se torna ativo) ele localiza os demais nós e pede que cada
um lhe envie as informações atuais de todas as sessões HTTP
7.5 Configuração de clusters para Tolerância à Falhas

O arquivo de configuração padrão server.xml do Tomcat traz comendado o elemento que cuida do
multicast IP entre os nós de um mesmo cluster
Além disso, deve ser configurado uma válvula () que faz o envio das modificações sobre as sessões
para os demais membros do cluster
Configuração de Multicast no Linux
Para que o cluster funcione, a rede local tem que estar permitindo tráfego em multicast
Garanta que seus switches não estão bloqueando este tráfego
O sistema operacional deve saber para onde enviar pacotes destinados a um dado endereço de
multicast, o que é feito como parte das configurações de roteamento está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 127.0.0.1

Edite o server.xml do no0 e acrescente, dentro do elemento
<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" />


Cuidado para não colocar quebras de linha dentro dos valores dos atributos!
81

<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"/>



<Valve className="org.apache.catalina.
cluster.tcp.ReplicationValve"
filter=".*\.gif;.*\.js;.*\.jpg;.*\.png;
.*\.htm;.*\.html;.*\.css;.*\.txt;.*\.swf"/>
</Cluster>
Se você perdeu o modelo, porque o Admin remove todos os comentários do server.xml, recupere
o modelo original do arquivo ZIP de instalação do Tomcat
É muita coisa para digitar na mão, e a maioria nunca é alterada pelo administrador

Edite o server.xml do segundo Tomcat (no1) e crie o elemento exatamente como no primeiro Tomcat
(no0), exceto:
<Receiver className="org.apache.catalina.
cluster.tcp.ReplicationListener"
tcpListenAddress="127.0.0.1"
tcpThreadCount="6" />
Note que cada nó do cluster abre uma porta TCP adicional (respectivamente 4100 e 4101)
Reinicie os dois servidores Tomcat

Acesse o exemplo 5.1 passando pelo Apache (http://127.0.0.1/exemplo5.1)
Ele deve se comportar exatamente como no cluster de distribuiçã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
82

Observe que a página foi gerada pelo no1, entretanto o identificador da sessão é do no2
Note que a contagem não se perdeu, indicando que o estado da sessão HTTP foi preservado
Figura 7.1:

A página de status do mod jk deve indicar que o nó falhou:
Figura 7.2:

Reinicie o primeiro servidor Tomcat (no0)
Após alguns segundos, o navegador que estava sendo atendido por ele voltará
A página de status do mod jk não irá indicar o nó do cluster novamente ativo até que alguma
requisição tenha sido entregue com sucesso a ele
Lembre-se de que leva algum tempo até a sua presença ser notada pelos outros nós do cluster, e
até que ele tenha recebido as informações das sessões em andamento
7.14 Se Algo Deu Errado...

Verifique com o comando route se existe uma rota para a rede 224.0.0.0/3 (classe D, IP multicast)
Verifique nos logs dos dois Tomcat e do Apache por mensagens de erro, como sintaxe inválida
nos arquivos de configuração
Verifique se as portas quatro TCP utilizadas por cada nó estão livres
Páre todos os servidores, remova a pasta work dos dois Tomcats, e reinicie todos os servidores
83
7.15 Seja Paciente! 1/2

A simulação de um cluster em um mesmo computador às vezes pode parecer errática
O tempo de troca de contexto de um Tomcat para o outro, especialmente em computadores com
pouca RAM e vários outros processos ativos, pode ser longo o suficiente para o balanceador ou um
dos nós acreditar que o outro nó esteja fora do ar
E o tempo de recuperação depois de uma possı́vel falha é de pelo menos um minuto
Na dúvida, veja a página de status do mod jk
7.16 Seja Paciente! 2/2

Se acontecer dos dois navegadores serem atendidos pelo mesmo servidor, porém ambos os nós estão
no ar e configurados corretamente
(mas o balanceador acredita que não)
Feche o navegador que está no servidor “errado” (para perder o cookie de sessão HTTP)
Aguarde alguns segundos e tente novamente
Ou então reinicie todos os servidores, removendo a pasta work do Tomcat
Conexões que migraram para fora de um nó falho não voltam automaticamente quando este nó
retorna ao cluster
7.17 Erros de Aplicação a Evitar

O suporte a clustering web do JavaEE é transparente, desde que o programador não cometa alguns
erros básicos:
Todos os objetos armazenados na sessão HTTP devem se serializáveis
Uma requisição HTTP deve corresponder a uma única transação no banco de dados
Uma transação no banco de dados deve ocorrer dentro de uma única transação HTTP
Nã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
7.18 Otimizações do Tomcat

O cluster web JavaEE seria transparente para aplicações escritas de forma correta
Entretanto, esta “transparência” seria cara em termos de rede, pois obriga os nós do cluster a
replicar o estado de sessões HTTP ao fim de cada requisição
Por isso o Tomcat implementa, em sua configuração padrão, um cluster “não-transparente”
Esta configuração espera que a aplicação atualize explicitamente todos os atributos da sessão
HTTP que forem atualizados
7.19 Clusters x Aplicações Administrativas

O Manager e o Admin não tem conhecimento do cluster, portanto eles tem que ser ativados e
acessados de forma independente em cada nó
Por isso nossa simulação não eliminou o conector HTTP
84
7.20 Cluster Farming

Até agora as aplicações foram instaladas manualmente em cada nó do cluster
Embora útil para nossa simulação, pois permite ter aplicações ligeiramente diferentes e saber
assim exatamente que nó atendeu a que requisição, é trabalhoso para ambiente de produção
Por isso o Tomcat fornece suporte a farming, que consiste em instalar (deploy) automaticamente
aplicações em todos os nós do cluster
7.21 Restrições do Farming no Tomcat

Apenas um nó pode estar configurado para instalar aplicações nos demais nós em um dado momento
A aplicação será instalada apenas nos nós ativos; se um nó falho volta à ativa, novas aplicações
e atualizações terão que ser instaladas manualmente, antes de reativar o nó
É obrigatório o uso de pacotes WAR compactados / fechados
Como Funciona
O pacote WAR da aplicação é copiado para um diretório especial, separado do webapps
O FarmWarDeployer monitora este diretório, e quando um pacote é adicionado ou removido, ele
é copiado ou removido do webapps, fazendo assim o deploy ou undeploy local
O pacote é enviado para os outros nós ativos do cluster, que repetem o processo de copiar para
o webapps local
A remoção de pacotes gera notificações para que os demais nós ativos façam o undeploy

Acrescente o FarmWarDeployer dentro do element do no0
<Cluster>
...
<Deployer className="org.apache.catalina.cluster.
deploy.FarmWarDeployer"
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.ClusterSessionListener"/>
...
</Cluster>

Não esqueça de ajustar os caminhos absolutos (/home/fernando) ao seu próprio diretó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 desejado
Somente um nó pode ter o watchEnabled com o valor true
O no1 recebe as mesmas alterações, com os caminhos devidamente ajustados, exceto pelo wat-
chEnabled com o valor false
85

O instrutor fornecerá o arquivo exemplo6.1.zip que contém uma pequena variaçã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 aplicação
(o FarmDeployer não afeta as configurações do Apache)
JkMount /exemplo6.1 cluster

JkMount /exemplo6.1/* cluster

Termine ambos os nós, limpe suas pastas work e reinicie ambos
Reinicie também o Apache
Verifique que ambos os nós individuais estão funcionando pelo acesso aos respectivos Manager, e
que o cluster também está 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

Acesse o Manager em cada nó, e confirme que a nova aplicaçã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 nó, comprovando que o FarmWarDeployer fez a cópia
do no0 para o no1
http://127.0.0.1:8080/exemplo6.1
http://127.0.0.1:8180/exemplo6.1
7.27 Tunning e Monitoração de Performance

Parâmetros de memória da JVM
Uso de threads pelo Tomcat e conectores
Dimensionamento dos pools de conexões ao banco de dados
Tunning do cluster
7.28 Introdução ao JMX

Gerenciamento do Tomcat via JMX
Uso de Memória pelo Tomcat
A JVM não aloca memória livre do sistema operacional
Em vez disso, no inı́cio da JVM é estabelecido um limite máximo para o heap, onde são armaze-
nadas instâncias de classes Java
86
Dependendo da quantidade de usuários, aplicações, páginas e informações na sessão HTTP pode

ser necessário aumentar o tamanho do heap
A página de status do servidor (no Manager) informa a memória em uso e a máxima no heap
Consultando o Uso de Memória com o Manager
A indicação de memória livre (Free memory) é em relação ao efetivamente alocado para o heap
(Total memory), e não em relação ao máximo possı́vel (Max memory)
Figura 7.3:
7.29 Parâmetros de memória da JVM 1/2

O comando java -X exibe as várias opções para tunning de memória e coleta de lixo da JVM
As opções mais usadas são:
-Xms<size>
Tamanho inicial do heap
-Xmx<size>
Tamanho máximo do heap
-Xss<size>
Tamanho da pilha ()
7.30 Parâmetros de memória da JVM 2/2

O máximo padrão do heap é de 64Mb
Parece pouco, mas lembre que é apenas o heap, outras partes da JVM ocupam centenas de Mb
mas estas partes não crescem com a carga da aplicação, ao contrário do heap
O comando abaixo exibe a memória total (vsz) e em uso na RAM (rss) para os processos da JVM
que rodam uma JVM
$ ps axo pid,vsz,rss,cmd | grep java
Para estabeler o máximo em 256Mb, use
$ java -Xmx256M
87
7.31 Modificando o Script de Startup

Embora seja possı́vel modificar os scripts de inı́cio do Tomcat para inserir opções da JVM, é mais
limpo usar a variável de ambiente JAVA OPTS
Então, para iniciar o Tomcat com o heap aumentado:
$ JAVA_OPTS=-Xmx256M ./startup.sh
Confira pela página de status do Manager, o aumento do máximo para o heap

Outra opção é inserir, no inı́cio do startup.sh
export JAVA_OPTS=-Xmx256M
7.32 Uso de Threads pelo Tomcat

Os conectores do Tomcat usam um pool de threads para atender a requisições
O pool permite eficiência no uso de processador e memória, além de melhorar o tempo de resposta
Como o tempo de processador é muito inferior ao tempo de disco, rede e dos humanos, ter um
thread por conexão (ou por usuário / sessão HTTP) seria um desperdı́cio de recursos
A página de status do Manager també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: máximo (Max), reserva (spare), total (current)
e ocupados (busy)
Também fornece uma lista do que estão fazendo os threads ocupados
Figura 7.4:
7.33 Conector x Front-end

Caso sua configuração use um servidor de front-end seus parâ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 ma folga para eventuais “desbalanceamentos”
Ex: três Tomcats, um Apache. Um único Tomcat falho, e 10 usuários para cada Tomcat:
MaxServers=3*10, MaxProcessors=2.2*10
MaxServers=30, MaxProcessors=22
88
7.34 Dimensionamento dos pools de conexões

O dimensionamento dos pools de conexões a bancos de dados
(DataSources) é um pouco mais complicado porque:
O Manager não exibe informações sobre o status atual dos pools
Conexõ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 máximo) vistos para threads
Estatı́sticas de uso podem ser obtidas via JMX
7.35 O Que São DataSource Leaks

Um dos problemas mais sérios de aplicações são os “vazamentos” (leaks) de conexões ao banco de
dados
Isto acontece por erro de programação, onde conexões são abertas (retiradas do pool) mas nunca
fechadas (devolvidas ao pool)
Então, após algum tempo não haverão mais conexões disponı́veis para uso por novas requisições
Detectando DataSource Leaks
Dentro de um elemento que configura um DataSource, podem ser definidos os atributos:
removeAbandoned="true"
Instrui o Tomcat a forçar a liberação de conexões que parecam ter sido “abandonadas” (portanto,
“vazadas”)
removeAbandonedTimeout="300"
Após quanto tempo sem uso uma conexão é considerada “abandonada”
logAbandoned="true"
Registra no log do Tomcat as conexões que foram considerada abandonadas
7.36 Tunning do cluster 1/3

Os recursos de clustering to Tomcat fornecem uma série de parâmetros que podem ser ajustados
Por exemplo, a válvula de replicação pode ignorar requisições por arquivos estáticos
Mas a configuração padrão não inclui arquivos Flash (*.swf)
<Valve className="org.apache.catalina.cluster.tcp.
ReplicationValve"
filter=".*\.gif;.*\.js;.*\.jpg;.*\.png;.*\.htm;
.*\.html;.*\.css;.*\.txt;.*\.swf"/>
89

Com uma grande quantidade de usuários simultânetos, pode ser necessário aumentar a quantidade
de threads que recebem informações dos demais nós, especialmente se o cluster envolver mais de dois
nós
<Receiver className="org.apache.catalina.cluster.
tcp.ReplicationListener"
tcpListenAddress="auto"
tcpThreadCount="8"/>

Por padrão, o envio de modificações nas sessões de um nó é assı́ncrono, o que gera um pequeno risco
de perda das últimas modificações das sessões em caso de pane
Mudar para envio sı́ncrono evita este risco às custas de maior consumo de processador, memória
e rede
<Sender className="org.apache.catalina.cluster.
tcp.ReplicationTransmitter"
replicationMode="synchronous"
ackTimeout="15000"/>
7.39 Introdução ao JMX

Especificação da plataforma Java que permite a qualquer aplicação fornecer “objetos gerenciados”,
os MBeans
Define também uma forma de se localizar e obter informações de MBeans, ou até de executar
ações sobre eles
É obrigatório em versões mais novas do JavaEE, que também define conjuntos de MBeans padrão
para os servidores de aplicações
O mercado oferece vários consoles para gerenciamento e monitoração JMX, similar aos consoles
SNMP
Monitoraçã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 o processo da JVM que roda o Tomcat e conecte a este processo
usando o jconsole do JavaSE
$ ps ax | grep java
22587 pts/5 Rl :03/usr/java/jdk1.5.0/bin/java ...
$ jconsole 22587
90
Sumário do JMX Console
Figura 7.5:
Memória via JMX
Figura 7.6:
Threads via JMX
Figura 7.7:
Observe que o Tomcat nomeia claramente os threads dos conectores, que são as responsáveis por
atender requisições
DataSources via JMX
91
Figura 7.8:
Todos os componentes do Tomcat são expostos como MBeans, então é possı́vel localizar o Data-
Source dentro do contexto e verificar a quantidade de conexões ativas (em uso)
Monitoração Remota via JMX
Forneç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
(Não há quebra de linha antes do “authenticate”)

Execute o jconsole indicando a porta TCP
$ jconsole 127.0.0.1:5000
Também é o final do “Treinamento de Servidores de Aplicações JavaEE usando Tomcat”!
7.40 REFERÊNCIAS 1/4

Site Oficial do Tomcat
http://tomcat.apache.org
Especificação JavaEE 1.4
http://jcp.org/en/jsr/detail?id=151
Especificação de Servlets 2.4
Especificação de Páginas JSP 2.0
Especificação JMX - Java Management Extensions 2.0

Java Secure Sockets Extensions
http://java.sun.com/products/jsse/
Java Criptography Extensions
http://java.sun.com/products/jce/
92
Protocolo HTTP
http://www.ietf.org/rfc/rfc2068.txt
Autenticação HTTP
Certificados Digitais na Internet

Jakarta Commons DBCP, implementação do pool de conexões do Tomcat
http://jakarta.apache.org/commons/dbcp
Commons Logging, utilizado pelo Tomcat para geraração de logs
http://jakarta.apache.org/commons/logging
Log4J, recomendado em lugar da Logging API do JavaSE
http://logging.apache.org/log4j

HSQLDB, utilizado nos exemplos que envolvem bancos de dados
http://jakarta.apache.org/commons/dbcp
Sobre o agente JMX incluso no JavaSE 5.0
http://java.sun.com/j2se/1.5.0/docs/guide/management/agent.html
Sobre o console JMX incluso no JavaSE 5.0
http://java.sun.com/j2se/1.5.0/docs/guide/management/jconsole.html
93
Referências Bibliográficas
94

Tomcat

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Tomcat

Enviado por

Direitos autorais:

Formatos disponíveis

Servidores de Aplicação JavaEE

usando Tomcat - 428

2.26 Usando o Admin 2/2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.46 Configuração do contexto via META-INF/context.xml . . . . . . . . . . . . . . . . . 35

4.42 Vinculação do Realm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.32 Segurança declarativa e encriptação . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

6.27 Integração x segurança e logging 2/2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

7.23 Exercı́cio 2/5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

Este curso visa capacitar profisssionais para a administração e gerenciamento de servidores de

1.1 Quem deve fazer?

• Programadores e analistas de sistemas responsáveis pelo desenvolvimento de aplicações Web

• Administradores de rede e desenvolvedores interessados em obter conhecimentos sobre como

• Conhecimentos básicos de Linguagem de programação Java

• Desejáveis, embora não indispensáveis:

• Compilação de programas na linha de comando utilizando o JDK;

• Acesso a bancos de dados utilizando JDBC;

• Construção de servles e páginas JSP.

• Conhecimentos básicos de HTML e HTTP (navegadores e servidores Web);

• Conhecimentos básicos de TCP/IP.

1.3 Agenda 1/2

– Aplicações de administração do Tomcat

– Deployment de aplicações Web JavaEE

– Instalação de bibliotecas e APIs de terceiros

– Configurações de segurança (parte 2)

– Integração com Apache Httpd

– Configurações de clustering (parte 2)

1.4 Antes do Tomcat

1.5 Verificando o Ambiente

Verifique se o compilador Java também está disponı́vel na linha de comando:

(observe que o resultado deve ser um ponto)

1.6 Programa Java Mı́nimo

Para compilar, gerando o arquivo Oi.class

• Aplicações de administração do Tomcat

2.1 Conceitos do JavaEE

• Containers Web, EJB e de Aplicação

• Servlets, JSP, JSTL e JSF

• Frameworks Struts, Hibernate e outros

• O formato WAR e deployment descriptors

2.2 JavaSE x JavaEE

Java EE ou JEE – Java Enterprise Edition(antigo J2EE):

• Tecnologias e APIs da plataforma Java para computação baseada em servidor

• São previstos servidores especializados para aplicações Java EE

2.3 Aplicações JavaEE

2.4 Containers JavaEE

• Container EJB: hospeda componentes / objetos distribuı́dos construı́dos segundo o padrão

• Container de aplicação: hospeda aplicações cliente stand-alone, fornecendo o ambiente ne-

2.5 Aplicação Java EE x JVM x Container

2.6 Servlets, JSP, JSTL e JSF

• JSTL é um conjunto padrão de tags customizados para uso em páginas JSP

• JSF é um framework que fornece um modelo de componentes e de eventos dentro de Servlets

2.7 Outras APIs Java EE

• JNDI permite acesso a serviços de diretório e objetos compartilhados entre aplicações e os

• JDBC para acesso a bancos de dados relacionais

• JavaMail para acesso a servidores de e-mail Internet

• JMS para acesso a filas de mensagens

• JMX para gerenciamento local ou remoto

• JAXP para processamento de documentos XML

2.8 Frameworks Struts, Hibernate e outros

• Struts permite a construção de aplicações segundo o modelo MVC (Model-View-Controller)

• Hibernate permite o uso de um banco relacional de forma orientada a objetos

• Spring e WebWorks são outros frameworks populares para o JavaEE

2.9 O formato WAR e deployment descriptors

2.10 Sobre o Tomcat