Fiz uma importante atualização do meu artigo Tutorial Tomcat – Instalação e Configuração Básica, um dos mais longevos e populares do meu site, introduzindo o atributo de contexto privilegiado para que a InvokerServlet possa ser utilizada no Tomcat 6.
Desde a revisão 25, eu comecei a atualizar o texto para cobrir o Tomcat 6. Mas só agora, na revisão 35, pude testar todos os aspectos nessa versão do Tomcat.
Descobri então que uma nova característica de segurança introduzida no Tomcat 6 necessitou alterações importantes na configuração do contexto, relativas ao uso da InvokerServlet.
InvokerServlet
é uma servlet do Tomcat, definida no pacote org.apache.catalina.servlets
, que serve para mapear e invocar genericamente qualquer servlet com base no nome da respectiva classe.
Utilizando Invoker Servlet, um mapeamento genérico como /servlet/*
no web.xml permite que se possa executar através de um URL do tipo /servlet/NomeClasse
uma servlet implementada pela classe NomeClasse.class
.
Até o Tomcat 5.5, InvokerServlet podia ser declarada e mapeada no web.xml de qualquer aplicação web e era automaticamente localizada e ativada pelo classloader desta aplicação.
A partir do Tomcat 6, InvokerServlet passou a ser restrita ao classloader do Server (mecanismo do servidor Tomcat). Para carregar e utilizar esta servlet, um contexto de aplicação web deve ser definido como privilegiado, setando o atributo privileged="true"
no elemento Context que o define.
Se esta configuração não for feita no Tomcat 6, ocorre o seguinte erro durante a tentativa de executar o mapeamento de InvokerServlet definido no web.xml do contexto da aplicação web, visível nos arquivos de log do Tomcat (em CATALINA_HOME/logs
):
java.lang.SecurityException: Servlet of class org.apache.catalina.servlets.InvokerServlet is privileged and cannot be loaded by this web application
Cabe ressaltar que o mapeamento genérico de servlets baseado no nome da classe, como permite InvokerServlet, é considerado má prática. Em produção, o ideal é que se mapeie individualmente cada servlet utilizada em um contexto, no arquivo web.xml da aplicação web.
Contudo, o mapeamento genérico do InvokerServlet é um recurso muito útil em desenvolvimento para se testar rapidamente qualquer classe servlet implementada, sem a necessidade prévia de configurar um mapeamento específico para esta.
Na revisão 35, o texto todo do tutorial foi repassado durante sua validação completa para o Tomcat 6, o que acabou trazendo vários ajustes e melhorias no texto. Confira!
Para saber mais:
- Invoker Servlet – The Long and Sordid Tale of the Invoker Servlet (em inglês), em JavaRanch.
- The Context Container – Common Attributes (em inglês), ver atributo
privileged
, na documentação do Tomcat 6.0. - Apache Tomcat FAQ – Why is the invoker evil? (em inglês), em Tomcat Wiki.
- Apache Tomcat 6 Tutorial – Configuration Details – Enable the Invoker Servlet (em inglês), no tutorial Configuring and Using Tomcat 6 and Tomcat 7 – A Tutorial on Installing, Configuring, and Using Tomcat for Servlet and JSP Development, em CoreServlets.com.
- Tomcat Installation and Configuration on Windows – Setting up port and servlet invoker (em inglês), em EasyWay Server.
Muito bom o post, poderia me esclarecer uma dúvida referente a um projeto ?
Para que alterações feitas em classes JAVA sejam percebidas no site, é necessário que o TomCat seja reiniciado? Assim, é possível fazer este procedimento sem possuir a permissão de acesso devida ao servidor de produção?
@Rud:
Em ambiente de desenvolvimento, em geral ativamos o atributo reloadable=true (veja http://www.mhavila.com.br/topicos/java/tomcat.html#t05_02 no tutorial) que recarrega automaticamente o Tomcat quando uma classe ou bliblioteca Java é alterada.
Mas esse processo de monitorar e detectar continuamente alterações de classe é muito oneroso ao Tomcat, de forma que esse recurso normalmente NÃO é usado em ambiente de produção, pois pode causar séria perda de desempenho do servidor.
Assim, em produção, é necessário sim reiniciar o Tomcat para que as alterações em classes e bibliotecas sejam efetivadas. Normalmente agenda-se essa operação para a madrugada ou qualquer outra janela de utilização mínima do servidor web.
Já páginas dinâmicas construídas em JSP/JSF são, por construção/definição do próprio mecanismo dessa tecnologia, automaticamente recompiladas e recarregadas pelo servidor Java (Tomcat) quando a página é alterada.
Espero ter esclarecido tudo.