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 [step18]

Dans le billet précédant [step17] nous avons mis en place JPA avec Spring en utilisant LocalEntityManagerFactoryBean avec l’implémentations JPA JPA/Eclipselink et les 2 bases de données H2 et Derby. Nous avons vu que le support Spring ORM nous permet de gérer JPA dans un conteneur (Spring) JPA ce qui permet de:

• gérer les ouvertures/fermetures des EntityManager.
• gérer les ouvertures/fermetures des EntityTransaction (commit/rollback) via l’annotation Spring org.springframework.transaction.annotation.@Transactionnal

A ce stade nous avons déclaré un persistence-unit par implémentation JPA et par base de données, ce qui engendre une duplication de déclaration XML (« provider », « propertes », et « class ») . Par exemple si on souhaite utiliser 2 base de données pour une même implémentation JPA, l’information « provider » est dupliquée 2 fois dans le fichier persistence.xml mais pire la déclaration des éléments « class » est aussi dupliquée. Lorsque l’on souhaite gérer une nouvelle classe Java domain persistente, l’élément « class » doit être ajouté dans les 2 déclaration des persistence-unit. Si on ajoute à ça une autre implémentation JPA, ceci signifie que l’on a 2 (implémentation JPA) * 2 (base de données) = 4 déclarations de persistence-unit.

L’idéal serait d’avoir 1 seule déclaration persistence-unit qui gère tous les cas. Le support de Spring ORM permet de gérer ce cas-ci en déléguant les informations de « provider » et de « properties » à des bean Spring en utilisant LocalContainerEntityManagerFactoryBean. LocalContainerEntityManagerFactoryBean permet d’avoir une seule déclaration persistence-unit pour n’importe quelle implémentation JPA et base de données :

<persistence xmlns="http://java.sun.com/xml/ns/persistence"
	version="1.0">

	<persistence-unit name="dynaresume"
		transaction-type="RESOURCE_LOCAL">

		<class>org.dynaresume.domain.User</class>

	</persistence-unit>

</persistence>

C’est ce que nous allons effectuer dans ce billet en mettant en place JPA avec LocalContainerEntityManagerFactoryBean en utilisant JPA/Hibernate et JPA/Eclipselink avec les 2 bases de données H2 et Derby.

Vous pouvez télécharger le zip org.dynaresume_step18.zip qui contient les projets expliqués ci dessous:

• org.dynaresume.test.jpa_lfb : projet avec 2 implémentations JPA JPA/Eclipselink et JPA/hibernate avec 2 bases de données H2 et Derby qui utilise LocaEntityManagerFactoryBean.
• org.dynaresume.test.jpa_lcfb_1 : projet avec 2 implémentations JPA JPA/Eclipselink et JPA/hibernate avec 2 bases de données H2 et Derby qui utilise LocaContainerEntityManagerFactoryBean. Dans ce projet l’implémentation JPA/Eclipselink ne fonctionne pas du au problème de LoadTimeWeaver (pour JPA/Hibernate le problème ne se pose pas).
• org.dynaresume.test.jpa_lcfb_withoutLTW : projet avec 2 implémentations JPA JPA/Eclipselink et JPA/hibernate avec 2 bases de données H2 et Derby qui utilise LocaContainerEntityManagerFactoryBean. Dans ce projet l’implémentation JPA/Eclipselink fonctionne en désactivant le LoadTimeWeaver.
• org.dynaresume.test.jpa_lcfb_withLTW : projet avec 2 implémentations JPA JPA/Eclipselink et JPA/hibernate avec 2 bases de données H2 et Derby qui utilise LocaContainerEntityManagerFactoryBean. Dans ce projet l’implémentation JPA/Eclipselink fonctionne en utilisant l’agent Spring.
• org.dynaresume.test.jpa_lcfb_2 : projet avec 2 implémentations JPA JPA/Eclipselink et JPA/hibernate avec 2 bases de données H2 et Derby qui utilise LocaContainerEntityManagerFactoryBean et qui délègue les informations provider et properties à des bean Spring.
• org.dynaresume.test.jpa_lcfb_3 : projet identique au projet org.dynaresume.test.jpa_lcfb_2 mais qui « splitte » la déclaration des bean en plusieurs fichier XML Spring applicationContext qui définiront dans le prochain billet nos bundles OSGi.
• org.dynaresume.test.jpa_lcfb_4 : projet identique au projet org.dynaresume.test.jpa_lcfb_3 mais qui utilise org.springframework.beans.factory.config.PropertyPlaceholderConfigurer pour définir les propriétés de la base de données dans un fichier de propriétés.
• spring-target-platform-dao : projet qui contient toutes les librairies nécessaires à la couche DAO.

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

