Acabo de leer la propuesta que hay sobre la mesa para llevar Jetty a eclipse.org e incluso formar parte de Eclipse 3.5 (Galileo) para este verano. Es interesante sobre todo porque los planes a largo plazo son involucrarse en mejorar el HttpService de Equinox (y supongo que la especificación OSGi del mismo).Posts Tagged osgi
Jetty como proyecto Eclipse
Jan 28
Acabo de leer la propuesta que hay sobre la mesa para llevar Jetty a eclipse.org e incluso formar parte de Eclipse 3.5 (Galileo) para este verano. Es interesante sobre todo porque los planes a largo plazo son involucrarse en mejorar el HttpService de Equinox (y supongo que la especificación OSGi del mismo).Code Coverage en Eclipse
Aug 8
Aunque se supone que estoy de vacaciones… no he podido resistir el hacer un ejercicio (que publicaré en breve en este blog) sobre Refactoring. Pero quería ver cómo de buenos eran mis tests y, la verdad, no me siento cómodo con el plugin de Cobertura para Maven: quería algo más integrado con Eclipse. Para ello he estado mirando los proyectos TPTP de Eclipse y EclEmma. Ambos están basados en Emma.
Después de buscar y buscar cómo instalar el módulo de code coverage de TPTP me he encontrado con que han abandonado el desarrollo para usar justamente EclEmma. Bueno, eso me ha simplificado el trabajo. 
Así pues, después de instalar EclEmma, probar la cobertura de mis tests JUnit ha sido muy fácil. Simplemente he seguido las instrucciones. (Ejem, he de reconocer que las seguí después de ver que me estaba calculando la cobertura ¡¡de los propios tests!!)
Para que no incluya nuestros tests en el informe de cobertura hay que:
- pulsar en el menú “Run / Coverage”,
- seleccionar la configuración de nuestro test,
- pulsar en la pestaña “Coverage”
- y desmarcar la carpeta correspondiente (en mi caso src/test/java porque uso Maven)
Como suponía, mi cobertura era del 100%.
De todos modos, no tener un plugin estable de Emma para Maven2 hace difícil el incorporarlo al proceso de integración continua (puesto que yo he optado por tenerlo todo con Maven2 y no usar Ant ni otros procesos añadidos). En cualquier caso, en cuanto pueda lo probaré a ver qué tal…
P.S.
Si alguien tiene interés, incluyo el enlace a una presentación sobre EclEmma de la EclipseCon 2008 que puede aclarar cómo funciona por dentro (incluidas referencias a OSGi).
La semana pasada SpringSource ofreció el webinar titulado “Introduction to Spring Dynamic Modules”. Ya está disponible en su versión grabada.
Lo siento, pero yo lo he intentado con Firefox y no he conseguido verlo, de modo que necesitaréis Internet Explorer y elegir la opción de “Redifusión” (porque la otra no funciona). Espero que SpringSource abandone esta plataforma Microsoft Live Meeting para sus webinars porque es seriamente mejorable.
Si alguien encuentra esta presentación en un formato más “portable”, por favor que me avise. Gracias.
Lo siento, pero yo lo he intentado con Firefox y no he conseguido verlo, de modo que necesitaréis Internet Explorer y elegir la opción de “Redifusión” (porque la otra no funciona). Espero que SpringSource abandone esta plataforma Microsoft Live Meeting para sus webinars porque es seriamente mejorable.
Si alguien encuentra esta presentación en un formato más “portable”, por favor que me avise. Gracias.
Los creadores del framework Spring acaban de cambiar su nombre de Interface21 a Spring Source. Como ellos mismos dicen en su web: “el nombre lo dice todo”.
Este cambio de nombre coincide con la liberación de la versión 2.5 del framework (que aparece con todos sus jars “osgificados”, es decir, listos para ser incorporados en un contenedor OSGi) y con la liberación de la primera “release candidate” de la versión 1.0 del proyecto Spring Dynamic Modules (aka Spring:OSGi).
Este cambio de nombre coincide con la liberación de la versión 2.5 del framework (que aparece con todos sus jars “osgificados”, es decir, listos para ser incorporados en un contenedor OSGi) y con la liberación de la primera “release candidate” de la versión 1.0 del proyecto Spring Dynamic Modules (aka Spring:OSGi).
Receta pax-runner
Nov 19
Si alguien quiere un ejemplo ya cocinado para ver lo sencillo que resulta esto de pax-runner, que haga lo siguiente:
- Descargar pax-runner y ponerlo en el PATH
- Asegurarnos que el valor de JAVA_HOME es correcto
- Ejecutar pax-run.sh o pax-run.bat
Veréis cómo “automágicamente” Pax Runner comienza a descargar un contenedor Apache Felix y lo ejecuta, dejando la consola de comandos lista para hacer, p.ej. “ps” y ver todos los bundles que ha descargado (apenas cinco) y que están en estado “ACTIVE”
C:\pax-runner-0.5.3\bin > pax-run
______ ________ __ __ / __ / / __ / / / / / / ___/ / __ / _\ \ _// / / / / / / _\ \/__/ /__/ /__/ /_/ /_/Pax Runner from OPS4J – http://www.ops4j.org
——————————————–-> Using config [classpath:META-INF/runner.properties]
-> Protocol [mvn] handler started
-> Protocol [wrap] handler started
-> Scanner for schema [scan-bundle] started
-> Scanner for schema [scan-dir] started
-> Scanner for schema [scan-file] started
-> Scanner for schema [scan-pom] started
-> Provision from [.!/*.jar]
-> Provision from [scan-dir:.!/*.jar]
-> Installing bundle [{location=file:/C:/pax-runner-0.5.3/bin/./pax-runner-0.5.
3.jar,startlevel=null,shouldStart=true}]
-> Downloading bundles…
-> Execution environment [J2SE-1.5]
-> Starting platform [Felix 1.0.1]. Runner has succesfully finished his job!Welcome to Felix.
=================ps
-> START LEVEL 6
ID State Level Name
[ 0] [Active ] [ 0] System Bundle (1.0.1)
[ 1] [Active ] [ 1] org.osgi.r4.compendium (1.0.0)
[ 2] [Active ] [ 1] Apache Felix Shell Service (1.0.0)
[ 3] [Active ] [ 1] Apache Felix Shell TUI (1.0.0)
[ 4] [Active ] [ 5] OPS4J Pax Runner – Core (0.5.3)
shutdown
-> ->
-> Shuting down platform…
-> Destroying platform process…
Si en vez de pax-run.sh (sin parámetros) ejecutamos pax-run.sh "--platform=equinox", lo que conseguimos es arrancar un contenedor Eclipse Equinox 3.2.1 y con un conjunto de bundles instalados ligeramente diferentes. (Por cierto, el comando para ver los bundles en la consola de Equinox es “ss” y para salir el comando es “close”).
Ejemplo OSGi en Eclipse
Oct 30
Como Eclipse está basado en Equinox (un contenedor OSGi) y además es mi IDE preferido, he comenzado a hacer mis primeros pinitos y quería compartir estos primeros pasos.
Run > Open Run Dialog > OSGi Framework > OSGi Framework
Pulsamos en “Duplicates the currently selected launch configuration”, renombramos “OSGi Framework (1)” a un nombre con el que nos encontremos más cómodos, p.ej. “OSGi Framework (Degesys)”
En la pestaña “Bundles” veremos dos grupos de bundles (todos seleccionados): Workspace y Target Platform. Deseleccionemos “Target Platform”.
File > New Project > Plug-in Project
Project Name: hellobundle
This plug-in is targeted to run with: an OSGi framework (yo he elegido “standard”)
Next , Next
Create a plug-in using one of the templates: Hello OSGi Bundle
Next , Finish
Seleccionamos la raiz de nuestro proyecto recién creado “hellobundle” y pulsamos “Alt+Shift+X, O” y seleccionamos nuestra configuración “OSGi Framework (Degesys)”. Se abrirá la consola y aparecerá un mensaje como el siguiente:
osgi> Hello World!!
Ponemos el cursor en la consola y escribimos “close”.
¡¡Ya hemos ejecutado nuestro primer bundle!!
PAX : OSGi made easy
Oct 19
Estas últimas semanas tengo bastante abandonado este blog porque estamos comenzando un proyecto muy bonito a la vez que difícil (al menos para mi): estamos valorando la posibilidad de desarrollar nuestro framework SOA basándolo en OSGi y SCA. Para ello, mi compañero Sixto está montando Newton con Spring:OSGi y todo el entorno de desarrollo que nos permita construir y desplegar nuestras aplicaciones en este nuevo entorno. Y en este orden de cosas, hemos visto que hay un par de herramientas muy nuevas que nos van a permitir acelerar muchas tareas: se trata de pax-runner y pax-construct.
Aquellos que tengáis algo que ver con OSGi, no perdáis ni un momento en echar un vistazo a este proyecto PAX (dentro de otro proyecto más genérico, OPS4J) porque merece la pena: puedes configurar tu entorno de ejecución y lanzar el contenedor de tu elección (por defecto es Apache Felix) con extrema facilidad (un fichero txt). Y muy similar es el proceso de construir una aplicación, incluso puedes “osgificar” un jar sin más que ejecutar pax-construct.
Este proyecto es un gran reto para mi, pero también por eso mismo está siendo tan apasionante.
Aquellos que tengáis algo que ver con OSGi, no perdáis ni un momento en echar un vistazo a este proyecto PAX (dentro de otro proyecto más genérico, OPS4J) porque merece la pena: puedes configurar tu entorno de ejecución y lanzar el contenedor de tu elección (por defecto es Apache Felix) con extrema facilidad (un fichero txt). Y muy similar es el proceso de construir una aplicación, incluso puedes “osgificar” un jar sin más que ejecutar pax-construct.
Este proyecto es un gran reto para mi, pero también por eso mismo está siendo tan apasionante.
Powered by ScribeFire.
SCA
Aug 4
He estado leyendo el libro “Service-Oriented Architecture (SOA): Concepts, Technology, and Design” de Thomas Erl y he llegado al convencimiento (entre otras muchas cosas) de que para hacer “verdadero SOA” son necesarios:
- una infraestructura que haga posible la localización y la colaboración (síncrona o asíncrona) entre servicios
- buscar un modelo a partir del cuál poder diseñar los servicios como componentes estándar (independientemente de la infraestructura en la que se desplieguen)
Respecto al segundo punto, leyendo, leyendo y navegando, navegando, he llegado a una serie de artículos de IBM sobre integración usando SOA. Tras leer varios de ellos (reconozco que no todos), he visto que SCA sería una posible solución. Para los que quieran una introducción rápida a SCA, creo que es mejor acudir a la fuente directamente. En la web de OpenSOA se define el modelo en UML, por si eso ayuda en algo a su comprensión. Lo mejor de todo es que ya hay incluso especificación para API Java y ejemplos de cómo usar JAX-WS para implementar un componente “SCA-enabled”.
SCA es una propuesta OASIS (por lo que se garantiza que Microsoft también participa y que, por tanto, está garantizado el éxito en la interoperabilidad). A mí, sin embargo, me queda la duda (y me gustaría mucho que alguien me lo explicara) sobre qué diferencia hay entre SCA y JBI y entre SCA y WSIT. Lo que pasa es que la gente de Glassfish parece un poco escéptica al respecto de adoptar SCA (al menos tal cual está ahora definida). Ya le pregunté “in person” a Eduard Pelegrí y me contestó que él veía más factible una convergencia a medio/largo plazo de JBI (Sun) y SCA (IBM).
De todos modos, vamos a ver, que yo sepa… SOA no sólo se puede implementar con .NET o con J2EE… 
