Tomcat is deprecated. Use Jetty instead.

É exatamente esse a impressão que eu tenho depois de migrar os nossos servidores para o Jetty. Depois de ver muita gente reclamando de OutOfMemory no Tomcat, inclusive aqui da empresa, resolvemos tentar o Jetty.

A tempo que escutava o pessoal da Caelum (e principalmente o Kung) falando bem do Jetty, mas só quando se começa a usar que se percebe as vantagens. Como temos várias aplicações rodando (diferente do GUJ, que era só o JForum, acredito), imaginei que a troca não seria tão smooth assim.

Claro que antes de sair trocando tudo, fizemos alguns testes pra ter certeza que tudo ia ocorrer bem. Por sinal, a troca foi bem tranquila do ponto de vista da aplicação, só tivemos que fazer alguns ajustes:

• o Jetty lança java.util.Collections$UnmodifiableMap ao tentar modificar diretamente o (Hash)Map devolvido com request.getParameterMap() ao invés de usar o método setAttribute() do request – coisa que o Tomcat deixa;
• Diferenças ao tentar recuperar um resource do sistema utilizando como pasta base “.”, ou usar “..” pra navegar na estrutura de pastas. Para resolver, basta usar como pasta base “/” (ex: “/com/foo/resources/xpto.xml”) e colocar dentro do WEB-INF/classes;
• E a última, mas simples de resolver, é que o Jetty deixa habilitado listagem de diretórios. Você pode alterar isso no etc/webdefault.xml, trocando o atributo dirAllowed para false;

Feitos esses ajustes, chegou a vez de configurar o Jetty para atender aos diferentes domínios. E é aqui que vi uma das grandes vantagens do Jetty. A parte de configuração dele fica muito organizada. Fizemos da seguinte forma:

• Para cada aplicação (pra cada .war na pasta /webapps do Jetty), criamos um arquivo de contexto no /contexts (não é necessário, mas como temos urls diferentes e contextos diferentes, tivemos que customizar – e acabamos ganhando um brinde que conto depois)
• Cada arquivo de context tem uma estrutura estupidamente simples:

  
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE Configure PUBLIC "-//Mort Bay Consulting//DTD Configure//EN" "http://jetty.mortbay.org/configure.dtd">
<Configure class="org.mortbay.jetty.webapp.WebAppContext">
  <Set name="contextPath">/</Set>
  <Set name="war"><SystemProperty name="jetty.home" default="."/>/webapps/demo_foo.war</Set>
  <Set name="defaultsDescriptor"><SystemProperty name="jetty.home" default="."/>/etc/webdefault.xml</Set>

  <Set name="virtualHosts">
    <Array type="String">
      <Item>demo.foo.com</Item>
    </Array>
  </Set>

</Configure>


Explicando por partes:

• WebAppContext é o tipo de contexto que você vai usar, estamos usando esse pois permite o hotdeploy
• contextPath serve para dizer (óbvio) o contexto que quer que a aplicação fique disponível. Aqui prefirimos colocar todas no contexto / e configurar diferentes Virtual Hosts pra cada aplicação.
• a propriedade war só diz qual .war (que pode ser um exploded war também) que vai ser deployado naquele contexto
• na seção que diz virtualHosts, você pode configurar todos os endereços que quer que sua aplicacão responda. Para ela aceitar mais de um endereço, basta ir adicionando Item’s com as outras URLs. Aproveitando, no Jetty 7 será possível usar wildcards!

Com isso feito, ficou muito fácil configurar o deploy automático de todas nossas aplicações, pois basta substituir o arquivo .war e dar um touch no arquivo de contexts que o Jetty faz reload do contexto (e esse é o brinde! )! Agora, com o Jetty combinado ao Hudson, com um clique podemos fazer deploy de qualquer uma das nossas aplicações em um ambiente específico ou mesmo em todos, automaticamente. Mas isso já é assunto para um outro post.

Links Relacionados

• Melhorando o GUJ: Jetty, NIO e load balancing
• Jetty Documentation

Popularity: 6% [?]