Este fin de semana estuve “destripando” ServiceMix, específicamente la distribución 4.2.0-fuse-02-00 de Fuse. El objetivo era generar un war desplegable en Tomcat6, ya que la versión de Fuse sólo viene como aplicación standalone.

Al final fue no fue tan complicado, porque hay un ejemplo que facilita enormemente la tarea.

Al grano

Para ejecutivos de tiempo escaso, estos son los pasos a seguir.

Supuestos:

• Linux, distribución Ubuntu Karmic x86_64.
• Tomcat6 instalado vía apt (relevante, porque determina rutas, permisos y usuario tomcat6).
• estar conectado a internet (se bajarán componentes en la instalación).

Pasos:

• Baja el war karaf-smx-1.4.0-fuse-02-00.war
• Como root, crea el directorio .karaf en el home de tomcat6: mkdir /usr/share/tomcat6/.karaf
• Cambia el owner de .karaf a tomcat6: chown tomcat6:tomcat6 /usr/share/tomcat6/.karaf
• Crea un link a etc en el directorio de trabajo de tomcat: ln -sf /var/lib/tomcat6/webapps/karaf-smx/WEB-INF/karaf/etc /var/lib/tomcat6/etc
• Despliega el war: cp /path/to/karaf-smx-1.4.0-fuse-02-00.war /var/lib/tomcat6/webapps/karaf-smx.war

Ahora deberás esperar un buen rato, porque Karaf empezará a bajar e instalar los bundles de ServiceMix. Puedes ir vigilando lo que pasa en el log:

$ tail -f /var/lib/tomcat6/webapps/karaf-smx/WEB-INF/karaf/data/log/servicemix.log

Para verificar que todo está listo, abre una consola (el password es smx):

$ ssh -p 8101 -l smx localhost

Ejecuta el comando list, para ver los bundles instalados:

smx@root> list
START LEVEL 100
   ID   State         Blueprint      Spring    Level  Name
[   0] [Active     ] [            ] [       ] [    0] OSGi System Bundle (3.5.1.R35x_v20090827)
[   1] [Active     ] [            ] [       ] [    5] OPS4J Pax Url - mvn: (1.1.2)
[   2] [Active     ] [            ] [       ] [    5] OPS4J Pax Url - wrap: (1.1.2)
...
[ 173] [Active     ] [            ] [       ] [   60] Apache ServiceMix Bundles: commons-io-1.3.2 (1.3.2.3)
[ 174] [Active     ] [            ] [       ] [   60] camel-cxf (2.2.0.fuse-02-00)
[ 175] [Active     ] [            ] [       ] [   60] camel-jms (2.2.0.fuse-02-00)
smx@root>

Cuando sean 175 debería esta todo listo para la acción .

Explicación

El war de arriba es una versión modificada del proyecto web, ubicado en examples/karaf-demos. El código fuente lo puedes bajar desde karaf-smx-4.2.0-fuse-02-00.tar.gz. Los cambios realizados son:

• El parent es directamente org.apache.felix.karaf:karaf:1.4.0-fuse-02-00.
• Las coordenadas del proyecto son org.apache.felix.karaf:karaf-smx:1.4.0-fuse-02-00:war.
• El directorio etc de apache-felix-karaf fue reemplazado por los archivos de la distribución de Fuse, así no hay que agregar a mano el repositorio de Fuse, los features de ServiceMix, bundles, etc.
• El listener org.apache.felix.karaf.web.WebAppListener fue modificado para:
  • verificar la existencia del link etc en el directorio de trabajo del usuario tomcat6.
  • verificar la existencia del directorio .karaf (y sus permisos) en el home del usuario tomcat6.
  • asignar a storage.location el directorio .karaf del home del usuario tomcat6.

Karaf

Karaf es un contenedor liviano que corre sobre una plataforma OSGI –Felix o Equinox- y provee un conjunto de servicios, como logging, hot deploy, configuración dinámica, etc. Karaf actúa como kernel de ServiceMix, por lo que para poder ejecutar ServiceMix en Tomcat (o cualquier otro contenedor) basta lograr ejecutar Karaf en dicho ambiente y luego desplegar los bundles de ServiceMix.

