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

Dans le billet précédant [step16] nous avons introduit JPA en mode « standalone ». Dans ce billet nous allons mettre en place JPA dans un conteneur avec Spring en suivant le design pattern Service/DAO. Spring fournit à travers Spring ORM un support JPA Spring. Ce support Spring JPA permet de déclarer dans un bean Spring, la factory JPA EntityManagerFactory de 3 manières :

• LocalEntityManagerFactoryBean est une factory Spring qui permet de créer une instance de EntityManagerFactory définit dans un persistence-unit du fichier META-INF/persistence.xml. Aucune configuration n’est possible avec cette factory Spring (ex : le nom du fichier persistence.xml ne peut pas être configuré).
• JNDI qui permet de récupérer un EntityManagerFactory via JNDI. Je ne parlerais pas de cette déclaration.
• LocalContainerEntityManagerFactoryBean qui permet entre autre de configurer les informations provider et properties du fichier persitence.xml via des bean Spring. Nous verrons l’intêret d’utiliser cette factory dans le prochain billet.

Dans ce billet nous allons mettre en place JPA avec Spring en utilisant LocalEntityManagerFactoryBean avec l’implémentation JPA/Eclipselink et montrerons l’intérêt d’utiliser cette déclaration de l’EntityManagerFactory. En effet Spring jouera le rôle d’un conteneur JPA qui permettra de :

• gérer les ouvertures/fermetures des EntityManager.
• gérer les ouvertures/fermetures des EntityTransaction (commit/rollback).

REMARQUE : Ces apports sont aussi valable pour les 2 autres solutions JNDI et LocalContainerEntityManagerFactoryBean.

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

• org.dynaresume.test.dao.find.mock : bouchon DAO où les Service/DAO seront instanciés en Java classique.
• org.dynaresume.test.dao.find.mock.spring : bouchon DAO où les Service/DAO seront déclarés en tant que bean XML Spring puis instanciés à l’aide de Spring.
• org.dynaresume.test.dao.find.mock.spring.annotations : bouchon DAO où les Service/DAO seront déclarés via des annotations Spring puis instanciés à l’aide de Spring.
• org.dynaresume.test.dao.find.jpa : implémentation JPA DAO où les Service/DAO seront instanciés en Java classique. JPA en mode « standalone » sera ici utilisé.
• org.dynaresume.test.dao.find.jpa.spring : implémentation JPA DAO où les Service/DAO seront instanciés à l’aide de Spring. Spring ORM sera aussi utilisé pour utiliser JPA dans un conteneur.
• org.dynaresume.test.dao.find.jpa.spring_PersistenceUnit utilisation de l’annotation JPA @PersistenceUnit pour injecter l’EntityManagerFactory à la DAO gràce au conteneur Spring.
• org.dynaresume.test.dao.find.jpa.spring_PersistenceContext utilisation de l’annotation JPA @PersistenceContext pour injecter l’EntityManager à la DAO gràce au conteneur Spring.
• org.dynaresume.test.dao.create.jpa implémentation JPA DAO avec des Transactions (EntityTransaction) où les Service/DAO seront instanciés en Java classique. JPA en mode « standalone » sera ici utilisé.
• org.dynaresume.test.dao.create.jpa.spring implémentation JPA DAO avec des Transactions (EntityTransaction) où les Service/DAO seront instanciés à l’aide de Spring. Spring ORM sera aussi utilisé pour utiliser JPA dans un conteneur.

Publicité

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

Dans le billet précédant [step14], nous avons récupéré les JARs (OSGifié) que nous allons avoir besoin pour mettre en place la couche DAO avec JPA. Dans ce billet nous allons créer et alimenter la base de données dynaresume qui contient une table T_USER constituée des colonnes suivantes :

• USR_ID_N, entier qui est l’identifiant technique d’un utilisateur. Cette colonne est la clé primaire de la table. Les 2 bases H2 et Derby gérant le type IDENTITY (qui permet d’auto-incrémenter l’identifiant lors d’une insertion), nous typerons la colonne USR_ID_N avec IDENTITY.
• USR_LOGIN_C, chaîne de caractères qui est le login de l’utilisateur.
• USR_PASSWORD_C, chaîne de caractères qui est le mot de passe de l’utilisateur.

2 bases de données de type différent vont être créées et alimentées, pour cela nous allons :

• dans le projet Eclipse Simple dynaresume-db, créer et alimenter via des scripts, 2 bases de données avec une Table T_USER :
  • création de la base dynaresume H2.
  • création de la base dynaresume Derby.
• dans le projet Eclipse Java dynaresume-db-test, tester les 2 bases de données en utilisant les JARs H2 et Derby téléchargés dans le zip spring-target-platform-dao.zip du billet [step14].

Vous pouvez télécharger org.dynaresume_step15.zip qui contient les 2 projets expliqués dans ce billet :

• dynaresume-db, scripts de création et d’alimentation des bases H2 et Derby.
• dynaresume-db-test, tests Java de connexion aux bases H2 et Derby.

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).