Tomcat

1. Qué es Tomcat y cómo encaja en Java/Jakarta EE

Tomcat es un contenedor de servlets: el “motor” que ejecuta aplicaciones web Java/Jakarta (Servlets, JSP, JSTL, WebSocket) y sirve contenidos dinámicos. A diferencia de un “servidor de aplicaciones” pesado, Tomcat apuesta por la ligereza: lo justo y necesario para apps web Java modernas.
En mi experiencia, Tomcat es más fácil de echar a andar que otras opciones: descargar, descomprimir, arrancar el script y en minutos tengo un .war desplegado. Esa curva de entrada baja lo convierte en el caballo de batalla de muchos equipos que quieren velocidad sin sacrificar estabilidad.

Dónde encaja

• Capa web de una arquitectura Java: front controller (Servlets), vistas (JSP/Thymeleaf), APIs REST (Servlet/filters), WebSockets.

• No reemplaza bases de datos, balanceadores ni colas; se integra con ellos.

• Con Jakarta EE: si vienes de javax.*, hoy todo apunta a jakarta.*. Tomcat va perfecto con stacks modernos de Jakarta Servlet.

2. Cuándo usar Tomcat (y cuándo no): criterios prácticos

Si tu app es Java/Jakarta EE web, Tomcat encaja de maravilla. Yo lo recomiendo solo si vas a usar aplicaciones en Java; si tu stack principal no es Java, no me complico: uso otra pieza más afín.
Sí úsalo cuando:

• Tu app es un WAR o un Spring MVC/REST en Java.

• Necesitas rendimiento estable con huella de memoria razonable.

• Valoras simplicidad operativa (logs claros, scripts estándar).
  Evítalo cuando:

• Buscas un servidor de aplicaciones completo (EJB, JMS, etc.) → mira WildFly/Payara.

• Tu app es Node, Python, PHP → despliega con servidores nativos del ecosistema.

• Necesitas serverless puro o funciones event-driven → ve por servicios administrados.

Señales de decisión

• ¿Tu equipo ya domina Java? Tomcat acelera.

• ¿Tienes microservicios con Spring Boot embebido? A veces no necesitas Tomcat externo; el JAR ejecutable con Tomcat embebido basta.

• ¿Tu seguridad exige políticas TLS finas y endurecimiento? Tomcat lo permite con configuración prolija.

3. Instalación rápida en Windows, Linux y Docker

La receta que me funciona:

Linux (Debian/Ubuntu)

Windows

• Instala Java 17+ (o la versión que requiera tu Tomcat).

• Descarga el zip binario, descomprime en C:\Tomcat.

• Arranca con bin\startup.bat (detén con bin\shutdown.bat).

• Asegura permisos mínimos para el usuario del servicio.

Docker

Dockerfile base minimalista:

Para proyectos, suelo preferir imágenes oficiales o las de distroless si busco superficie mínima.

4. Despliegue de tu app (WAR) en minutos

Aquí Tomcat brilla y, sinceramente, es donde digo que es muy fácil de usar.
Opciones típicas:

• Drop-in: copia tu miapp.war a webapps/ y reinicia. Tomcat lo desplegará como http://host:8080/miapp/.

• Contexto dedicado: crea conf/Catalina/localhost/miapp.xml para afinar rutas, recursos JNDI o datasources.

• Manager App: habilita el usuario en tomcat-users.xml y sube el WAR vía UI o curl.

Checklist rápido:

• Define context path claro (/ ó /miapp).

• Configura datasources en context.xml (evitas credenciales en el WAR).

• Revisa logs (logs/catalina.out, localhost.*.log) tras el primer arranque.

5. Configuración esencial: server.xml, context.xml y estructura de directorios

Conocer la “anatomía” te ahorra horas:

• conf/server.xml: conectores (<Connector port="8080" .../>), Executor de hilos, Host virtual, TLS.

• conf/context.xml (global) y META-INF/context.xml (por app): session manager, recursos JNDI, datasources.

• webapps/: tus aplicaciones (WAR o explodidas).

• logs/: catalina, localhost, access logs.

• bin/: scripts de arranque.
  En mi flujo, ajusto pocas cosas al principio: puerto, maxThreads, URIEncoding="UTF-8" y un AccessLogValve con formato JSON para enviar a observabilidad.