Ubuntu

Ubuntu da problemas para el demo web debido a su esquema de permisos. Cuando uno accede a la shell de Karaf vía SSH, se crea en el home del usuario que corre el proceso Karaf (en este caso tomcat6) el archivo .karaf/karaf.history. Como en Ubuntu el home del usuario tomcat6 es /usr/share/tomcat6, que no tiene permisos de escritura para tomcat6, ocurre una excepción cuando Karaf trata de crear el archivo. Por eso se debe crear a mano /usr/share/tomcat6/.karaf y asignarle permisos de escritura a tomcat6.

Bundle activemq-broker

Otro problema, esta vez relacionado a ServiceMix, es que bundle activemq-broker trata de leer el archivo etc/activemq-broker.xml desde el directorio de trabajo. Esto es “poco amistoso” con un esquema de despliegue web, donde los archivos de la aplicación no se encuentran en el directorio de trabajo. La solución “parche” es crear el link /var/lib/tomcat6/etc a /var/lib/tomcat6/webapps/karaf-smx/WEB-INF/karaf/etc, así el bundle activemq-broker pordrá encontrar etc/ activemq-broker.xml.

Conclusiones

No es complicado desplegar Karaf 1.4, y sobre él ServiceMix 4.2, en Tomcat. Sin embarago, por los detalles expuestos en este post, es notorio que las cosas están hechas para funcionar en forma standalone.

Hace poco (23/07) se liberó Karaf 2.0.0, que define nuevas variables de entorno que permiten distribuir diferentes partes de karaf en el sistema de archivos. Esto permitiría, por ejemplo, dejar la configuración en /etc, los datos en /var, y en el war sólo los binarios.

Otra cosa destacable es que ServiceMix “es sólo” un conjunto de bundles sobre Karaf. Además, hay esfuerzos en Karaf para apoyar la generación de distribuciones personalizadas, lo que es atractivo, pues se podría lograr un runtime “a medida”, con los bunldes justos (y evitar así los 170 y tanto que trae ServiceMix).

• El jar resultante es una sopa de artefactos, ya que se mezclan todas las dependencias directas y transitivas con la aplicación misma.
• No escala; para proyectos con muchas dependencias, el proceso de formar el “super jar” es lento, por lo que no es una opción viable para utilizar en tiempo de desarrollo (sólo al hacer un release).
• Pueden haber problemas de licencia. Algunas dependencias pueden exigir que se mantenga la integridad de los binarios que distribuyen, prohibiendo “reempaques”.

Los requerimientos que deseo satisfacer son bastante simples:

1. Generar un jar con el manifiesto necesario; esto es, que indique la clase con el punto de entrada main y las dependencias.
2. Poder obtener todos los jars de las dependencias, directas y transitivas, en un directorio de salida aparte (lib, por ejemplo).
3. Generar un pequeño script bash, que lance el jar con el classpath configurado.
4. Obtener una distribución de la aplicación, o sea, copiar todo lo anterior en un directorio del sistema (o en target).
5. Debe ser rápido!, ya que será ejecutado recurrentemente, en tiempo de desarrollo.

En algún momento del pasado lejano llegué a una configuración que satisface los objetivos listados, consistente en una combinación de maven-jar-plugin, maven-dependency-plugin y maven-resources-plugin.

La aplicación

La sofisticada aplicación de ejemplo es un “hola mundo” camuflado:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

package cl.totex.demo;
 
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
 
public class Demo
{
	private static final Logger logger = LoggerFactory.getLogger(Demo.class);
 
	public static void main(String... args)
	{
		if(args.length > 0)
			logger.info("holo {}", args[0]);
		else
			logger.info("duh!");
	}
}

El POM

Aparte de toda la información usual de un POM, uso la propiedad install-dir, que indicará a Maven el directorio de instalación de la aplicación.

1
2
3

<properties>
	<install-dir>${build.directory}</install-dir>
</properties>

