@Repository("djo") » OSGi https://blog.developpez.com/djo-mos Sun, 27 Sep 2009 00:05:37 +0000 fr-FR hourly 1 https://wordpress.org/?v=4.1.42 Préparation de l’environnement : configuration de Jetty https://blog.developpez.com/djo-mos/p7727/java/osgi_configuration_port_jetty https://blog.developpez.com/djo-mos/p7727/java/osgi_configuration_port_jetty#comments Tue, 09 Jun 2009 23:11:07 +0000 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 »

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.

]]> 12 Préparation de l’environnement : configuration de log4j https://blog.developpez.com/djo-mos/p7515/java/spring/spring-framework/osgi_configuration_log4j_logging https://blog.developpez.com/djo-mos/p7515/java/spring/spring-framework/osgi_configuration_log4j_logging#comments Wed, 22 Apr 2009 14:17:34 +0000 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.

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 » :

fragment-wizard-1

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

fragment-wizard-2

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

fragment-wizard-3

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 :

console-log

]]> 0 Disponibilité du public Draft de la plateforme OSGi 4.2 https://blog.developpez.com/djo-mos/p7402/annonces/disponibilite_du_public_draft_osgi_4_2 https://blog.developpez.com/djo-mos/p7402/annonces/disponibilite_du_public_draft_osgi_4_2#comments Tue, 24 Mar 2009 12:38:43 +0000 Le public draft des specs du core => Le public draft des specs du compendium (services extra)]]> 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)

]]> 0 Préparation de l’environnement : la target platform https://blog.developpez.com/djo-mos/p7098/java/osgi_preparation_target_platform https://blog.developpez.com/djo-mos/p7098/java/osgi_preparation_target_platform#comments Wed, 21 Jan 2009 17:58:17 +0000 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 »

Target Platform Preferences

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 »

Run config 1

Sélectionnez le noeud « OSGi Framework », puis clic droit et « New »

Run config 2

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

extender-config-1

extender-config-2

Cliquez sur « Apply » pour valider.

5. Test

Cliquez sur le bouton « Run ». La console devrait afficher :

console

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

Browser

]]> 0 Nouvelle registre pour les entêtes OSGi https://blog.developpez.com/djo-mos/p6842/java/osgi/nouvelle_registre_pour_les_entetes_osgi https://blog.developpez.com/djo-mos/p6842/java/osgi/nouvelle_registre_pour_les_entetes_osgi#comments Thu, 27 Nov 2008 17:35:45 +0000 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]]> 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

]]> 0 Bug bizarroïde, ou OSGi quand tu nous tiens … https://blog.developpez.com/djo-mos/p6528/java/spring/bug_bizarroide_ou_osgi_quand_tu_nous_tie https://blog.developpez.com/djo-mos/p6528/java/spring/bug_bizarroide_ou_osgi_quand_tu_nous_tie#comments Tue, 07 Oct 2008 18:00:57 +0000 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)

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 :D

]]> 0 Sortie de Spring Dynamic Modules 1.2.0 M1 https://blog.developpez.com/djo-mos/p6327/java/sortie_de_spring_dynamic_modules_1_2_0_m https://blog.developpez.com/djo-mos/p6327/java/sortie_de_spring_dynamic_modules_1_2_0_m#comments Fri, 05 Sep 2008 12:42:30 +0000 Le premier Milestone du futur Spring Dynamic Modules (DM) 1.2.0 vient tout juste de sortir.
Pour rappel, Spring DM permet d’intégrer les modèles de composition d’OSGi (externe) et de Spring Framework (interne), et ce en:
– Importer déclarativement des services OSGi en tant que beans Spring, qu ipourront ensuite participer au cycle habituel de Spring (AOP, DI, etc.)
– Exporter déclarativement des beans Spring comme services OSGi.

D’ailleurs, l’approche du couple Spring/Spring DM pourrait être retenues comme standard dans les specifications de l’OSGi (Plus de détails ici ici).

Quelques liens clés pour cette sortie:

=> Télécharger
=> Changelog
=> Documentation
=> FAQ

]]> 0 Disponibilité du premier Early Draft des spécifications OSGi 4.2 https://blog.developpez.com/djo-mos/p6252/java/disponibilite_du_premier_early_draft_des_2 https://blog.developpez.com/djo-mos/p6252/java/disponibilite_du_premier_early_draft_des_2#comments Fri, 22 Aug 2008 13:29:18 +0000 Depuis Hier, OSGi Alliance a rendu public le premier Early Draft des spécifications de la future version de la plateforme OSGi, la 4.2.

