Conception d’un client Eclipse RCP et serveur OSGI avec Spring DM [step19]

Dans le billet précédant [step18] nous avons mis en place JPA avec LocalContainerEntityManagerFactoryBean en utilisant JPA/Hibernate et JPA/EclipseLink avec les 2 bases de données H2 et Derby dans un contexte NON OSGi. Dans ce billet nous allons mettre en place JPA dans un contexte OSGi avec LocalContainerEntityManagerFactoryBean en utilisant JPA/Hibernate et JPA/EclipseLink avec les 2 bases de données H2 et Derby.

Notre classe UserServiceImpl du bundle org.dynaresume.services.impl utilisera une interface DAO UserDAO qui dans notre cas est implémenté en JPA. L’implémentation de la DAO UserDAO est renseigné à la classe UserServiceImpl via le mécanisme d’injection de Dépendances en utilisant le registre de services OSGi :

Publicité

Conception d’un client Eclipse RCP et serveur OSGI avec Spring DM [step10]

Dans le billet précédant [step9] nous avons mis en place Spring Remoting, coté serveur dans l’application WEB dynaresume-server. Dans ce billet nous allons mettre en place Spring Remoting coté client dans un Client sans OSGi et un Client OSGi.

Voici un schéma de ce que nous allons effectuer dans ce billet concernant le client OSGi :

Ce schéma montre que nous allons :

• créer le bundle org.dyanresume.remoting.importer.http qui s’occupe de :
  1. récupérer le service UserService exposé par le serveur à l’aide HtppInvoker de Spring remoting. Ceci s’effectue déclarativement dans le fichier XML Spring module-context.xml.
  2. enregistrer dans le registre de services OSGi le service UserService récupéré du serveur. Ceci s’effectue déclarativement dans le fichier XML Spring module-osgi-context.xml.
• créer le fragment org.dynaresume.config.remoting.importer.http qui stocke le fichier client.properties qui permet de configurer les paramètres de connexion au serveur.
• enrichir la Target Platform avec le bundle Spring WEB.

Conception d’un client Eclipse RCP et serveur OSGI avec Spring DM [step6]

Dans le billet précédant [step5] nous avons mis en place les 3 couches Client/Services/Domain découpées en plusieurs Bundles :

• Couche Domain gérée par le bundle org.dynaresume.domain.
• Couche Services gérée par les 2 bundles :
  • API Services org.dynaresume.services qui contient l’interface UserService.
  • Implémentation Services org.dynaresume.services.impl qui exporte UserServiceImpl, l’implémentation de l’interface UserService dans le registre de services OSGi.
• Couche Client qui consomme via le registre de services OSGi, le service UserServiceImpl, géré par le bundle org.dynaresume.simpleosgiclient.

Dans ce billet et le prochain nous allons montrer pas à pas l’interêt d’utiliser Spring Dynamic Module en nous concentrant sur le bundle org.dynaresume.services.impl qui a pour rôle d’enregistrer une instance UserServiceImpl dans le registre de services OSGi. Dans ce billet nous allons utiliser basiquement Spring . Voici un schéma de ce que nous allons effectuer dans ce billet :

Ce schéma montre que :

• La classe ServicesFactory est basée sur un fichier XML Spring applicationContext.xml qui permet de déclarer la classe UserServiceImpl. C’est le conteneur Spring qui s’occupera d’instancier cette classe. Spring joue le rôle dans notre cas de factory de services.
• la Target Platform doit être enrichie pour ajouter tous les bundles Spring.
• le bundle org.dynaresume.services.impl fera référence aux bundle Spring de la Target Platform via les dépendances Import Package.

Le but de ce billet est d’introduire Spring en montrant comment déclarer l’instanciation du service UserServiceImpl via Spring :

• dans un contexte non OSGi. Nous repartirons des projets du billet [step1] et notre factory de services ServicesFactory se basera sur Spring. Nous montrerons qu’il existe 2 manières de déclarer le service UserServiceImpl avec Spring:
  • XML bean : la déclaration s’effectue tout en XML.
  • @Service annotation : la déclaration s’effectue via l’annotation Spring @Service.

  Nous verrons comment configurer Log4j dans un contexte non OSGi.

• dans un contexte OSGi. Nous partirons des projets du billet [step5] et notre factory de services ServicesFactory se basera sur Spring. Nous tenterons d’utiliser les 2 modes de déclarations en mettant en évidence toutes les problématiques de mise en oeuvre de Spring dans un contexte OSGi (problème lié au classloader). Attention, ici nous n’utiliserons pas encore Spring DM, mais uniquement Spring Framework et dans le prochain billet nous verrons comment Spring DM simplifie le code expliqué dans cette section.

  Nous verrons comment configurer Log4j dans un contexte OSGi via un Fragment OSGi.