InvokerServlet no Tomcat 6

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:

3 Replies to “InvokerServlet no Tomcat 6”

  1. 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?

  2. @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.

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *