Gestión de dependencias en OSGi

Anteriormente en este blog hemos dado unos primeros pasos con OSGi, que os recomiendo leer si todavía no lo habéis hecho. Desde esas entradas he actualizado la versión de Apache Felix hasta la 1.2.1.

Ahora llega el momento de echar un vistazo a una de las características más interesantes de Osgi, como es la gestión de dependencias.

Lo primero que debemos conocer es que en OSGi permite exportar e importar paquetes de forma que es el contenedor OSGi el que se encarga de realizar y validar esas dependencias como paso previo a la ejecución de un módulo. Si no se pueden resolver dichas dependencias no se podrá ejecutar el módulo. Para jugar un poco con el tema, he creado dos pequeños módulos:

• Uno que exporta un Logger con funcionalidad avanzada (bueno, no muy avanzada, pero es que es un ejemplo) cuyo código vemos a continuación. Este módulo también tiene un BundleActivator que saca una traza tanto en el arranque como en la parada.:

package org.tcymu.osgi.log.logger;

public class Logger {
    public void log(String msg) {
        System.out.println(System.currentTimeMillis() + ": " + msg);
    }
}

• Otro que importa dicho Logger para hacer uso de él:

package org.tcymu.osgi.app;

import org.osgi.framework.BundleActivator;
import org.osgi.framework.BundleContext;
import org.tcymu.osgi.log.logger.Logger;

public class AppBundle implements BundleActivator {
    Logger logger = new Logger();

    public void start(BundleContext arg0) throws Exception {
        logger.log("Arrancando AppBundle");
    }

    public void stop(BundleContext arg0) throws Exception {
        logger.log("Parando AppBundle");
    }
}

Tanto la exportación como la importación de los paquetes se hace a través de los descriptores. Las líneas importantes son:

Bundle-SymbolicName: org.tcymu.osgi.log.LogBundle
Bundle-Version: 1.0.0
Bundle-Activator: org.tcymu.osgi.log.LogBundle
Import-Package: org.osgi.framework
Export-Package: org.tcymu.osgi.log.logger;version="1.0.0"

y en la importación:

Bundle-SymbolicName: org.tcymu.osgi.app.AppBundle
Bundle-Version: 1.0.0
Bundle-Activator: org.tcymu.osgi.app.AppBundle
Import-Package: org.osgi.framework,org.tcymu.osgi.log.logger;version="1.0.0"

Empaquetaremos ambos módulos tal y como vimos en la anterior entrada. Ahora vamos a probar la instalación. Primero en el orden correcto. Primero instalo el módulo de log y después la aplicación:

install file:////d:/felix-1.2.1/bundle/org.tcymu.osgi.log.logbundle-1.0.0.jar Bundle ID: 16 install file:////d:/felix-1.2.1/bundle/org.tcymu.osgi.app.appbundle-1.0.0.jar Bundle ID: 17 start 16 start 17 Todo funciona correctamente. Ahora podemos hasta desinstalar el módulo de log, que una vez exportado, el contenedor mantiene una copia de esas clases para ofrecerlas a quien las necesite. Ahora vamos a parar y desinstalar nuestros módulos. También paro y reinicio Felix, ya que quiero comprobar qué ocurre si no tenemos una dependencia. Si instalo sólo el módulo de aplicación e intento arrancar, me lanza el siguiente error:

org.osgi.framework.BundleException: Unresolved constraint in bundle 24: package; (&(package=org.tcymu.osgi.log.logger)(version>=1.0.0))

Voy a dejar para una segunda parte de esta entrada el crear nuevas versiones de los módulos y comprobar cómo ser gestionan en el contenedor.

Actualización: Segunda parte

CSS: Cambiar la imagen de un div con enlace «onmouseover»

Supongamos que tenemos una imagen que hará de enlace y que queremos que cambie cuando pasamos el ratón sobre ella.

Por ejemplo si tenemos un enlace en una celda de una tabla, en lugar de <td><a><img/></a></td>, lo haremos de la siguiente manera:

