Mi espacio

Uso Eclipse, WTP (Web Tools Project) y Maven desde hace mucho años. Cada vez que he tenido que configurar un nuevo entorno, y han pasado meses desde la última vez, me encuentro con pequeñas sorpresas. Por otro lado es normal, en los proyectos se toman decisiones que afectan a quienes usamos el software. Además en este caso todas las piezas son open source y es una maravilla que podamos disfrutar de estas herramientas sin un coste directo.

Desde hace unos días estoy montando mi entorno de desarrollo en un nuevo MacBook Pro que he adquirido. Instalé Eclipse Helios, Apache Maven 2.2.1 (sí, aun tenemos proyectos no migrados) y algunos plugins para Eclipse como MultiProject, Checkstyle, AnyEdit, etc.

Cual fue mi sorpresa que tras realizar el checkout de mivecindad, ejecutar mvn install eclipse:eclipse [...] e intentar ejecutar el proyecto (Facet: Dynamic Web Module, Java) había muchas dependencias que WTP no podía resolver. Esto se solucionaba anteriormente indicándole a proyecto principal (webapp) que los otros proyectos (service, model, resources, etc) eran módulos (J2EE Modules) de éste. Para ello encontrábamos una opción en las preferencias del proyecto llamada J2EE Modules Dependencies.

Pues bien, esta opción ha desaparecido. Ahora podemos hacer lo mismo dentro de la opción Deployment Assembly.

Si ayer hablábamos de cómo configurar Apache Tomcat con Apache Tomcat Native, hoy vamos a ver cómo lanzar el servidor como un servicio del sistema operativo. Esto implica dejar a un lado los scripts startup.sh, catalana.sh y shutdown.sh que se encuentran en $TOMCAT_HOME/bin. Para esto necesitaremos Commons Daemon Native que podemos encontrar en los binarios de Apache Tomcat. La versión que necesitamos se encuentra en $TOMCAT_HOME/bin/commons-daemon-native.tar.gz y corresponde con la 1.0.5. La instalación es muy sencilla:

1. Descomprimir commons-daemon-native.tar.gz
2. Entrar en el directorio unix que encontraremos
3. Ejecutamos:

   ./configure --with-java=/usr/local/java
   make

4. Encontraremos que se ha generado un binario llamado jsvc
5. Copiamos este ejecutable a $TOMCAT_HOME/bin
6. Creamos el usuario y grupo tomcat que necesitaremos para la configuración. El UID tendremos que elegirlo según nuestro S.O.:

   useradd -b /opt/tomcat -u 105 -s /bin/false tomcat

7. Ahora conviene que revisemos el propietario de los directorios y archivos que tenemos en $TOMCAT_HOME, principalmente conf, log, webapp, temp y work. Si algo no está bien, lo veremos claramente en los logs.

La parte interesante corresponde con la configuración. Lo mejor para explicarlo es hacerlo sobre el archivo que usamos en Clinker Virtual Appliance. A continuación el contenido del script tomcat6.sh que colocaremos en /etc/init.d:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55

#!/bin/sh
 
. /lib/lsb/init-functions
 
JAVA_HOME=/usr/local/java
 
CATALINA_HOME=/opt/tomcat
DAEMON_HOME=/opt/tomcat/bin
TOMCAT_USER=tomcat
TMP_DIR=/opt/tomcat/temp
PID_FILE=/var/run/jsvc.pid
CATALINA_BASE=/opt/tomcat
CATALINA_OPTS="-Djava.library.path=/usr/local/lib/tomcat-native -Xms256m -Xmx512m -XX:MaxPermSize=256m"
 
CLASSPATH=\
$JAVA_HOME/lib/tools.jar:\
$CATALINA_HOME/bin/commons-daemon.jar:\
$CATALINA_HOME/bin/bootstrap.jar
 