Las únicas dependencias son las correspondientes al logger, slf4j. Por simplicidad, el binding elegido es SimpleLogger ; por lo tanto, las dependencias necesarias en el POM son:

1
2
3
4
5
6
7
8
9
10

<dependency>
	<groupId>org.slf4j</groupId>
	<artifactId>slf4j-api</artifactId>
	<version>1.6.0</version>
</dependency>
<dependency>
	<groupId>org.slf4j</groupId>
	<artifactId>slf4j-simple</artifactId>
	<version>1.6.0</version>
</dependency>

El requerimiento 1 se puede solucionar con plugin maven-jar-plugin, que permite generar un jar con un manifiesto donde queda establecida la clase con el punto de entrada main y el classpath.

1
2
3
4
5
6
7
8
9
10
11
12
13

<plugin>
	<artifactId>maven-jar-plugin</artifactId>
	<version>2.2</version>
	<configuration>
		<archive>
			<manifest>
				<mainClass>cl.totex.demo.Demo</mainClass>
				<addClasspath>true</addClasspath>
				<classpathPrefix>lib</classpathPrefix>
			</manifest>
		</archive>
	</configuration>
</plugin>

Para el segundo requerimiento se puede usar el plugin maven-dependency-plugin, que permite copiar las dependencias directas y transitivas al directorio lib. El plugin sólo copiará los jars faltantes, por lo que la ejecución de la fase install no se ralentiza.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

<plugin>
	<artifactId>maven-dependency-plugin</artifactId>
	<version>2.0</version>
	<executions>
		<execution>
			<id>copy-dependencies</id>
			<phase>install</phase>
			<goals>
				<goal>copy-dependencies</goal>
			</goals>
			<configuration>
				<outputDirectory>${install-dir}/${artifactId}/lib</outputDirectory>
				<overWriteReleases>false</overWriteReleases>
				<overWriteSnapshots>false</overWriteSnapshots>
				<overWriteIfNewer>true</overWriteIfNewer>
			</configuration>
		</execution>
	</executions>
</plugin>

El plugin maven-resources-plugin permite satisfacer los últimos dos requerimientos: generar un script de lanzamiento y copiar el jar de la aplicación al directorio install-dir.

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

<plugin>
	<artifactId>maven-resources-plugin</artifactId>
	<version>2.4.3</version>
	<executions>
		<execution>
			<id>copy-jar</id>
			<phase>install</phase>
			<goals>
				<goal>copy-resources</goal>
			</goals>
			<configuration>
				<outputDirectory>${install-dir}/${artifactId}</outputDirectory>
				<resources>
					<resource>
						<directory>${build.directory}</directory>
						<includes>
							<include>${build.finalName}.jar</include>
						</includes>
					</resource>
					<resource>
						<directory>${project.basedir}/src/main/resources</directory>
						<filtering>true</filtering>
					</resource>
				</resources>
			</configuration>
		</execution>
	</executions>
</plugin>

La opción filtering, le indica a Maven que debe filtrar es el script run.sh, esto es, reemplazar todas las propiedades que encuentra. El código original de run.sh es:

1
2
3
4

#!/bin/bash
 
java -cp ${install-dir}/${artifactId}/lib\
 -jar ${install-dir}/${artifactId}/${build.finalName}.jar $*

Al filtrar el script anterior, se reemplazan los placeholders ${install-dir}, ${artifactId} y ${build.finalName} por sus valores reales.

Instalación

Por ejemplo, al ejecutar mvn -Dinstall-dir=/home/totex install se crea el directorio /home/totex/demo, con el siguiente contenido:

1
2
3
4
5
6
7
8
9

$ tree -f
.
|-- ./demo-1.0-SNAPSHOT.jar
|-- ./lib
|   |-- ./lib/slf4j-api-1.6.0.jar
|   `-- ./lib/slf4j-simple-1.6.0.jar
`-- ./run.sh
 
1 directory, 4 files

1
2
3
4

#!/bin/bash
 
java -cp /home/totex/demo/lib\
 -jar /home/totex/demo/demo-1.0-SNAPSHOT.jar $*