Il s’agit de controler l’inclusion de fichiers de configuration Spring via une property passé à la JVM :

<import resource="${env}-infrastructure.xml"/>

puis passer l’argument :

-Denv=prod

ou encore

-Denv=dev

Par exemple, selon que l’on est en mode développement ou en mode production.

J’adore ! surtout pour l’inclusion des fichiers .properties

Le billet qui présente cette technique.

J’avais utilisé Yourkit Java Profiler 8.0.10 pour ce faire. Quelques notes :

– Il est payant. J’ai utilisé la version complète d’essai utilisable pour 15 jours. Un point pour Yourkit : rien de pire qu’une version démo bridée en fonctionnalités.
– Il dispose d’intégration avec Eclipse. Un autre point pour.

– Il a fonctionné sans le moindre accroc et du premier coup. 10 points pour, à comparer avec TPTP (le profiler standrd d’Eclipse) que je suis jamais arrivé à faire fonctionner sur Linux.
– Plus fort encore, Yourkit supporte les configurations de lancement OSGi. 20 points pour en ce qui me concerne. C’était un showstopper majeur, car peu d’aurtes profilers supportent ça. J’ai pas réussi à utiliser VisualVM pour ça par exemple.
– Il est léger, du moins dans le mode «Sampling», car pour le «Tracing», c’est une autre histoire. D’ailleurs, je sui sun peu étonné par la lourdeur du mode «Tracing» : ça n’ajoute parapport au «Sampling» que le nombre d’invoquations d’une méthode. Je trouve bizarre que ceci soit aussi couteux.

Je trouve pas encore de défauts, ce qui est … ennuyeux ? embetant ? :)) C’est pas mon genre de chanter les louanges d’un produit commercial (ce blog ne fait pas de la pub), mais parfois, à moins de ne pas poster le billet, on trouve pas quoi critiquer
Bref, je vais continuer de tester la chose dans la prochaine semaine et je partagerais mes impressions.

Ah, et un dernier point :

Early optimization is the root of all evil

Après chaque session de profiling, ce percepte ne fait que se confirmer. Depuis des semaines déjà je me disais tout le temps que je devrais introduire du caching par ici et par là, que ce truc là allait exploser la base de données, etc. etc.

Mais après cette séance de profiling, c’est reglé : je peux dormir tranquile et ne plus penser à ces histoires d’optimisation. Pas dans les semaines qui viennent en tout cas

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 »

Créez donc un fragment en utilisant l’assistant offert par PDE en utilisant « sse.jetty.config » comme nom et en sélectionnant « org.springframework.osgi.jetty.start.osgi » comme host.

Dans ce fragment, créez un dossier « etc » à la racine du projet avec un fichier jetty.xml dedans dont voici le contenu :

<?xml version="1.0"?> 

<!DOCTYPE Configure PUBLIC "-//Mort Bay Consulting//DTD Configure//EN" "http://jetty.mortbay.org/configure.dtd"> 

 

<!-- =============================================================== --> 

<!-- Configure the Jetty Server  (OSGi specific)                     --> 

<!--                                                                 --> 

<!-- Documentation of this file format can be found at:              --> 

<!-- http://docs.codehaus.org/display/JETTY/jetty.xml                --> 

<!--                                                                 --> 

<!-- =============================================================== --> 

 

 