case "$1" in
  start)
    log_daemon_msg "Starting Apache Tomcat launched with commons-daemon (jsvc)" "jsvc"
    log_end_msg 0
    $DAEMON_HOME/jsvc \
    -jvm server \
    -user $TOMCAT_USER \
    -home $JAVA_HOME \
    -Dcatalina.home=$CATALINA_HOME \
    -Dcatalina.base=$CATALINA_BASE \
    -Djava.io.tmpdir=$TMP_DIR \
    -wait 10 \
    -pidfile $PID_FILE \
    -outfile $CATALINA_HOME/logs/catalina.out \
    -errfile '&1' \
    $CATALINA_OPTS \
    -cp $CLASSPATH \
    -showversion \
    org.apache.catalina.startup.Bootstrap
    exit $?
    ;;
 
  stop)
    log_daemon_msg "Stopping Apache Tomcat" "jsvc"
    log_end_msg 0
    $DAEMON_HOME/jsvc \
    -stop \
    -pidfile $PID_FILE \
    org.apache.catalina.startup.Bootstrap
    exit $?
    ;;
 
  *)
    echo "Usage tomcat6 start/stop"
    exit 1;;
esac

Como podéis comprobar, este script es el candidato perfecto para localizar variables de entorno y cualquier otra cosa que necesitemos inicializar antes de lanzar Apache Tomcat. Por lo tanto, la variable LD_LIBRARY_PATH que necesitamos en la entrada anterior, podemos definirla aquí. Los parámetros de configuración relacionados con la memoria se controlan desde la variable local CATALINA_OPTS. Observaremos que únicamente se crea un archivo de log en $TOMCAT_HOME/logs, para recuperar los otros archivos tendremos que proporcionar la configuración de logging. En el arranque de Apache Tomcat debemos encontrar algo similar a esto:

java version "1.6.0_24"
Java(TM) SE Runtime Environment (build 1.6.0_24-b07)
Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02, mixed mode)
commons daemon version "1.0.5"
commons daemon process (id: 3882, parent: 3881)
20-abr-2011 13:02:14 org.apache.catalina.core.AprLifecycleListener init
INFO: Cargada la biblioteca nativa APR de Apache Tomcat 1.1.20
20-abr-2011 13:02:14 org.apache.catalina.core.AprLifecycleListener init
INFO: Capacidades APR: IPv6 [true], enviar fichero [true], aceptar filtros [false], aleatorio [true].
20-abr-2011 13:02:14 org.apache.coyote.http11.Http11AprProtocol init
INFO: Inicializando Coyote HTTP/1.1 en puerto http-8080
20-abr-2011 13:02:14 org.apache.coyote.ajp.AjpAprProtocol init
INFO: Inicializando Coyote AJP/1.3 en ajp-8009
20-abr-2011 13:02:14 org.apache.catalina.startup.Catalina load
INFO: Initialization processed in 889 ms
20-abr-2011 13:02:14 org.apache.catalina.core.StandardService start
INFO: Arrancando servicio Catalina
20-abr-2011 13:02:14 org.apache.catalina.core.StandardEngine start
INFO: Starting Servlet Engine: Apache Tomcat/6.0.32
20-abr-2011 13:02:14 org.apache.catalina.startup.HostConfig deployDescriptor
INFO: Desplieque del descriptor de configuración host-manager.xml
20-abr-2011 13:02:14 org.apache.catalina.startup.HostConfig deployDescriptor
INFO: Desplieque del descriptor de configuración manager.xml
20-abr-2011 13:02:15 org.apache.catalina.startup.HostConfig deployDirectory
INFO: Despliegue del directorio docs de la aplicación web
20-abr-2011 13:02:15 org.apache.catalina.startup.HostConfig deployDirectory
INFO: Despliegue del directorio ROOT de la aplicación web
20-abr-2011 13:02:15 org.apache.catalina.startup.HostConfig deployDirectory
INFO: Despliegue del directorio examples de la aplicación web
20-abr-2011 13:02:15 org.apache.catalina.core.ApplicationContext log
INFO: ContextListener: contextInitialized()
20-abr-2011 13:02:15 org.apache.catalina.core.ApplicationContext log
INFO: SessionListener: contextInitialized()
20-abr-2011 13:02:15 org.apache.coyote.http11.Http11AprProtocol start
INFO: Arrancando Coyote HTTP/1.1 en puerto http-8080
20-abr-2011 13:02:15 org.apache.coyote.ajp.AjpAprProtocol start
INFO: Arrancando Coyote AJP/1.3 en ajp-8009
20-abr-2011 13:02:15 org.apache.catalina.startup.Catalina start
INFO: Server startup in 1084 ms

