Eclipse Equinox and Maven

I finally found a maven repository hosting recent versions of Eclipse Equinox framework : thanks Sonatype for providing it !

You’ll have to add this repository to your pom.xml :

<repository>
	<id>org.sonatype.forge</id>
	Sonatype Forge
	<url>http://repository.sonatype.org/content/groups/forge/</url>
</repository>

To reference Equinox, you’ll need to add this dependency :

<dependency>
	<groupid>org.eclipse.equinox</groupid>
	<artifactid>org.eclipse.osgi</artifactid>
	<version>3.5.1</version>
</dependency>

Now that’s cool ! I can now describe the whole target platform as a pom.xml + .target file, no more need to embed equinox’s jar 🙂

Invalid property ‘cacheTarget’ of bean class [org.springframework.osgi.service.exporter.support.OsgiServiceFactoryBean]

Okay, so I’ve lost so much time on this incredibly stupid issue, and Google wasn’t of much help that I thought I’d blog about it as a memo for myself and for others.

here’s the setup : I’ve created an osgi bundle (using PDE new plugin wizard), created a class (implementing an interface) and tried to export it as an OSGi service using Spring DM.

I used Spring IDE tooling to generate my bundle’s context xml files (I tend to follow the Spring DM best practices in separating the bundle’s context in 2 xml files, one for the regular Spring setup, the other for OSGi interactions).

Anyway, the first xml file simply declares a Spring bean :

Préparation de l’environnement : configuration de Jetty

Dans ce triosième volet de la série parlant de l’utilisation d’OSGi côté serveur, je vais présenter comment on peut configurer jetty.

Par défaut, Jetty utilise le port 8080, ce qui peut poser problème quand on a un autre serveur sur ce port.

Pour résoudre celà, on va créer un fragment qui contient les fichiers de configuration de Jetty. J’avais présenté en détail comment céer un fragment dans le billet précédent : « Préparation de l’environnement : configuration de log4j »

Préparation de l’environnement : configuration de log4j

Dans ce second volet de la série de l’utilisation d’OSGi côté serveur, je vais présenter comment on peut configurer log4j pour qu’on puisse voir les logs générés par les différents bundles dans la console d’Eclipse.

Dans un programme Java ordianire, log4j cherche un fichier log4j.properties (ou xml) dans le racine du classpath. Or, dans un conteneur OSGi, la notion de classpath est différente. On n’a plus de classpath unique par application, mais plutôt un classpath séparé par bundle.

Sortie de Spring DM Server 2.0 M1

SpringSource frappe fort : ils viennent d’annoncer la sortie du premier milestone de DM Server 2.0.
J’ai pas vu le coup venir : rien qu’Hier, Rob Harrop a publié un billet où il parle de leurs plans pour Spring DM Server 2, et e lendemain, ils publient un premier milestone …

Voici rapidement les quelques nouveautés apportées par cette version :

[Suite:]

Utilisation de Scrum comme processus de développement (c’est bien comme ça qu’on l’appèlle hein ?)
Premier support de la notion de plans : pensez les features d’Eclipse. Je tiens à préciser que j’avais abandonné DM Server 1 à cause de la notion de PAR, une sorte de regroupement de bundles dans un archive, ce qui va tout simplement à l’encontre de l’essence de l’OSGi. Avec les plans, un simple descripteur xml d’un ensemble de bundles, je crois qu’une ré-évaluation des choses s’impose
Premier support de la notion de cloning : j’ai pas encore approfondi ma lecture la dessus, je peux donc pas présenter ce que c’est.

Voici maintenant quelques liens clés :
Annonce
Téléchargement
Release notes
Doc : Getting Started, User Guide, Dev Guide

Billet original publié sur les blogs de developpez.com…

—-

Disponibilité du public Draft de la plateforme OSGi 4.2

Le public draft des spécifications de la prochaine version d’OSGi, la 4.2, vient d’être rendu public.

J’avais présenté (brièvement) dans un autre billet les quelques nouveautés qui seront apportées par cette version.

Le public draft des specs du core
Le public draft des specs du compendium (services extra)

Billet original publié sur les blogs de developpez.com…

—-

Préparation de l’environnement : la target platform

Ce billet est le premier d’une série (que j’espère finir pour une fois) de billets à propos de l’utilisation d’OSGi du côté serveur.
L’utilisation la plus populaire d’OSGi est plus du côté client, avec Eclipse qui l’utilise comme noyeau et base de son architecture de plugins, ainsi que dans le monde de l’embarqué.

Dans ce premier billet, je vais présenter l’étape de préparation de l’environnement de développement,et plus particulièrement la notation de Target Platform.

[Suite:]

1. Présentation

Il s’agit ici de définir l’ensemble initial de plugins qui va constituer l’environnement d’exécution de notre serveur.

