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.

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 :