Para cualquier consulta, no dudéis en dejar un mensaje e intentaré atender como mejor sepa y pueda.

Desde hace ya muchos años, Apache Tomcat forma parte de mi caja de herramientas. Supongo esto también le sucederá a otros muchos profesionales. Bien es cierto, que cada vez más comparte espacio con soluciones como Jetty o Glassfish, sin embargo, yo le tengo un respeto prácticamente infinito. Son muchos los entornos de producción a los que he tenido acceso y en los que Apache Tomcat era la opción para actuar como contenedor JSP/Servlet. Que no os extrañe si os digo que en la mayoría la instalación consistía en:

1. Descargar el tar.gz
2. Descomprimirlo
3. Y lanzar $TOMCAT_HOME/bin/startup.sh

Me gustaría compartir con vosotros cómo configuramos nosotros (@klicap) Apache Tomcat con el objetivo de conocer vuestras impresiones y dejar unas notas para que no se olviden. Esta es la configuración que estamos usando en Clinker Virtual Appliance. En las siguientes instrucciones se presupone que estamos usando un S.O. Linux y que la JVM está correctamente configurada.

1. Descargar los binarios del sitio web oficial.
2. Descomprimir el tar.gz en /opt
3. Crear un enlace simbólico /opt/tomcat > /opt/apache-tomcat-6.0.32
4. En $TOMCAT_HOME/bin encontraremos tomcat-native.tar.gz que corresponde con Apache Tomcat Native, una librería que mejora el rendimiento porque delega en APR ciertas funcionalidades que están implementadas de forma nativa.
5. Descomprimimos tomcat-native.tar.gz
6. Configuramos el proyecto y compilamos:

   ./configure \
   --libdir=/usr/local/lib/tomcat-native-1.1.20 \
   --with-java-home=/usr/local/java \
   --with-apr=/usr/bin/apr-1-config

   make && make install

7. Creamos un enlace simbólico /usr/local/lib/tomcat-native > /usr/local/lib/tomcat-native-1.1.20
8. Configuramos la variable de entorno (p.e. en /etc/profile):

   export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib/tomcat-native

Cuando lancemos Apache Tomcat encontraremos en los logs el siguiente mensaje:

19-abr-2011 13:09:45 org.apache.catalina.core.AprLifecycleListener init
INFO: Cargada la biblioteca nativa APR de Apache Tomcat 1.1.20
19-abr-2011 13:09:45 org.apache.catalina.core.AprLifecycleListener init
INFO: Capacidades APR: IPv6 [true], enviar fichero [true], aceptar filtros [false], aleatorio [true].

En una instalación por defecto hubiéramos encontrado un mensaje similar a este:

org.apache.catalina.core.AprLifecycleListener init
INFO: The APR based Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path

En la siguiente entrada veremos cómo configurar commons-daemon con Apache Tomcat.

En estos últimos años he tenido la oportunidad de intervenir (no se pueden llamar proyectos) en situaciones donde nos encontrábamos con aplicaciones que llevaban semanas puestas en producción y que daban muchos problemas a los departamentos de sistemas, infraestructuras u operaciones, como queráis llamarlos. Los problemas se manifestaban dónde menos te lo esperabas, sin embargo, el efecto que provocaban era evidente, la aplicación no cumplía el objetivo para el que había sido concebida. Algunas se degradaban con el paso de tiempo, otras no soportaban la carga puntual de la mañana y otras tenían tiempos de respuesta tan altos que era como si la aplicación no existiese. Me estoy refiriendo a aplicaciones web.

En este tipo de escenarios hay gente que piensa que vas a llegar, vas a tocar dos o tres parámetros de configuración y todo arreglado. No digo que haya casos en los que algo así pueda solucionar el problema temporalmente, pero ten por seguro que lo único que has conseguido es barrer la basura y esconderla debajo de la alfombra.

