tomcat_arqs.zip (ZIP)Os arquivos de configuração e exemplos listados aqui estão também disponíveis para baixar (download), como um pacote compactado ZIP:
tomcat_arqs.zip (ZIP) JDK 6.0 Update 23. apache-tomcat-6.0.30.exe. tomcat_arqs.zip,
e descompacte em C:\tomcat_arqs.C:\Program Files\Apache Software Foundation\Tomcat 6.0\conf\Catalina\localhost.O Tomcat é um servidor de aplicações Java para web. É software livre e de código aberto, surgido dentro do conceituado projeto Apache Jakarta e que teve apoio e endosso oficial da Sun Microsystems como Implementação de Referência (RI) para as tecnologias Java Servlet e JavaServer Pages (JSP). Atualmente, o Tomcat tem seu próprio projeto de desenvolvimento independente, dentro da Apache Software Foundation. O Tomcat é robusto e eficiente o suficiente para ser utilizado mesmo em um ambiente de produção.
Nota: A partir do Java EE 5.0, com as versões de especificações Servlet 2.5 e JSP 2.1, a implementação de referência (RI) destas tecnologias passou a ser o servidor de aplicações Java EE completo (Web e EJB) GlassFish Application Server & Java EE SDKs, baseado no projeto de software livre GlassFish.
Tecnicamente, o Tomcat é um Conteiner Web, parte da plataforma corporativa Java Enterprise Edition (Java EE, anteriormente denominada J2EE) que abrange as tecnologias Servlet e JSP, incluindo tecnologias de apoio relacionadas como Realms e segurança, JNDI Resources e JDBC DataSources. O Tomcat tem a capacidade de atuar também como servidor web/HTTP autônomo, ou pode funcionar integrado a um servidor web dedicado, como Apache httpd ou Microsoft IIS, ou ainda como parte integrante de um servidor de aplicações mais amplo, como JBoss AS, provendo os recursos de Java Servlet e JSP.
O Tomcat porém não implementa um conteiner EJB. Para aplicações Java Enterprise Edition (Java EE) que utilizam Enterprise JavaBeans (EJB), você deve procurar um servidor de aplicações Java EE completo, como JBoss AS (software livre) - JBoss Enterprise Application Platform, GlassFish (software livre) - Sun GlassFish Community, Apache Geronimo (software livre), IBM WebSphere (comercial), Oracle Fusion Middleware - [ex BEA] WebLogic (comercial), ou o Java EE SDK que inclui GlassFish [ex Sun Java System Application Server Platform Edition] (gratuito), entre outros.
Este é um tutorial de instalação e configuração básica do Tomcat. Ele foi escrito e testado com base em instalações do Tomcat 4.1, 5.0, 5.5 e 6.0 em Windows, Unix e Linux. As configurações aqui propostas são para criar um ambiente de desenvolvimento bem simples e independente de qualquer ambiente integrado de desenvolvimento (IDE), suficiente para um primeiro contato com o Tomcat e as tecnologias Java para web. O tutorial, porém, não cobre o aprendizado da linguagem Java ou das tecnologias Servlet e JSP em si, nem tampouco o desenvolvimento de aplicações para web. Para mais informações sobre esses tópicos, veja as seções 15 e 16 ao final deste tutorial.
O Tomcat é inteiramente escrito em Java e, portanto, necessita de uma Java Virtual Machine (JVM) — Máquina Virtual Java — para ser executado. Assim, é necessário ter a plataforma Java Padrão, Java Platform Standard Edition (Java SE), previamente instalada.
Na Tecnologia Java, existem duas distribuições do Java SE:
Para seu ambiente de desenvolvimento Java com Tomcat, onde você deve criar aplicações Java em geral, utilize o JDK completo.
A versão mais atual da plataforma Java SE é a 6, lançada em dezembro de 2006. As duas versões anteriores, Java SE 5 (desde setembro 2004) e J2SE 1.4.2 (desde junho 2003), ainda são consideradas ativas. Já o J2SE 1.3.1 encerrou seu ciclo de vida e não deve ser usado para nenhum propósito.
O Tomcat 6.0 requer Java SE 5.0 ou superior. O Tomcat 5.5 suporta também J2SE 1.4.x, mas é necessário instalar um pacote adicional de compatibilidade.
Se você está iniciando um novo ambiente de desenvolvimento, a princípio o mais adequado é utilizar a versão mais recente, JDK 6, que inclui todas as melhorias e facilidades atuais para a tecnologia Java padrão. O Java SE 6 é plenamente compatível com as versões anteriores, com raras exceções. Havendo impossibilidade de usar o Java SE 6, o Java SE 5 também funciona muito bem com Tomcat.
Considere optar por versão anterior de JDK somente se o Java SE mais recente ainda não está disponível para o seu sistema operacional, ou se há alguma restrição de suporte, compatibilidade com aplicações pré-existentes ou outro impedimento crítico.
A plataforma Java SE (JRE e JDK) é disponibilizada nativa para cada sistema operacional suportado pela tecnologia Java. Desde o Java SE 5.0, a Sun Microsystems provê JDK para os sistemas operacionais Windows, Linux e Solaris. A HP fornece JDK para seu HP-UX desde dezembro de 2004; a Apple disponibiliza o JDK 5.0 para seu Mac OS X desde abril de 2005, com suporte a 64-bits, e trouxe o Java SE 6 (1.6.0_05) no Mac OS X 10.5 Update 1 em maio de 2008.
Quando este tutorial foi editado, a atualização mais recente de Java SE SDK disponibilizada pela Sun Microsystems era JDK 6.0 Update 23, para Windows, Linux e Solaris.
Para obter o Java SE SDK (JDK) e informações sobre a instalação em seu sistema operacional, acesse os links correspondentes a seguir:
Mais detalhes sobre convenções de nome e versão do ambiente Java padrão podem ser encontrados em J2SE Code Names e Version 1.5.0 or 5.0.
Complementando a instalação do Java 2 SDK, defina a variável de ambiente
JAVA_HOME apontando para seu local de instalação.
Esta variável de ambiente padrão é usada pelo Tomcat e vários outros sistemas
baseados em Java, para determinar a JVM preferencial. Isto é muito importante se
houver mais de uma instalação de J2SE no computador, mas a variável JAVA_HOME
deve ser definida mesmo se houver apenas uma versão instalada.
JAVA_HOME,
ou edite se já existente, definindo como valor o caminho da pasta de
instalação, por exemplo C:\Arquivos de programas\Java\jdk1.6.0_13
(ver
imagem).autoexec.bat, para incluir a linha:set JAVA_HOME=C:\Arquivos de programas\Java\jdk1.6.0_13~/.profile) ou global
do sistema (/etc/profile), para incluir a linha:JAVA_HOME=/opt/javase; export JAVA_HOME/etc/environment:
JAVA_HOME=/opt/javasePara mais informações sobre variáveis de ambiente recomendadas, veja também a seção 13 deste tutorial.
O Tomcat tem evoluído paralelamente à evolução da Plataforma Java EE e suas especificações para web, especialmente Java Servlet e JavaServer Pages (JSP). O quadro a seguir relaciona as versões de Tomcat com as respectivas versões de tecnologias suportadas, bem como versão mínima de Java SE necessária para executar o Tomcat.
| Tomcat | Servlet | JSP | Java EE | Java SE mín. |
|---|---|---|---|---|
| 7.0 (beta) | 3.0 | 2.2 | Java EE 6.0 | JDK/JRE 6 (1.6) |
| 6.0 | 2.5 | 2.1 | Java EE 5.0 | JDK/JRE 5 (1.5) |
| 5.5 | 2.4 | 2.0 | J2EE 1.4 | JDK 1.4 [*] |
| 4.1 (archive) | 2.3 | 1.2 | J2EE 1.3 | JDK 1.3 |
| 3.3 (archive) | 2.2 | 1.1 | - | JDK 1.1 |
Se você está iniciando o aprendizado e desenvolvimento Java para web, é recomendado utilizar a versão mais atualizada Tomcat 6.0, que é compatível com as especificações e tecnologias mais recentes e é o foco principal de desenvolvimento do projeto Tomcat. A maior parte dos recursos atuais é compatível com versões anteriores. Para mais informações sobre as versões de Tomcat, veja Apache Tomcat Versions.
A versão antiga 5.5 do Tomcat ainda é bastante utilizada, pois a especificação J2SE 1.4 e suas tecnologias, bem como os produtos baseados nelas, estão maduros e bem difundidos no mercado. Já o Tomcat 4.1 está muito defasado e não é recomendado, sendo inclusive considerado produto arquivado (legado sem atualização) pela Fundação Apache.
Para obter o Tomcat e informações sobre instalação e documentação, acesse o site Apache Tomcat, na Apache Software Foundation:
Quando este tutorial foi editado, a versão estável mais recente era Tomcat 6.0.30 (APIs Servlet 2.5 e JSP 2.1, integrantes do Java EE 5.0). O download do instalador para Windows pode ser acessado no site primário em apache-tomcat-6.0.30.exe (instalador com serviço Windows). A página principal de download apresenta todas as alternativas de versões de Tomcat e repositórios de download (mirrors).
Importante - Tomcat Windows: No passo "Java Virtual Machine path selection" do instalador do Tomcat, certifique-se de informar o caminho correto do JDK.
Na instalação Windows, a seleção de componentes personalizada (Custom) permite instalar e ativar o Tomcat como serviço no Windows NT/2000 ou superior, pelo item "Service". No Tomcat 5 em diante, o serviço é sempre instalado e o item "Service" apenas escolhe a sua ativação automática na inicialização do Windows.
O diretório principal (local de instalação) do Tomcat é
referenciado posteriormente neste tutorial como CATALINA_HOME.
Na documentação e scripts do Tomcat, esse diretório é também referenciado assim,
pois Catalina é o nome-código do projeto Tomcat e seu contêiner Servlet.
Siga o anexo correspondente à versão desejada, para um passo-a-passo do processo de instalação e configuração inicial do Tomcat:
Você pode executar o Tomcat instalando como serviço (Windows NT/2000 ou superior), com inicialização automática ou manual; ou executá-lo como processo isolado (qualquer sistema operacional), por um atalho no menu Iniciar do Windows ou por script shell (.bat/.sh). Veja a seguir a seção correspondente à forma de inicialização desejada.
Em sistemas Windows Vista ou superior, deve ser necessário executar o Tomcat Monitor como Administrador, caso contrário o sistema não permitirá à aplicação acessar o serviço do Tomcat.
Através da opção "Configure" do Tomcat Monitor, ou do ícone "Configure Tomcat" no menu iniciar, você acessa a caixa de Propriedades do Tomcat, onde pode configurar opções úteis como a gravação de log do servidor (aba Logging) e o runtime/JRE e Máquina Virtual Java a utilizar (aba Java), entre outros (ver imagem).
net start "Apache Tomcat"net stop "Apache Tomcat" net start "Apache Tomcat 4.1"net stop "Apache Tomcat 4.1" Para mais informações sobre como gerenciar e executar o Tomcat como serviço
do Windows, o uso dos programas tomcat6w.exe (Procrun Service
Manager) e tomcat6.exe (Service Runner) e seus respectivos
parâmetros de linha de comando, veja a página
Apache Tomcat 6.0 - Windows service HOW-TO.
setenv.bat ou
[Unix] setenv.sh dentro de CATALINA_HOME/bin,
com estas configurações (veja seção 13 deste tutorial);cd %CATALINA_HOME%\bincd $CATALINA_HOME/binstartup.bat ou catalina startstartup.sh ou catalina.sh startshutdown.bat ou catalina stopshutdown.sh ou catalina.sh stopObservações importantes para a plataforma Windows:
Para testar se o Tomcat está rodando ok após iniciado, abra o browser e vá para o endereço:
http://localhost:8080/
Na home-page padrão do Tomcat, o link "Tomcat Documentation" dá acesso a toda a documentação necessária, instalada localmente, inclusive a API Servlet/JSP da Sun, inclusa com o Tomcat.
O Tomcat inclui um contexto chamado Tomcat Manager, que provê uma interface
web amigável para gerenciar as aplicações (contextos) — listar, parar,
iniciar, recarregar, instalar (deploy), remover (undeploy) — e ver
informações e estado do servidor e de suas conexões/threads. O instalador
Windows solicita o login de usuário (padrão é admin) e a senha
para acesso a este recurso.
Para acessar o Tomcat Manager, siga o link respectivo no quadro "Administration" da home-page padrão do servidor, ou acesse diretamente o endereço http://localhost:8080/manager/html.
Se você ainda não entende bem a estrutura e características da configuração de um servidor de aplicação web Java como o Tomcat, não altere nada sem saber. Você pode contudo acessar a ferramenta de Gerenciamento (Tomcat Manager), fornecer o login e senha do usuário administrativo configurado na instalação e visualizar o Estado do Servidor, que apresenta uma série de informações técnicas sobre o funcionamento do servidor Tomcat.
Para executar seus servlets e JSPs, você precisa colocá-los dentro de um contexto de aplicação web (ServletContext). Cada contexto é uma unidade de aplicação web Java (servlet/JSP) que possui suas próprias configurações.
Para organizar o desenvolvimento, é interessante criar um contexto
novo e ativar sua opção reloadable (recarga
automática das classes modificadas). Para isso, faça o seguinte:
Crie um diretório que será a sua estrutura de desenvolvimento web Java. Uma organização simples sugerida é a seguinte:
dev/
src/ (os fontes .java ficam aqui, organizados em pacotes/diretórios)web/ (arquivos do módulo web)
WEB-INF/ (diretório obrigatório)
classes/ (os .class gerados devem ser direcionados para cá)lib/ (pacotes jar de bibliotecas utilizadas devem ficar aqui)web.xml (arquivo XML de configuração do contexto)index.jsp (home-page do módulo Java web),
ou um index.htmlSupondo que seu diretório "dev" seja em C:\dir\dev\ (Windows),
assim, o módulo web ficaria em C:\dir\dev\web.
A tarefa aqui consiste em criar no Tomcat um novo contexto de aplicação web,
para seu ambiente de desenvolvimento. Existem basicamente três meios de se
criar um contexto no Tomcat, cuja configuração corresponde a um código XML com
um elemento Context:
Context diretamente no arquivo
conf/server.xml, dentro de um elemento Host.
Este meio, frequentemente usado até o Tomcat 4, não é mais recomendado
desde o Tomcat 5, em prol do Deployment Automático. A criação de um
contexto pelo arquivo server.xml tem várias desvantagens:
não é dinâmica pois atualizações neste arquivo só podem ser re-lidas
reiniciando o Tomcat, cria o risco de invalidar toda a configuração do
servidor se for cometido um erro na sintaxe de uma tag de contexto, e
mistura configurações de servidor com configurações de contexto.Existem ainda outras formas de criação e configuração automática de um
contexto de aplicação web, como o uso de um pacote Web Application Archive (WAR)
e o arquivo META-INF/context.xml dentro do WAR. Para mais
informações, veja a documentação
Tomcat Web Application Deployment (Deployer HOW-TO)
e
Context Container na Referência de Configuração do Servidor Tomcat.
CATALINA_HOME/conf/Catalina/localhost/dev.xmlCatalina é o mecanismo e localhost
(máquina local) é o hostname padrão.CATALINA_HOME/webapps/dev.xmlwebapps é o diretório base de aplicações definido
no atributo appBase do Host.Crie o arquivo dev.xml na localização
já descrita, com o conteúdo do quadro a seguir.
O conteúdo é a definição do Context, precedida pela tag de
identificação de arquivo XML:
<?xml version="1.0" encoding="iso-8859-1"?> <Context path="/dev" docBase="C:/dir/dev/web" reloadable="true" privileged="true" crossContext="true"> </Context>Os seguintes atributos foram utilizados para o ambiente de desenvolvimento:
dev/web/
na estrutura de diretórios descrita no tópico anterior deste tutorial.
/WEB-INF/classes/ e
/WEB-INF/lib/, e automaticamente recarregue o contexto se uma
mudança for detectada. Muito útil em desenvolvimento, para testar imediatamente
classes e bibliotecas modificadas/recompiladas ou novas, mas não deve ser
ativado em ambiente de produção, pois consome significativo overhead.web.xml deste contexto
utilize o InvokerServlet do Tomcat.
ServletContext.getContext()
retorne um request dispatcher para outras aplicações web existentes neste
host virtual. Não deve ser usado se há restrições de segurança entre os
ambientes de cada aplicação web rodando neste host.Nota:
No Tomcat 4.1, era possível configurar no Context um elemento
aninhado Logger para opções de log do contexto. No Tomcat 5.5 em
diante, o tratamento de logging foi totalmente reestruturado.
Uma consequência importante é que o elemento Logger deixou de
existir. Para detalhes sobre configurar e utilizar logs em sua
aplicação, veja a seção 12 - Logs deste tutorial.
Crédito: Agradeço ao Samuel Valerio, de Natal, RN, por me
alertar sobre essa mudança.
Atenção: Para ter a aplicação
Administration no Tomcat 5.5, baixe e instale o pacote
adicional apache-tomcat-5.5.*-admin.tar.gz.
admin) e senha do usuário
administrativo, conforme configurado durante a instalação.Context.O arquivo WEB-INF/web.xml é o descritor do contexto de
aplicação web, segundo a especificação Java Servlet/J2EE. As informações nele
contidas são as configurações específicas da aplicação.
Nosso contexto de desenvolvimento terá apenas as seguintes configurações:
display-name, nome
para exibição no Gerenciador) e comentário de descrição (description)
do contexto, úteis para identificação e documentação;servlet associada à classe do invocador genérico
InvokerServlet do Tomcat, usada para executar os servlets que você
criar;
No Tomcat 6, InvokerServlet passou a ser servlet restrita.
Uma aplicação web que deseje usar a Invoker Servlet em seu contexto deve rodar
como privilegiada, com o atributo privileged="true" em Context,
conforme definimos anteriormente.
servlet-mapping) genérico associando o
padrão de endereço URI /servlet/* à definição do invoker criada,
indicando que qualquer nome dentro do caminho /servlet/ neste contexto deve ser
reconhecido como servlet e portanto repassado ao invoker do Tomcat para execução.
Este mapeamento genérico de servlet baseado no nome da classe
é muito útil no ambiente de desenvolvimento para testar rapidamente qualquer
servlet, mas é
considerado má prática por ser um risco de segurança,
clareza e organização. O ideal é mapear individualmente cada servlet utilizada
pela alicação no web.xml do contexto.
Crie o arquivo web.xml descritor para o novo contexto de aplicação web criado,
dentro do diretório dev/web/WEB-INF/. Um conteúdo mínimo para ele,
com as configurações apresentadas, é listado a seguir.
<?xml version="1.0" encoding="ISO-8859-1"?> <web-app xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" version="2.5"> <display-name>Desenvolvimento</display-name> <description> Descritor do contexto de desenvolvimento. </description> <servlet> <servlet-name>dev-invoker</servlet-name> <servlet-class> org.apache.catalina.servlets.InvokerServlet </servlet-class> <init-param> <param-name>debug</param-name> <param-value>0</param-value> </init-param> <load-on-startup>2</load-on-startup> </servlet> <servlet-mapping> <servlet-name>dev-invoker</servlet-name> <url-pattern>/servlet/*</url-pattern> </servlet-mapping> </web-app>
Como se pode observar no XML anterior, ele se refere ao descritor de
Aplicação Web da especificação Servlet 2.5 (integrante do Java EE 5). Para
utilizar apenas recursos de uma versão anterior de descritor de Aplicação Web,
substitua o cabeçalho do XML e a definição da tag raiz web-app
pelo da respectiva versão. Eis a alteração de cabeçalho para Servlet 2.4:
<?xml version="1.0" encoding="ISO-8859-1"?> <web-app xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd" version="2.4"> ... </web-app>
E a seguir o cabeçalho para a especificação Servlet 2.3. Note que a
estrutura do XML na versão 2.3 é definida por um DTD definido na tag DOCTYPE,
enquanto as versões mais recentes usam XML Schema (XSD), definido por atributos
de namespace na própria tag web-app.
<?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd"> <web-app> ... </web-app>
Para garantir a ativação do novo contexto criado, reinicie o Tomcat (stop/start).
Logo após a inicialização do Tomcat, o arquivo de log da saida padrão
do servidor Tomcat, criado em logs com o nome
stdout.log, deve iniciar com um conteúdo similar ao trecho
apresentado a seguir. Observe a mensagem (em destaque no quadro) que
indica que o contexto configurado pelo arquivo dev.xml foi
processado.
12/09/2004 12:09:00 org.apache.coyote.http11.Http11Protocol init
INFO: Initializing Coyote HTTP/1.1 on port 8080
12/09/2004 12:09:01 org.apache.catalina.startup.Catalina load
INFO: Initialization processed in 2234 ms
(...)
12/09/2004 12:09:06 org.apache.catalina.core.StandardHostDeployer install
INFO: Processing Context configuration file URL file:
.../Tomcat6.0/conf/Catalina/localhost/dev.xml
O Tomcat 5 em diante gera por padrão muito menos mensagens em log para os
contextos do que o Tomcat 4, de forma que a inicialização não gera nenhuma
mensagem no arquivo de log específico do contexto dev. Por isso,
não estranhe se você não encontrar inicialmente nenhum arquivo
localhost_dev_log.*.txt na pasta logs.
Logo após a inicialização do Tomcat, o arquivo de log geral do host
para o servidor Tomcat, que é criado em logs com nome
no formato localhost_log.2004-09-12.txt, onde
2004-09-12 corresponde ao ano, mês e dia atuais, deve iniciar
com um conteúdo similar ao trecho apresentado a seguir. Observe a
mensagem (em destaque no quadro) que indica que o contexto configurado
pelo arquivo dev.xml foi processado.
2004-... HostConfig[localhost]: Deploying configuration descriptor admin.xml 2004-... HostConfig[localhost]: Deploying configuration descriptor dev.xml 2004-... HostConfig[localhost]: Deploying configuration descriptor manager.xml 2004-... WebappLoader[/manager]: Deploying class repositories to work directory (...)
E o arquivo de log do novo contexto, que é criado com nome no formato
localhost_dev_log.*.txt, deve ter um conteúdo inicial
similar ao seguinte:
2004-... WebappLoader[/dev]: Deploying class repositories to work directory
.../Tomcat4.1/work/Standalone/localhost/dev
2004-... WebappLoader[/dev]: Deploy class files /WEB-INF/classes to /dir/dev/web/WEB-INF/classes
2004-... WebappLoader[/dev]: Reloading checks are enabled for this Context
2004-... StandardManager[/dev]: Seeding random number generator class java.security.SecureRandom
2004-... StandardManager[/dev]: Seeding of random number generator has been completed
2004-... StandardWrapper[/dev:default]: Loading container servlet default
2004-... StandardWrapper[/dev:invoker]: Loading container servlet invoker
2004-... StandardWrapper[/dev:dev-invoker]: Loading container servlet dev-invoker
Para testar o novo contexto, acesse o endereço:
http://localhost:8080/dev/
Se você criou um index.html no diretório de desenvolvimento
(dev/web/), você deve ver esta página.
Senão, verá apenas uma listagem do diretório gerada pelo Tomcat.
Se o Tomcat retornar a página de erro 404 - Não Encontrado, houve algum
problema de forma que o contexto não foi ativado. O problema mais comum é haver
algum erro de sintaxe no elemento Context no arquivo XML que define
o contexto. Verifique os logs do Tomcat, conforme a seção 12 adiante, à procura
de erros. Você pode também usar algum dos muitos
Validadores de XML
existentes como auxílo, como por exemplo o serviço on-line de
Validação de XML do STG,
que verifica um XML em arquivo, URI na web ou o texto copiado diretamente em um
formulário.
Para compilar servlets, você precisa essencialmente importar os pacotes
javax.servlet e javax.servlet.http. As bibliotecas com
estes pacotes também estão inclusas como JAR no Tomcat e devem ser
adicionadas ao CLASSPATH do compilador javac:
CATALINA_HOME/common/lib/servlet-api.jarCATALINA_HOME/common/lib/jsp-api.jarCATALINA_HOME/common/lib/servlet.jaronde CATALINA_HOME é o diretório principal de instalação do Tomcat.
Se você tem o J2EE SDK da Sun instalado, pode alternativamente usar o j2ee.jar incluso com ele, que contém todas as APIs do Java EE inclusive Servlet/JSP. Mas o mais simples é usar o(s) jar(s) do Tomcat. Isso garante total compatibilidade entre a versão das APIs Servlet/JSP usadas no desenvolvimento e no seu Tomcat.
Além disso, se o código Java de uma classe servlet sua importar
pacotes ou classes de uma biblioteca de terceiros (que não seja parte das
APIs J2SE e Servlet/JSP), o JAR com as classes compiladas desta biblioteca deve
estar no diretório WEB-INF\lib\ para que o Tomcat encontre.
O pacote ZIP com os arquivos deste tutorial (veja a Introdução) inclui o fonte de um servlet bem simples AloMundoServ.java, que pode ser usado como primeiro teste, similar a:
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
public class AloMundoServ extends HttpServlet
{
public void doGet(HttpServletRequest request, HttpServletResponse response)
throws IOException, ServletException
{
String alo = "Alô Mundo!";
PrintWriter out = response.getWriter();
out.println("<html>");
out.println("<body><h1>" + alo + "</h1></body>");
out.println("</html>");
} // doGet
} // class AloMundoServ
Se o arquivo estiver em dev/src/, você pode
abrir uma janela de comandos (prompt) neste local, certificar-se que o CLASSPATH
está devidamente configurado conforme a seção 9 deste tutorial,
e executar o compilador javac, direcionando o destino para
../web/WEB-INF/classes/:
javac -d ../../web/WEB-INF/classes AloMundoServ.java
Depois que um servlet for compilado e o .class resultante colocado em
dev/web/WEB-INF/classes/, com as configurações de
mapeamento servlet genérico que fizemos no contexto, você acessa
seu servlet com o URI /dev/servlet/NomeDaClasseServlet (sem o
.class). Para o exemplo compilado AloMundoServ.class,
acesse o servlet com o seguinte URL:
http://localhost:8080/dev/servlet/AloMundoServ
Podem ser criados, no web.xml, outros mapeamentos específicos
para uma ou mais servlets. Para isso, você deve conhecer a sintaxe dos
elementos <servlet> e <servlet-mapping>.
Os JSPs colocados em dev/web/ (exemplo: arquivo
alomundo.jsp) são acessados assim:
http://localhost:8080/dev/alomundo.jsp
Podem ser criados sub-diretórios dentro do diretório principal
do contexto, para organizar os arquivos JSP e arquivos estáticos
(HTML, imagens etc.). Estes sub-diretórios se refletirão diretamente
no URL (endereço) de uma página JSP neles contida.
Uma página JSP em dev/web/subdir/pagina.jsp neste contexto
terá URL http://localhost:8080/dev/subdir/pagina.jsp.
É recomendado não utilizar espaços nem caracteres acentuados
nos nomes de sub-diretório. Além disso, procure usar apenas
letras minúsculas, o que é o mais comum em endereços web.
No Tomcat 5 ou inferior, se a configuração não estiver apontando para a localização correta do JDK (Java SDK) mas sim para a do JRE (Java Runtime), a tentativa de exibição de um novo JSP pode resultar no seguinte erro:
HTTP Status 500 - Exception report exception org.apache.jasper.JasperException: Unable to compile class for JSP No Java compiler was found to compile the generated source for the JSP. This can usually be solved by copying manually $JAVA_HOME/lib/tools.jar from the JDK to the common/lib directory of the Tomcat server, followed by a Tomcat restart. If using an alternate Java compiler, please check its installation and access path.
O JRE não inclui as ferramentas de compilação Java,
necessárias para a compilação dinâmica de
páginas JSP novas ou modificadas. Daí o erro. Para solucionar,
re-configure ou re-instale o Tomcat informando o caminho correto do Java SDK (JDK),
ou então recorra à alternativa sugerida na mensagem de erro: copie
manualmente o arquivo lib/tools.jar do JDK para o diretório
common/lib do Tomcat e re-inicie o Tomcat (shutdown/start).
Para configurar a gravação de log (registro histórico) em sua aplicação, veja a página Logging in Tomcat 6.0 (ou 5.5) para detalhes.
As opções e preferências de geração de log das aplicações rodando no Tomcat devem ser configuradas diretamente no arquivo de configuração do mecanismo/framework de logging em uso:
TOMCAT_HOME/conf/logging.properties;TOMCAT_HOME/lib/log4j.properties.Em Windows, lembre-se que a opção Configure Tomcat (veja tópico 3.1) permite definir o nível padrão, localização e prefixo dos arquivos de log do Tomcat.
Para ver logs de acesso, erro e depuração, leia os txt's gerados em:
CATALINA_HOME\logs\
Quando existirem muitos arquivos de log no Tomcat de desenvolvimento e você quiser limpar o diretório para facilitar o rastreamento dos logs, pode:
CATALINA_HOME\logs\,
ou movê-los para uma área de backup.Inspecionar as mensagens de saída informativas e de erro do Tomcat é importante para depurar e fazer diagnóstico do servidor, como identificar problemas na inicialização do Tomcat, acompanhar o processamento dos arquivos de configuração (server.xml, web.xml) e da inicialização e finalização do Tomcat, bem como visualizar quaisquer exceções Java levantadas. Estes são os arquivos de log do servidor, que devem ser inspecionados:
stdout.log: arquivo que recebe toda a saída padrão de mensagens
informativas geradas na execução do Tomcat e seus contextos (exceto
quando o Tomcat é iniciado pelo prompt de comandos, quando as mensagens
aparecem diretamente no console. Inclui também as mensagens de saída que, até
o Tomcat 4.1 ficavam no arquivo separado localhost_log.stderr.log: analogamente ao stdout, o stderr recebe toda a
saída de erro gerada na execução do Tomcat.As saídas padrão (stdout) e de erro (stderr) podem ser exibidas de diversas formas, dependendo de como o Tomcat foi inicializado:
stdout.log e stderr.log respectivamente,
localizados em CATALINA_HOME\logs\.É útil deixar configuradas algumas variáveis de ambiente relacionadas a Java e ao Tomcat. A variável JAVA_HOME foi abordada no tópico 1.3 deste tutorial. As variáveis de ambiente relacionadas são:
bin das ferramentas
do Java SDK.Windows (Painel de Controle ou arquivo autoexec.bat), ou criar
um script setenv.bat:
set JAVA_HOME=C:\Arquivos de programas\Java\jdk1.6.0_13 set CATALINA_HOME=C:\Arquiv~1\Apache~1\Tomcat 6.0 set CLASSPATH=%CATALINA_HOME%\common\lib\servlet-api.jar;.;%CLASSPATH% set CLASSPATH=%CATALINA_HOME%\common\lib\jsp-api.jar;%CLASSPATH% set PATH=%JAVA_HOME%\bin;%PATH%
Se decidir usar o JRE ao invés do JDK, substitua o JAVA_HOME anterior:
set JAVA_HOME=C:\Arquivos de programas\Java\jre6
Unix/Linux (user/system profile), ou criar um script setenv.sh:
JAVA_HOME=/opt/javase
CATALINA_HOME=/opt/tomcat
CLASSPATH=$CATALINA_HOME/common/lib/servlet-api.jar:.:$CLASSPATH
CLASSPATH=$CATALINA_HOME/common/lib/jsp-api.jar:$CLASSPATH
PATH=$JAVA_HOME/bin:$PATH
# Sintaxe Bourne shell (sh), Korn shell (ksh), Bash e similares:
export JAVA_HOME CATALINA_HOME CLASSPATH PATH
Mais informações sobre variáveis de ambiente:
O Tomcat vem com material de referência completo, documentação e exemplos. Tudo pode ser acessado localmente on-line (Tomcat iniciado) a partir dos links na home-page padrão do Tomcat, em http://localhost:8080/. Este material também está disponível no site do Projeto Apache Tomcat.
CATALINA_HOME\webapps\docs\index.html
(Até o Tomcat 5.5, o caminho era tomcat-docs;
no Tomcat 6, foi simplificado apenas para docs.)
conf\server.xml:
config/Terminada a instalação do software, está aberta a sua temporada de desenvolvimento Java para web. A tecnologia e as informações envolvidas na programação são assuntos muito mais abrangentes e não estão no escopo deste tutorial. Para desenvolver em Java para web, você deve ter bons fundamentos dos seguintes tópicos essenciais:
Para fazer projetos bem estruturados, você também deve saber:
E para fazer aplicações completas, você deverá conhecer e utilizar:
Se você ainda não tem domínio dos tópicos essenciais, recomendo um bom curso (ou cursos), em sala de aula, e a leitura de bons livros. O mesmo vale para os tópicos mais avançados. Há ainda muitas referências disponíveis na web e uma boa quantidade de grupos de usuários e listas de discussão sobre Java, inclusive no Brasil.
Para produtividade, é importante também um bom ambiente integrado de desenvolvimento (IDE). As ferramentas mais usadas, ambas gratuitas e livres, são Eclipse e NetBeans. Há também os ótimos Oracle JDeveloper (gratuito), IntelliJ IDEA (comercial), JBuilder (comercial). Mas nenhuma ferramenta vai dispensar o conhecimento da arquitetura Java EE e das tecnologias envolvidas.
Por fim, existem tópicos avançados sobre Tomcat não abordados por este tutorial, como:
© 2003-2020, Márcio d'Ávila, mhavila.com.br, direitos reservados. O texto e código-fonte apresentados podem ser referenciados, distribuídos e utilizados, desde que expressamente citada esta fonte e o crédito do(s) autor(es). A informação aqui apresentada, apesar de todo o esforço para garantir sua precisão e correção, é oferecida "como está", sem quaisquer garantias explícitas ou implícitas decorrentes de sua utilização ou suas consequências diretas e indiretas.