Il nous faut aussi configurer Eclipse pour qu’il reconnaisse et travaille sur cet ensemble de plugins.
Ca permettrait d’une part de limiter le nombre de choix présentés dans divers endroits (lors de sélection de plugins requis et des packages importés, des plugins à inclure dans une configuration d’exécution, etc.) mais aussi pour éviter une dépendance accidentelle à un plugin non désiré (je pense notamment aux plugins d’Eclipse par exemple)

2. Vue d’ensemble

La target platform sera constituée de :

• Equinox : C’est le coeur du serveur. Il implémente les spécifications OSGi et servira comme conteneur qui charge et gère le cycle de vie des autres plugins
• Spring Dynamic Modules : C’est une sorte de pont entre le monde OSGi (registre des services) et le monde de Spring (application context). De plus, Spring DM permet de faire tourner des applications Web Java ordinaires (Servlets, JSPs, etc.) dans un conteneur OSGi (OSGi offre un support basique pour le web à travers HttpService, mais c’est très limité)
• Spring : Il est là car tout d’abord il est requis par Spring DM, mais aussi pour son moteur IoC ainsi que les abstractions qu’il offre au dessus de plusieurs technologies Java (JDBC et Remoting entre autres)
• Jetty : Comme énoncé plus tôt, le HttpService d’OSGi est très limité parapport à la puissance dont on dispose dans une application web Java ordinaire. J’ai donc inclus Jetty dans la configuration de base de notre serveur pour avoir toute la puissance requise sous la main
• Quelques autre dépendances, comme des librairies de logging

Notez qu’il est tout à fait possible (et très simple) d’utiliser Tomcat à la place de Jetty. Ceci revient juste à remplacer les jars de Jetty par ceux de Tomcat.

3. Récupération des fichiers nécessaires

Il va nous falloir télécharger plusieurs packages pour retrouver les jars nécessaires.

• Spring DM : récupérable à cette adresse (pour cet article, j’ai utilisé Spring DM 1.2 M2)
• Spring Framework : récupérable à cette adresse (pour cet article, j’ai utilisé Spring Framework 2.5.6)

Après avoir extrait les archives de Spring et de Spring DM, Créez quelque part sur votre disque un dossier qui servira à rassembler les jars de la target platform, par exemple ” server-springdm-1.2.0.m2-spring-2.5.6-jetty ” dans mon cas.

Généralement, je crée la target platform en tant que projet (simple) dans mon worksapce Eclipse, histoire de pouvoir le versionner sur SVN par exemple, mais ce n’est pas requis.

Copiez les fichiers suivants depuis le dossier où vous avez extrait Spring DM vers le dossier de la target platform:

• spring-osgi-1.2.0-m2/dist/spring-osgi-core-1.2.0-m2.jar
• spring-osgi-1.2.0-m2/dist/spring-osgi-extender-1.2.0-m2.jar
• spring-osgi-1.2.0-m2/dist/spring-osgi-io-1.2.0-m2.jar
• spring-osgi-1.2.0-m2/dist/spring-osgi-web-1.2.0-m2.jar
• spring-osgi-1.2.0-m2/dist/spring-osgi-web-extender-1.2.0-m2.jar

• spring-osgi-1.2.0-m2/lib/com.springsource.net.sf.cglib-2.1.3.jar
• spring-osgi-1.2.0-m2/lib/com.springsource.org.aopalliance-1.0.0.jar
• spring-osgi-1.2.0-m2/lib/com.springsource.slf4j.api-1.5.0.jar
• spring-osgi-1.2.0-m2/lib/com.springsource.slf4j.log4j-1.5.0.jar
• spring-osgi-1.2.0-m2/lib/com.springsource.slf4j.org.apache.commons.logging-1.5.0.jar
• spring-osgi-1.2.0-m2/lib/jetty-6.1.9.jar
• spring-osgi-1.2.0-m2/lib/jetty.start.osgi-1.0.0.jar
• spring-osgi-1.2.0-m2/lib/jetty-util-6.1.9.jar
• spring-osgi-1.2.0-m2/lib/jetty.web.extender.fragment.osgi-1.0.1.jar
• spring-osgi-1.2.0-m2/lib/log4j.osgi-1.2.15-SNAPSHOT.jar
• spring-osgi-1.2.0-m2/lib/org.eclipse.osgi-3.2.2.jar
• spring-osgi-1.2.0-m2/lib/servlet-api.osgi-2.5-SNAPSHOT.jar

• spring-framework-2.5.6/dist/modules/spring-aop.jar
• spring-framework-2.5.6/dist/modules/spring-beans.jar
• spring-framework-2.5.6/dist/modules/spring-context.jar
• spring-framework-2.5.6/dist/modules/spring-core.jar
• spring-framework-2.5.6/dist/modules/spring-jdbc.jar
• spring-framework-2.5.6/dist/modules/spring-tx.jar
• spring-framework-2.5.6/dist/modules/spring-web.jar
• spring-framework-2.5.6/dist/modules/spring-webmvc.jar