<Configure id="Server" class="org.mortbay.jetty.Server"> 

 

    <!-- =========================================================== --> 

    <!-- Server Thread Pool                                          --> 

    <!-- =========================================================== --> 

    <Set name="ThreadPool"> 

      <!-- Default bounded blocking threadpool  

      --> 

      <New class="org.mortbay.thread.BoundedThreadPool"> 

        <Set name="minThreads">10</Set> 

        <Set name="maxThreads">250</Set> 

        <Set name="lowThreads">25</Set> 

      </New> 

 

      <!-- Optional Java 5 bounded threadpool with job queue  

      <New class="org.mortbay.thread.concurrent.ThreadPool"> 

        <Set name="corePoolSize">250</Set> 

        <Set name="maximumPoolSize">250</Set> 

      </New> 

      --> 

    </Set> 

 

 

 

    <!-- =========================================================== --> 

    <!-- Set connectors                                              --> 

    <!-- =========================================================== --> 

    <!-- One of each type!                                           --> 

    <!-- =========================================================== --> 

 

    <!-- Use this connector for many frequently idle connections 

         and for threadless continuations. 

    -->     

    <Call name="addConnector"> 

      <Arg> 

          <New class="org.mortbay.jetty.nio.SelectChannelConnector"> 

            <Set name="host"><SystemProperty name="jetty.host" /></Set> 

            <Set name="port"><SystemProperty name="jetty.port" default="9090"/></Set> 

            <Set name="maxIdleTime">30000</Set> 

            <Set name="Acceptors">2</Set> 

            <Set name="statsOn">false</Set> 

            <Set name="confidentialPort">9443</Set> 

      <Set name="lowResourcesConnections">5000</Set> 

      <Set name="lowResourcesMaxIdleTime">5000</Set> 

          </New> 

      </Arg> 

    </Call> 

 

    <!-- Use this connector if NIO is not available.  

    <Call name="addConnector"> 

      <Arg> 

          <New class="org.mortbay.jetty.bio.SocketConnector"> 

            <Set name="port">8081</Set> 

            <Set name="maxIdleTime">50000</Set> 

            <Set name="lowResourceMaxIdleTime">1500</Set> 

          </New> 

      </Arg> 

    </Call> 

    --> 

 

    <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> 

    <!-- To add a HTTPS SSL listener                                     --> 

    <!-- see jetty-ssl.xml to add an ssl connector. use                  --> 

    <!-- java -jar start.jar etc/jetty.xml etc/jetty-ssl.xml             --> 

    <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> 

     

    <!-- =========================================================== --> 

    <!-- Set up global session ID manager                            --> 

    <!-- =========================================================== --> 

    <!-- 

    <Set name="sessionIdManager"> 

      <New class="org.mortbay.jetty.servlet.HashSessionIdManager"> 

        <Set name="workerName">node1</Set> 

      </New> 

    </Set> 

    --> 

 

    <!-- =========================================================== --> 

    <!-- Set handler Collection Structure                            -->  

    <!-- =========================================================== --> 

    <Set name="handler"> 

      <New id="Handlers" class="org.mortbay.jetty.handler.HandlerCollection"> 

        <Set name="handlers"> 

         <Array type="org.mortbay.jetty.Handler"> 

           <Item> 

             <New id="Contexts" class="org.mortbay.jetty.handler.ContextHandlerCollection"/> 

           </Item> 

           <Item> 

             <New id="DefaultHandler" class="org.mortbay.jetty.handler.DefaultHandler"/> 

           </Item> 

           <Item> 

             <New id="RequestLog" class="org.mortbay.jetty.handler.RequestLogHandler"/> 

           </Item> 

         </Array> 

        </Set> 

      </New> 

    </Set> 

     

    <!-- =========================================================== --> 

    <!-- Configure the context deployer                              --> 

    <!-- A context deployer will deploy contexts described in        --> 

    <!-- configuration files discovered in a directory.              --> 

    <!-- The configuration directory can be scanned for hot          --> 

    <!-- deployments at the configured scanInterval.                 --> 

    <!--                                                             --> 

    <!-- This deployer is configured to deploy contexts configured   --> 

    <!-- in the $JETTY_HOME/contexts directory                       --> 

    <!--                                                             --> 

    <!-- =========================================================== --> 

     

    <!-- 

  <Call name="addLifeCycle"> 

      <Arg> 

        <New class="org.mortbay.jetty.deployer.ContextDeployer"> 

          <Set name="contexts"><Ref id="Contexts"/></Set> 

          <Set name="configurationDir"><SystemProperty name="jetty.home" default="."/>/contexts</Set> 

          <Set name="scanInterval">1</Set> 

        </New> 

      </Arg> 

    </Call> 

  --> 

    <!-- =========================================================== --> 

    <!-- Configure the webapp deployer.                              --> 

    <!-- A webapp  deployer will deploy standard webapps discovered  --> 

    <!-- in a directory at startup, without the need for additional  --> 

    <!-- configuration files.    It does not support hot deploy or   --> 

    <!-- non standard contexts (see ContextDeployer above).          --> 

    <!--                                                             --> 

    <!-- This deployer is configured to deploy webapps from the      --> 

    <!-- $JETTY_HOME/webapps directory                               --> 

    <!--                                                             --> 

    <!-- Normally only one type of deployer need be used.            --> 

    <!--                                                             --> 

    <!-- =========================================================== --> 

    <!-- 

    <Call name="addLifeCycle"> 

      <Arg> 

        <New class="org.mortbay.jetty.deployer.WebAppDeployer"> 

          <Set name="contexts"><Ref id="Contexts"/></Set> 

          <Set name="webAppDir"><SystemProperty name="jetty.home" default="."/>/webapps</Set> 

    <Set name="parentLoaderPriority">false</Set> 

    <Set name="extract">true</Set> 

    <Set name="allowDuplicates">false</Set> 

          <Set name="defaultsDescriptor"><SystemProperty name="jetty.home" default="."/>/etc/webdefault.xml</Set> 

        </New> 

      </Arg> 

    </Call> 

    --> 

 

    <!-- =========================================================== --> 

    <!-- Configure Authentication Realms                             --> 

    <!-- Realms may be configured for the entire server here, or     --> 

    <!-- they can be configured for a specific web app in a context  --> 

    <!-- configuration (see $(jetty.home)/contexts/test.xml for an   --> 

    <!-- example).                                                   --> 

    <!-- =========================================================== --> 

    <!-- 

    <Set name="UserRealms"> 

      <Array type="org.mortbay.jetty.security.UserRealm"> 

        <Item> 

          <New class="org.mortbay.jetty.security.HashUserRealm"> 

            <Set name="name">Test Realm</Set> 

            <Set name="config"><SystemProperty name="jetty.home" default="."/>/etc/realm.properties</Set> 

            <Set name="refreshInterval">0</Set> 

          </New> 

        </Item> 

      </Array> 

    </Set> 

    --> 

 

    <!-- =========================================================== --> 

    <!-- Configure Request Log                                       --> 

    <!-- Request logs  may be configured for the entire server here, --> 

    <!-- or they can be configured for a specific web app in a       --> 

    <!-- contexts configuration (see $(jetty.home)/contexts/test.xml --> 

    <!-- for an example).                                            --> 

    <!-- =========================================================== --> 

    <Ref id="RequestLog"> 

      <Set name="requestLog"> 

        <New id="RequestLogImpl" class="org.mortbay.jetty.NCSARequestLog"> 

          <Set name="filename"><SystemProperty name="jetty.logs" default="./logs"/>/yyyy_mm_dd.request.log</Set> 

          <Set name="filenameDateFormat">yyyy_MM_dd</Set> 

          <Set name="retainDays">90</Set> 

          <Set name="append">true</Set> 

          <Set name="extended">true</Set> 

          <Set name="logCookies">false</Set> 

          <Set name="LogTimeZone">GMT</Set> 

        </New> 

      </Set> 

    </Ref> 

     

    <New id="ServerLog" class="java.io.PrintStream"> 

      <Arg> 

        <New class="org.mortbay.util.RolloverFileOutputStream"> 

          <Arg><SystemProperty name="jetty.logs" default="./logs"/>/yyyy_mm_dd.stderrout.log</Arg> 

          <Arg type="boolean">false</Arg> 

          <Arg type="int">90</Arg> 

          <Arg><Call class="java.util.TimeZone" name="getTimeZone"><Arg>GMT</Arg></Call></Arg> 

          <Get id="ServerLogName" name="datedFilename"/> 

        </New> 

      </Arg> 

    </New> 

 

    <!-- <Call class="org.mortbay.log.Log" name="info"><Arg>Redirecting stderr/stdout to <Ref id="ServerLogName"/></Arg></Call> 

    <Call class="java.lang.System" name="setErr"><Arg><Ref id="ServerLog"/></Arg></Call> 

    <Call class="java.lang.System" name="setOut"><Arg><Ref id="ServerLog"/></Arg></Call> 

     --> 

 

    <!-- =========================================================== --> 

    <!-- extra options                                               --> 

    <!-- =========================================================== --> 

    <Set name="stopAtShutdown">true</Set> 

    <Set name="sendServerVersion">true</Set> 

    <Set name="sendDateHeader">true</Set> 

    <Set name="gracefulShutdown">1000</Set> 

 