6. HTTPS sin dolor: certificados, SSLHostConfig y buenas prácticas

Activar HTTPS no debería ser drama:

1. Genera/instala el certificado (ACME/Let’s Encrypt, o tu PKI).

2. En server.xml, habilita un conector TLS:

Buenas prácticas:

• Prefiere TLS 1.2/1.3, deshabilita suites débiles.

• Usa PKCS#12; gestiona secretos fuera del repo.

• Redirecciona HTTP→HTTPS con un RemoteIpValve si hay proxy inverso delante.

7. Rendimiento y estabilidad: memoria, threads, HTTP/2 y logs

Mi receta de arranque:

• JVM: -Xms512m -Xmx1024m (ajusta a tus perfiles), -XX:+UseG1GC.

• Conector: maxThreads según concurrencia esperada (p.ej., 200–400), acceptCount para picos.

• Compresión: compression="on" y compressableMimeType.

• HTTP/2: mejora latencia en apps modernas (requiere TLS).

• Logs: activa access logs; envíalos a tu stack ELK/Datadog/CloudWatch.

• Pool JDBC: valora TestOnBorrow y límites del pool para evitar fugas.

En mi experiencia, el mayor salto viene de ajustar el pool de hilos y el pool de conexiones a base real y no a defaults.

8. Monitoreo con JMX y alertas útiles

Tomcat expone MBeans por JMX: hilos, sesiones, conectores, memoria.
Qué monitorizo siempre:

• Busy/Current Threads por conector.

• Tiempo de respuesta p95/p99.

• Sesiones activas por aplicación.

• Errores 4xx/5xx en access logs.
  Alerta si busyThreads se acerca al maxThreads o si el tiempo de respuesta se degrada en picos.

9. Migrar de javax.* a jakarta.*: qué cambia y cómo evitar sustos

El gran cambio es de paquetes: javax.servlet.* → jakarta.servlet.*. Para migraciones rápidas:

• Usa herramientas de rewriting (search/replace + pruebas).

• Verifica dependencias (JSP, JSTL, frameworks) compatibles con Jakarta.

• Haz pruebas de regresión en endpoints críticos y filtros/servlets.

Consejo: crea un branch de migración y despliega en un entorno gemelo; mide rendimiento antes y después.

10. Alternativas a Tomcat: Jetty, WildFly y Spring Boot embedded

• Jetty: muy ligero y flexible, a veces preferido en microservicios.

• WildFly/Payara: servidores de aplicaciones completos (JMS, CDI avanzado, clustering).

• Spring Boot embebido: si ya empaquetas un JAR ejecutable con Tomcat/Jetty embebido, podrías evitar instalar Tomcat externo.
  Yo comparo así: si necesito solo web y simplicidad, Tomcat. Si piden full EE, WildFly. Si el equipo es Spring puro, embebido.

11. Errores comunes y cómo los soluciono

• HTTP 404 al desplegar: el WAR no se expandió; revisa logs/localhost.*.log y nombre de contexto.

• OutOfMemoryError: sube Xmx y revisa fugas (heap dump + MAT).

• Conexiones colgadas: ajusta keepAliveTimeout y maxKeepAliveRequests.

• Conflictos de puerto: cambia Connector port o el servicio ocupando 8080.

• CORS/Headers: añade filtros o configura el proxy frontal.
  Y sí, parte de la “magia” de Tomcat es que solucionas estas cosas sin una curva imposible.

12. Preguntas frecuentes

¿Tomcat es “server de aplicaciones”?
Técnicamente es un contenedor de servlets; provee lo necesario para web Java, no toda la plataforma EE.

¿Sirve para apps que no son Java?
No es su terreno. Yo solo lo recomiendo para Java/Jakarta.

¿Qué versión elegir?
La más reciente estable compatible con tu Java, sobre todo si migras a jakarta.*.

Conclusión

Tomcat es el camino corto entre tu app Java y producción. En mi día a día valoro que es fácil de usar y que no me mete en jardines innecesarios. Eso sí, lo uso cuando la app es Java; si no, elijo otra herramienta. Con una instalación limpia, HTTPS bien puesto, unos toques de rendimiento y monitoreo por JMX, tienes un stack sólido para crecer sin dolores.