Si la tensión del ambiente aun te permite respirar lo primero es monitorizar. Es básico instalar sondas que arrojen datos que por un lado te permitan justificar que ciertos cambios aportan mejoras y por otro lado, te digan donde están los problemas:

1. Consumo de CPU prolongado en el tiempo o simplemente puntual bajo ciertas circunstancias
2. La RAM está al 100% y tu amiga swap está a punto de entrar en juego
3. Le has preguntado a tu gestor de base de datos qué le están haciendo?
4. Las integraciones (facebook, SSO corporativo, flickr) qué tal van?

El problema es que esto requiere que te dejen instalar y configurar ciertas herramientas en entornos de producción. Y ahí, con la iglesia hemos topado. Salvo que la tensión sea muy alta, rara vez te dejarán. Obviamente si las cosas de hicieran convenientemente, no haría falta llegar a estas situaciones, pero la realidad y el día a día son bien distintos.

Hacía ya tiempo que la conocía, pero no he tenido oportunidad de probarla hasta hace muy poco con una aplicación en producción y con picos de usuarios muy interesantes. Lo que más me gusta es que es una aplicación con un modelo SaaS en el que te instalas un agente que envía información a un servidor y simplemente tienes que acceder a la aplicación y comenzar a ver datos.

Pude probarlo en uno de los front-ends que formaban parte de la infraestructura. Los datos que muestra son realmente interesantes para analizar qué está pasando en tu aplicación y cómo de mal lo está pasando el servidor. La interfaz gráfica de la aplicación es agradable y fácil de usar para la complejidad y cantidad de información que gestiona. Su precio realmente asequible para el valor que proporciona. Está disponible para los stacks Java, PHP, Ruby y .NET. Os recomiendo que la probéis, te dejan usar la modalidad Gold completamente gratis durante una semana.

Conocí este excelente framework en el año 2008. Desde entonces no ha faltado en mi caja de herramientas. Son más de 5 proyectos en los que he participado y se ha optado por ExtJS. Según últimas noticias en febrero 2011 publicarán la versión 4. Ahora, junto a otros productos como Ext GWT, Ext Designer o Sencha Touch, forman Sencha Inc. Se ha ganado mi confianza por:

1. Me gusta su modelo dual de licencia. Si sacas dinero con tu producto compra al menos una licencia
2. La documentación del API es buena y accesible. Desde mi punto de vista, un fallo que comenten es dejar de publicar versiones anteriores de la API
3. Ofrece un conjunto muy amplio de elementos gráficos: form, grid, menu, window, panel, etc.
4. Layout Managers potentes
5. Se pueden conseguir interfaces gráficas muy dinámicas e interactivas
6. Excelente compatibilidad con los principales navegadores. Eso no quita que también haya que usar hacks.
7. Es la pieza que encaja perfectamente en nuestro puzle:
   1. Server-side: Hibernate + Spring + Resteasy = Restful API (JSON)
   2. Client-side: ExtJS (Model + View + Events).
8. En aplicaciones con una interfaz gráfica compleja el rendimiento se puede ver resentido sino seguimos buenas prácticas y nos encontramos con versiones algo antiguas.
9. Relacionado con el punto anterior está YUI Compressor, JSLint y si usas Apache Maven, yuicompressor-maven-plugin
10. Distribuyen ExtJS con un conjunto muy amplio de plugins. Estos plugins, terminan formando parte del API. Creo que esto se produce cuando el plugin madura y tiene suficiente aceptación.
11. Hay una gran comunidad: foros, tutoriales, libros y gente muy activa como Jozef Sakalos (aka Saki)
12. En caso de necesitarlo, hay una empresa detrás ofreciendo soporte profesional. Empresa que recientemente recibió una gran inversión económica.
13. A parte de la experiencia adquirida en esos proyectos, hay importantes referencias de ExtJS: MapFish, Nexus (Sonatype), PHP Docbook Online Editor, y otros no públicos que he tenido la oportunidad de ver.

Quizás revise esta lista pronto. Podéis ver algunas capturas de pantalla de dos proyectos en los que estamos (@klicap) trabajando y estamos ExtJS, Opina y mivecindad.