</Configure>

Notez surtout que j’ai utilisé 9090 comme valeur pour le port, au lieu du 8080.

Voilà. Il suffit ensuite d’ajouter ce fragment à votre configuration de lancement pour que Jetty utilise le port 9090.

La version courte

Ne jamais utiliser <wicket:container> avec l’ajax !!!!

La version longue

J’ai mis dans le html :

<wicket:container wicket:id=details"></wicket:container>

Côté Java, j’y avais associé un EmptyPanel (initialement) :

add(new EmptyPanel("details").setOutputMarkupId(true));

Et je voualis mettre à jour son contenu via ajax suite à un clic sur un autre élément de la page :

PersonDetailsPanel personDetailsPanel = new PersonDetailsPanel( 

    "details", new Model<Person>(p)); 

personDetailsPanel.setOutputMarkupId(true); 

addOrReplace(personDetailsPanel); 

if (target != null) { 

  target.addComponent(new PersonDetailsPanel( 

      "details", new Model<Person>(p)).setOutputMarkupId(true)); 

  

}

A l’exécution, j’obtiens un comportement bizarre : Au premier clic, ça met à jour la page html, mais les clics suivants bien que traités côté serveur ne mettent pas à jour le panel.
D’autres fois, même le premier clic ne fonctionnait pas.