Pour vous simplifier la tache, vous pouvez télécharger cet archive zip (5 Mo) qui contient la target platform décrite plus haut)

4. Configuration d’Eclipse

Dans Eclipse, allez au menu Window -> Preferences et localisez le noeud “Plug-in Development/Target Platform”

Cliquez sur “Browse”, localiser le dossier de la target platform et validez.

Il nous faut maintenant créer une configuration de lancement qui lance notre serveur.

Faites un clic sur le petit flêche orienté vers le bas du bouton Run et sélectionnez “Run configurations”

Sélectionnez le noeud “OSGi Framework”, puis clic droit et “New”

Saisissez un nom pour cette configuration, “serveur” par exemple.
Par défaut, tous les plugins de la target platform sont cochés. Faites le si ce n’est pas le cas.

Assurez vous aussi que “Default start level” est positionné à 4 et que “Default-Autostart” est à true

Il faut maintenant modifer le start level des deux extenders de Spring DM (org.springframework.osgi.extender et org.springframework.osgi.web.extender) pour les mettre à 5

Cliquez sur “Apply” pour valider.

5. Test

Cliquez sur le bouton “Run”. La console devrait afficher :

Et si vous tapez l’adresse “http://localhost:8080/” dans un navigateur, vous devriez avoir :

Billet original publié sur les blogs de developpez.com…

—-

Nouvelle registre pour les entêtes OSGi

OSGi Allaince vient de rendre disponible une registre des entêtes utilisés dans le fichier MANIFEST.MF, et ce pour essayer d’éviter des collisions de noms.

C’est accessible par ici :

http://www.osgi.org/Specifications/ReferenceHeaders

On notera que cette liste contient les entêtes standard d’OSGi, ceux de BnD (sous ne nom aQute dans la liste) mais aussi ceux introduits par Spring Source DM Server

Billet original publié sur les blogs de developpez.com…

—-

Sortie du second Milestone de Spring Dynamic

Spring Dynamic Modules permet de réconcilier le modèle de développement de Spring Framework avec celui d’OSGi, et ce via l’ajout d’un namespace osgi utilisable dans les fichiers de configuration de Spring qui permettent entre autre d’importer un service OSGi en tant que Bean Spring ainsi que d’exporter un Bean Spring en tant que service OSGi.

Aujourdhui, le second milestone de Spring dynamic Modules (spring DM) est sorti, apportant comme nouveautés :

[Suite:]

• Passage à Spring 2.5.6
• Mise à jour des dépendances ves les modules Spring pour refléter les nouveaux noms de ceux-ci
• Support des services compendium via le namespace compendium
• etc.

Les liens qu’il vous faut :

Télécharger
Documentation
FAQ
Changelog

Billet original publié sur les blogs de developpez.com…

—-

Bug bizarroïde, ou OSGi quand tu nous tiens …

Aujourd’hui, j’ai failli m’arracher les cheveux à cause d’un bug bizarre dans l’application sur laquelle on travaille (une application client/serveur à base d’Eclipse RCP côté client et Tomcat tournant comme service dans Equinox côté serveur avec Spring DM).

Pour expliquer la chose, on utilise un super petit plug-in développé par Martin Lippert appelé Spring Extension Factory. Ce plugin permet de faire en sorte que les vues et éditeurs Eclipse peuvent être déclarés dans l’applicationContext du plug-in (en tant que Spring beans quoi) ce qui permet de profiter de la DI par exemple. Plus précisément, dans notre cas ceci revient à injecter les proxies des services distants (sur le serveur) qui seront invoqués par remoting (via Hessian pour le moment, mais c’est interchangeable grâce à l’abstraction Spring du Remoting).

ça marchait impec jusqu’à aujourd’hui, où on avait besoin d’utiliser une vue définie dans un plug-in A dans une perspective définie par un plug-in B. Et hop, l’injection de dépendances ne marchait plus (un NPE à l’accès à une des dépendances)

[Suite:]

bon, heureusement que je me suis vite aperçu (enfin, plus d’une heure) que si j’utilisais les versions plus récentes de Spring Extension Factory (1.0.3 au lieu de 1.0.1) et de Spring DM (1.1.2 au lieu de 1.1.0), le problème n’est plus … Ouf !

Peut être que c’était Spring DM qui n’utilisait pas le classloader correct :

* fixed usage of incorrect class loader for imported services with client thread context class loader management

(tiré du changelog de la 1.1.2)

Mais bon, comme ça marche là, je vais pas bloquer la dessus

Billet original publié sur les blogs de developpez.com…

—-