Dans le billet précédant [step15] nous avons créé les bases de données H2 et Derby constitué d’une table T_USER. Nous avons développé un petit code Java qui se connecte via JDBC à la base de données pour afficher la liste des User. Dans ce billet nous allons mettre en place JPA en mode « standalone » (sans utiliser un conteneur JPA) et développer des petits exemples qui récupère un User, une liste de User, qui insère un User dans la table T_USER des bases de données H2 et Derby avec les 2 implémentations JPA JPA/Hibernate et JPA/Eclipse Link :

Nous développerons les exemples décrits ci-dessus, avec les 2 implémentations JPA et les 2 bases de données :

• JPA/Hibernate – H2 : exemples qui utilise la base de données H2 avec l’implémentation JPA/Hibernate.
• JPA/Hibernate – Derby : exemples qui utilise la base de données Derby avec l’implémentation JPA/Hibernate.
• JPA/Eclipselink – H2 : exemples qui utilise la base de données H2 avec l’implémentation JPA/Eclipse Link.
• JPA/Eclipselink – Derby : exemples qui utilise la base de données Derby avec l’implémentation JPA/Eclipse Link.

Vous pouvez télécharger le zip org.dynaresume_step16.zip qui contient les projets expliqués ci dessous:

• org.dynaresume.test.jpa.hibernate : examples avec JPA/Hibernate.
• org.dynaresume.test.jpa.eclipselink : examples avec JPA/Eclipse Link.
• spring-target-platform-dao : librairies JARs récupérés via Maven dans le billet [step14].
• org.dynaresume.test.jpa : fusion des 2 projets org.dynaresume.test.jpa.hibernate et org.dynaresume.test.jpa.eclipselink pour montrer qu’il est possible d’avoir plusieurs implémentations JPA dans un même projet.

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

Dans le billet précédant [step13] nous avons mis en place l’application RCP qui fait appel au service UserService pour afficher la liste des Users dans une View via Spring DM. Cette liste provient du bundle Implémentation service org.dynaresume.services.impl qui retourne une liste de User statique créées en dur en Java.

A partir de ce billet, nous allons utiliser une base de donnée constituée d’une table T_USER qui contiendra la liste des User qui sera récupérée par le service UserService. Notre implémentation Service UserServiceImpl fera appel à un bundle DAO (Data Access Object) encore appelé Repository qui s’occupera de récupérer la liste des Users d’une base de donnée.

Voici un schéma grossier de ce que nous allons mettre en place dans les billets futurs :

Ce schéma montre que :

• la couche DAO utilisera JPA (Java Persistence API) l’API standard d’ORM (Object Relationnel Mapping).
• JPA étant une API, nous devons utiliser une implémentation de JPA dans notre DAO. Nous allons nous appuyer sur 2 implémentations JPA :
  • JPA/Hibernate implémentation de JPA avec Hibernate.
  • JPA/EclipseLink implémentation JPA avec EclipseLink. Cette implémentation qui est basé sur les sources de TopLink est une version adaptée au contexte OSGi, ce qui le rend facilement utilisable dans un contexte Eclipse RCP. EclipseLink a pour objectif d’implémenter JPA 2.0 (JSR 317).
• nous allons utiliser 2 base de données :
  • H2 Database
  • Derby

  J’ai choisi ces 2 bases de données car elles ne nécessitent aucune installation (comme MySQL par exemple) et peuvent être utilisé en mode embarqué, autrement dit il suffit de placer dans le classpath le JAR de la base de donnée pour l’utiliser.

Avant de démarrer les billets futurs nous devons télécharger les JARs (H2, Derby, JPA, EclipseLink, JPA/Hibernate). Pour cela, jJ’ai décidé d’utiliser Maven. Dans ce billet je vais expliquer comment utiliser Maven pour télécharger nos JARs requis. Dans les prochains billets, j’expliquerais ce qu’est JPA puis ce que peut apporter Spring dans un contexte JPA. Je montrerais ensuite comment utiliser JPA dans un contexte OSGi à l’aide de Spring DM et ce que peut apporter OSGi (changer de base, changer d’implémentation JPA… sans devoir redémarrer l’application RCP).