Pour finir, je tiens à adresser mes remerciements les plus sincères à la console «Ajax Debug» de Wicket qui m’a permis de résoudre ce problème ! :))

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.

Pour résoudre celà, on utilise la notion de fragments. Un fragment est un bundle spécial, qui à l’exécution (à la pahse de resolution), se trouve attaché et mergé dans un autre bundle hôte. Après, il sera traités exactement comme faisant partie du bundle hôte.

Dans le cas précis de ce billet, on va créer un fragment avec le bundle de log4j comme hôte, et on va placer le fichier log4j.properties dans ce fragment.
Ainsi, quand log4j va rechercher un fichier de configuration dans la racind du classpath (le classpath de son bundle), il trouvera et utilisera ce fichier

Eclipse PDE fournit un assistant pour la création d’un fragment. Faites « New > Other > Plug-In Developement > Fragment Project » :

Saissisez un nom pour ce fragment, « ssosgi.log4j.config » dans mon cas par exemple et cochez l’option « an OSGi framework » sous « Target Platform »:

Dans la page suivante, utilisez le bouton « Browse » pour sélectionnez le bundle de log4j comme Host Plig-In

Et validez.

Dans le projet, créez un fichier log4.properties avec le contenu suivant :

log4j.rootLogger=info, con, file 

log4j.appender.con=org.apache.log4j.ConsoleAppender 

log4j.appender.con.layout=org.apache.log4j.PatternLayout 

log4j.appender.con.layout.ConversionPattern=%-4r [%t] %-5p %c %x - %m%n 

 

log4j.appender.file=org.apache.log4j.FileAppender 

log4j.appender.file.layout=org.apache.log4j.PatternLayout 

log4j.appender.file.layout.ConversionPattern=%5p [%t] (%F\:%L) - %m%n 

log4j.appender.file.File=/home/djo/ssosgi.log 

log4j.appender.file.append=false

Notez que vous pouvez personnaliser la configuration pour l’adapter à vos besoins. Pensez notamment à changer le nom du fichier de log («/home/djo/ssosgi.log» dans mon cas).

Il faut ensuite ajouter ce fragment à la configuration de lancement. Allez dans la fnêtre de configuration de celle-ci (comme décrit dans le billet précédent) et cochez le fragment qu’on vient de créer dans la liste des plugins à inclure.

Appliquez et lancer la configuration. Vous devriez avoir un log plus détaillé dans la console d’Eclipse :

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

=> 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

http://vikasrao.wordpress.com/2009/02/19/scala-nature-in-eclipse/

En gros, avec le nouveau plugin Scala, bien qu’il soit beacoup plus simple d’ajouter une nature Scala à un projet Java (clic droit, « Scala Tools> Add Scala Nature », ceci ne marche pas avec un projet de type « Dynamic web project » … exit donc ça ou ça

=> https://lampsvn.epfl.ch/trac/scala/ticket/1744

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)

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 :

1. Vue d’ensemble

L’application que je vais utiliser comme exemple est simpliste : elle ne sert qu’à afficher une liste de personnes (peu importe comment cette liste est retrouvée) dans une page web.

Seulement, histoire de faire propre, je vais découper cette application en 4 bundles:

1. domain: C’est un bundle qui définit les objets métier (un seul dans notre cas: Person)
2. service-api: C’est un bundle qui définit les interfaces (contrats) de la couche métier
3. service-impl: C’est un bundle qui définit les implémentations des services mais aussi les exporte en tant que services OSGi qui seront consommés par le dernier bundle.
4. web-frontend: C’est un bundle qui définit le front-end web de l’application et qui consomme les services exposés par service-impl

N.B.: Je suppose tout au long de ce billet que le serveur S2AP ainsi que le tooling Eclipse correspondant est déjà en place comme je le montre ici.

2. Créer le bundle domain

Dans Eclipse, lancez le wizard « New Bundle Project » :