<td>
<div id="enlace">
<a href="http://www.tuscerosymisunos.es"></a>
</div>
</td>

Y en nuestro CSS tendremos:

div#enlace a{
	float:left;
	width:205px;
	height:27px;
	background-image:url(img/enlace_off.gif);
	background-repeat: no-repeat;
}
div#enlace a:hover{
	background-image:url(img/enlace_on.gif);
	background-repeat: no-repeat;
}

Señalar que aparece el tamaño de las imágenes (preferiblemente serán del mismo tamaño) y la ruta a las mismas (en este caso están en el directorio img y son imagen_off.gif e imagen_on.gif).

Y con este sencillo truco nos podemos librar de los javascript para realizar esta tarea.

Instalación de un servidor CVS casero

CVS (Concurrent Versions System) es un sistema de control de versiones, algo que no debería ser ajeno a ningún desarrollador.

En mi XUbuntu (todavía necesito las X para alguna cosilla, aunque estoy en proceso de quitarme) voy a instalar un servidor casero de CVS para mis cosillas. Voy a utilizar CVS porque es lo que más domino, aunque pretendo migrar a Subversion o Git más pronto que tarde. Cuando suceda, tendréis el correspondiente tutorial.

Lo primero que he hecho es instalar cvsd (es un recubrimiento a cvs para aumentar algo la seguridad), lo que nos instala cvs como dependencia. Durante la instalación nos pregunta los repositorios que queremos publicar mediante cvsd, aunque esto lo podemos modificar luego en el archivo cvsd.conf (en /etc/cvsd), más concretamente con las líneas que comienzan por Repos.

Para crear un repositorio (lógicamente los que le hemos indicado durante la instalación) utilizamos el comando init de cvs. Explicaros que cvs desde línea de comandos tiene la siguiente estructura:

cvs [cvs-options] cvs-command [command-options] [command-args]

El comando init inicializa un repositorio (lo ejecutaremos como root o mediante sudo). Mediante la opción -d le indicamos la ruta al repositorio.

cvs -d /var/lib/cvsd/tcymu init

Esto crea el repositorio en la ruta especificada, lo que podemos comprobar mirando el contenido de /var/lib/cvsd/tcymu. Observaremos el directorio CVSROOT con contenido propio del servidor CVS.

Ahora añadimos un usuario a nuestro repositorio (de nuevo como root):

cvsd-passwd /var/lib/cvsd/tcymu +tcymu

Nos pide un password, que será el que utilizaremos para entrar posteriormente. Lo almacena (cifrado por supuesto) en /var/lib/cvsd/tcymu/CVSROOT/passwd.

Bien, ya tenemos preparado el CVS. Si tenemos un firewall activado, debemos recordar abrir los puertos correspondientes: 2401 por defecto.

Y ahora y desde línea de comandos (es decir, que así podemos trabajar tanto en Linux como en Windows) podremos identificarnos en CVS mediante el comando:

cvs -d :pserver:user@server:/repository login

Hay que notar que la opción -d sólo es necesaria si no tenemos definida una variable de entorno CVSROOT. Por lo tanto si trabajamos con un único servidor CVS pues lo más cómodo es añadir dicha variable de entorno.

Una vez identificados en CVS el primer paso sería añadir un directorio al CVS, ya que de momento nuestro repositorio está vacío. Creamos un directorio local que albergará nuestro proyecto CVS y dentro de ese directorio ejecutamos:

cvs -d :pserver:user@server:/repository co -l .

Notaremos que se nos ha creado una carpeta CVS que contiene los archivos necesarios para mantener el estado de nuestra imagen del CVS.

Ahora ya podemos empezar a trabajar en nuestro proyecto de la forma habitual. Crearemos archivos, los añadiremos, haremos commit y demás. El trabajo habitual con CVS queda para una entrada futura, aunque no faltan precisamente recursos en la red.