Cette version devrait apporter quelques nouveautés majeures, dont je cite :

  • Quelques améliorations quant à la sécurité
  • Introduction du concept de BundleTracker, à l’instar du ServiceTracker (RFC 121).
  • Nouveaux évènements interceptables pour le cycle de vie des services (RFC 126)
  • Introduction d’une infrastructure pour les interpréteurs en ligne de commande (RFC 132) (Comme pour les CommandProvider d’Eclipse)
  • Support des transactions (RFC 98)
  • Support des services distants (et des systèmes distribués en général) (RFC 119)
  • Mais surtout, l’introduction d’un modèle de composants propre à l’OSGi (RFC 124)

Pour revenir au dernier point, OSGi fournit déjà les moyens pour gérer les dépendances inter-bundles (via services et import/export de packages), mais pas de facilité de gestion de composants internes aux modules (création, configuration, assemblage, etc.).
Pour mettre en place ce modèle de composants, OSGi Alliance s’est inspiré par le standard officieux dans monde Java, j’ai nommé Spring :D qui offre déjà un ensemble de fonctionnalités riche et complet pour ce qui est de la gestion des composants, ainsi qu’à Spring Dynamic Modules qui a su combiner à la perfection le monde de Spring à celui de l’OSGi.

Bref, cet RFC est grossomodo une standardisation de l’approche déclarative de Spring et de Spring DM.
Après avoir vu rapidement le draft, je n’ai décelé que quelques différences minimes parapport à l’approche de spring, et qui sont l’utilisation d’autres namespaces propores à OSGi (logique) et l’utilisation de l’élément <component> au lieu du familier <bean>.

Le draft en question est ici:
=> http://www.osgi.org/Download/File?url=/download/osgi-4.2-early-draft.pdf

]]> 0 Sortie de la version finale d’EclipseLink 1.0 https://blog.developpez.com/djo-mos/p6044/java/sortie_de_la_version_finale_d_eclipselin_0 https://blog.developpez.com/djo-mos/p6044/java/sortie_de_la_version_finale_d_eclipselin_0#comments Wed, 09 Jul 2008 23:57:09 +0000 L’équipe d’EclipseLink vient d’annoncer la sortie de la version finale d’EclipseLink, un framework de persistance pour Java utilisable avec des bases de données relationelles, non realtionelles ou fichiers XML, et exposant plusieurs APIs (JPA, JAXB, etc.)

EclipseLink est composé de:

  • Mapping Objet/Relationnel : Une implémentation JPA basée sur Toplink
  • Mapping Objet/XML : via MOXy, qui implémente et JAXB et une API spécifique.
  • Généraion de Service Data Object (SDO) à partir d’un XSD
  • Accès aux DataStores non relationnels via un adaptateur JCA : EIS

A Noter aussi qu’EclipseLink est compatible avec OSGi (venant d’Eclipse, ça n’étonne pas :D).

Quelques liens utiles :
=> Télécharger
=> Site
=> Wiki
=> News Group

]]> 4 Prototype d’Application Client/Serveur avec Eclipse RCP et S2AP https://blog.developpez.com/djo-mos/p6018/eclipse/prototype_d_application_client_serveur_a https://blog.developpez.com/djo-mos/p6018/eclipse/prototype_d_application_client_serveur_a#comments Sat, 05 Jul 2008 00:54:24 +0000 Juste pour signaler que j’ai enfin réussi à mettre en place un prototype d’une application client/serveur full-OSGi où le server est un par tournant dans S2AP et le client est une application Eclipse RCP.

Le serveur et le client sont architecturés comme suit:

  • Le serveur est un ensemble de bundles OSGi tournant sur S2AP (beta 8) composé comme suit:
    • un bundle définissant un PAO
    • un bundle définissant l’interface d’un DAO
    • un bundle définissant une implémentation du DAO utilisant Spring JDBC, MySQL et Apache DBCP
    • un bundle exposant ce DAO pour accès distant via Hessian/Spring
  • Le client est une application à base d’Eclipse RCP (3.4) qui est constitué de :
    • un bundle définissant un PAO (exactement le même que celui deployé dans le serveur)
    • un bundle définissant l’interface d’un DAO (exactement le même que celui deployé dans le serveur)
    • un bundle qui importe le DAO distant (toujours via Hessian/Spring) et l’expose en tant que Service OSGi (via Spring DM)
    • un plug-in qui définit l’aplication RCP
    • un plug-in qui ddéfinit une perspective et une vue affichant la liste des PAOs récupérés par le DAO distant tournant sur le serveur.

Ca m’a pris 2 jours (plus précisément 2 demi-journées et 1 nuit blanche), et même si le résultat est juste un proof-of-concept, sa mise en place etait vraiment douleureuse.

Je compte donc faire partager cette expérience en montrant, captures, explications et sources à l’appui, comment réaliser celà, enfin, si ça intéresse quelqu’un :)

Par contre, j’hésite encore sur le format : soit une série de billets dans ce blog, ou encore un article en bonne et due forme. Toutefois, ça risque de prendre du temps quand même …

]]> 6