Saisissez un nom parlant pour ce bundle (djo.s2ap.demo.domain pour moi) et cliquez sur Next.
Là, et c’est une nouveauté dans le tooling S2AP pour Eclipse (sur une suggestion de ma part, merci à Christian Dupuis qui l’a implémenté), il est possible de choisir le type du bundle (None ou Web) :

Choissisez None et validez.
Créer un package dans le dossier src (j’utilise habituellement le nom du projet comme package de base), et créez une classe Person (forcément, mon type de données préféré )

package djo.s2ap.demo.domain; 

 

public class Person { 

  private String name; 

  private int age; 

 

  public Person(String name, int age) { 

    super(); 

    this.name = name; 

    this.age = age; 

  } 

 

  public String getName() { 

    return name; 

  } 

 

  public void setName(String name) { 

    this.name = name; 

  } 

 

  public int getAge() { 

    return age; 

  } 

 

  public void setAge(int age) { 

    this.age = age; 

  } 

 

}

Je vais me contenter de cette classe comme mon domaine.

Il faut ensuite exporter le package de cette classe pour qu’elle soit visible aux autres bundles.
Pour ce faire, localisez le fichier src/META-INF/MANIFEST.MF et double-cliquez la dessus, ce qui ouvre l’éditeur de manifest de STS (encore une fonctionnalité proposé par l’auteur de ce billet (moi) et implémentée par l’equipe STS (re-merci) !).
Dans l’éditeur multi-pages qui se lance, localisez la page « Runtime » et activer la.
A gauche, vous trouverez une liste présentant les packages exportés par le bundle en question. Cliquez sur le bouton « Add » et dans la fenêtre qui s’affiche, sélectionnez l’unique package présent (djo.s2ap.demo.domain).

Sinon, il est toujours possible de travailler directement sur le manifest en utilisant le contenu suivant:

Manifest-Version: 1.0 

Bundle-Version: 1.0.0 

Bundle-Name: Domain Bundle 

Bundle-ManifestVersion: 2 

Bundle-SymbolicName: djo.s2ap.demo.domain 

Export-Package: djo.s2ap.demo.domain

Voilà, le premier bundle est prêt.

3. Créer le bundle service-api

Comme énoncé plus haut, ce bundle va juste définir les contrats des services (sous forme d’interfaces). C’est LE pattern OSGi à mon avis, i.e. séparer l’interface de l’implémentation dans des bundles différents, histoire de pouvoir changer (mettre à jour, corriger des bugs, peaufiner, etc.) l’implémentation séparément de son interface mais aussi pour éviter que le consommateur d’un service ne dépende de son implémentation.

Dans le cadre de cette application exemple, je vais me contenter d’un seul service exposant une seule fonctionnalité qui est de récupérer une liste de personnes.

Commencez par créer un autre bundle nommé « djo.s2ap.demo.service.api » dans mon cas (même procédure que pour le bundle domain, choisissez « None » comme personality).
Ce bundle aura besoin de voir la classe Person du bundle domain.
Or, justement, j’ai exporté le package contenant cette classe. Il ne reste plus qu’à importer ce package dans le bundle service.api.

Pour ce faire, localisez et double-cliquez sur le fichier « src/META-INF/MANIFEST.MF » du bundle service.api.
Dans l’éditeur multi-pages qui s’affiche, activez la page « Dependencies ».
Dans la liste à gauche (Import Package », cliquez sur Add, et localisez le package « djo.s2ap.demo.domain » contenant la classe Person (utilisez le filtre):

Sélectionnez ce package et validez.
Ainsi, la classe Person devient visible dans le second bundle.

Créez ensuite un package « djo.s2ap.demo.service.api » avec une interface IPersonRepository dont voici le code:

package djo.s2ap.demo.service.api; 

 

import java.util.List; 

 

import djo.s2ap.demo.domain.Person; 

 

public interface IPersonRepository { 

  List<Person> getPersonsList(); 

}

Pour finir, il faut exporter le package qui définit cette interface car l’implémentation de ce service aura besoin d’y accéder.
Donc, comme montré plus haut, exportez le package « djo.s2ap.demo.service.api » en utilisant soit l’editeur graphique du manifest ou en jouant directement sur le manifest.

4. to be continued

Faute d’espace et de temps, je vais m’arrêter là pour ce billet et je finirais la chose bientôt dans un autre billet.

Toujours faute de temps, mais aussi à cause du fait que j’ai abandonné S2DMS, j’arrive pas à finir le second volet
J’espère au moins pouvoir parler des raisons du pourquoi j’ai abandonné cette plateforme (1 raison plus précisément, la notion de PAR)