Gestión de dependencias en OSGi (y 2)
3 noviembre 2008 at 7:50 pm 1 comentario
En la primera parte de esta entrada vimos cómo exportar e importar paquetes, y ahora vamos a ver el funcionamiento con varias versiones de dichos paquetes.
Para empezar, es el momento de mejorar nuestro Logger:
package org.tcymu.osgi.log.logger; import java.text.SimpleDateFormat; import java.util.Date; public class Logger { private SimpleDateFormat dateFormat = new SimpleDateFormat("dd-MM-yyyy HH:mm:ss.S"); private Date date = new Date(); public void log(String msg) { date.setTime(System.currentTimeMillis()); System.out.println(dateFormat.format(date) + ": " + msg); } }
Y también actualizamos las siguientes líneas del MANIFEST para cambiar su versión:
Bundle-Version: 1.0.1 Export-Package: org.tcymu.osgi.log.logger;version="1.0.1"
Si empezamos a instalar de nuevo los módulos (hemos generado una nueva versión logbundle-1.0.1.jar) en Felix, comprobamos que podemos perfectamente tener dos versiones de una librería (en este caso nuestro Logger) instaladas, y que cada aplicación según su configuración utilizará una u otra. Si hacemos la prueba vemos que si tenemos las dos versiones del Logger va a utilizar la versión 1.0.1. ¿Por qué?. La respuesta es que version="1.0.0"
se interpreta como version >= 1.0.0 y el contenedor selecciona la mayor. ¿Existe otra manera de definir las versiones?. Por supuesto. Los intervalos:
version="1.0.0"
se interpreta como version >= 1.0.0
version="[1.0.0,1.1.0)"
se interpreta como 1.0.0 <= version < 1.1.0
version="(1.0.0,1.1.0]"
se interpreta como 1.0.0 < version <= 1.1.0
NOTA: Nótese la notación estilo matemático para definir los intervalos abiertos o cerrados.
Por lo tanto si modificamos el MANIFEST de nuestro módulo de aplicación, en concreto la siguiente línea:
Import-Package: org.osgi.framework,org.tcymu.osgi.log.logger;version="[1.0.0,1.0.0]"
comprobamos que ahora hemos forzado a que utilice la versión antigua.
También debemos conocer que en el caso de que tengamos módulos que exportan un mismo paquete con una misma versión, todavía podemos diferenciarlos y forzar la carga de uno determinado mediante la utilización de atributos. Por ejemplo, si tenemos exportado nuestro Logger de esta manera:
Export-Package: org.tcymu.osgi.log.logger;version="1.0.1";provider="tcymu"
Y existiera otro módulo que exportara el mismo paquete, se podría forzar a utilizar nuestro paquete mediante:
Import-Package: org.tcymu.osgi.log.logger;version="1.0.1";provider="tcymu"
Existen más posibilidades que dejaremos en el tintero de momento, como por ejemplo la directiva resolution, el atributo use, la fragmentación de módulos o la dependencia de módulos (Require-Bundle). Se puede ver todo esto en la especificación descargable (previo registro) en la web de OSGi.
Y esto es todo de momento. Próximamente veremos la utilización de servicios en OSGi.
1 comentario Add your own
Deja una respuesta
Trackback this post | Subscribe to the comments via RSS Feed
1. Gestión de dependencias en OSGi « Tus ceros y mis unos | 17 diciembre 2008 a las 10:06 am
[…] Actualización: Segunda parte […]