Archive
Eclipse RCP/RAP with Spring DM, Spring Data JPA and Remoting [step1]
In [step0] we have seen that I will explain step by step how to develop « Eclipse RCP/RAP with Spring DM, Spring Data JPA and Remoting ». In my articles, I will use Spring DM instead of using Eclipse Gemini Blueprint because today CXF DOSGi supports only Spring DM. However I have created the patch DOSGI-115 to support Eclipse Gemini Blueprint with DOSGi.
In this article we will just initialize Spring DM :
- download Spring DM and their dependencies with maven.
- create the target definition with Spring DM bundles.
- create OSGi launch and run the launch to start the OSGi container with Spring DM.
- configure logger (log4j) for Spring DM.
But what is Spring DM? Spring DM gives you the capability to use Spring on OSGi context:
- any OSGi bundles can declare Spring bean in XML Spring file stored in their META-INF/spring folder. Spring DM provides a Spring Extender bundle which :
- load XML Spring file for each OSGi bundles which starts.
- unload XML Spring file for each OSGi bundles which stops.
- it’s possible to declare in Spring bean, services to publish/consume in the OSGi registry services.
Eclipse RCP/RAP with Spring DM, Spring Data JPA and Remoting [step0]
XDocReport project provides a modular Eclipse RCP/RAP XDocReport application where you can develop your own module with Eclipse Plugin to manage your domain with CRUD Form and generates some reporting. The online RAP demo provides for instance a Resume module to manage resume (create/update/search resume and generate report resume):
This application is based on :
- Eclipse RCP to provide Fat Rich Client.
- Eclipse RAP to provide the same application in WEB mode
- Eclipse Gemini Blueprint to use Spring on OSGi context. This project is the donation of the Spring DM project to Eclipse
- Spring Data JPA is used to implement our DAO with JPA. This Spring project is very impressive because you need not code your JPA Query. You must just follow some convention name with your methode DAO interface and that’s all! Spring Data JPA implements (at runtime) for you the JPA DAO.
- Eclipselink used as JPA Implementation.
You can find sources from this Eclipse RCP/RAP application on Git.
Our 2 next goals is :
- manage remoting to provide too Client (RCP Client) and Server (Services on server side) architecture. To do that we have several solutions like :
- CXF DOSGi (with REST).
- ECF (with REST).
- Spring Remoting (with Spring’s HTTP invoker).
- use Eclipse E4 instead of Eclipse RCP as soon as Eclipse RAP will support Eclipse E4.
We spent much time to study how to manage those technologies together but today we like this architecture. Goal of my « Eclipse RCP/RAP with Spring DM, Spring Data JPA and Remoting » articles is to explain step by step how to develop a simple Eclipse RCP/RAP with those Spring technologies, shares several rules that we have discovered with Spring on OSGi context, and manages 2 architectures :
- Fat client.
- Client/Server by managing remoting with CXF DOSGi, ECF, Spring Remoting (with Spring’s HTTP invoker).
To follow those articles, you must know OSGi, Eclipse RCP:
- if you don’t know OSGi, Eclipse RCP, or Spring and you can read French, please read « Conception d’un client Eclipse RCP et serveur OSGI avec Spring DM« .
- if you don’t know Eclipse RAP, please read My first step with RAP.
You can read the next article [step1] which explains how to initialize Spring DM.
Eclipse Nebula Pagination Control
In business application with large data, display data in a table with navigation page can be really helpful. In our XDocReport project, we need this feature in our Eclipse RCP/RAP XDocReport application for instance to select resumes to open in the Search Resume Dialog :
This last screenshot is the resume search dialog in WEB context (Eclipse RAP). Here a screenshot in fat client context (Eclipse RCP) :
After several search, it seems that there is no project which provides a SWT pagination control, which works with Eclipse RCP and RAP. So we decided to develop this control and give our code to Eclipse Nebula Project. Today Nebula Team are voting if the project will be accepted or not. Pagination control was accepted by Nebula and today it is stored on Eclipse Nebula Git.
If you are intersted you can read the original bug 367064.
Load-Time Weaving for Spring-DM with JPA/EclipseLink [step2]
Into the previous [step1], I have introduced Springweaver 0.1.2 to use it with JPA/EclipseLink. In this article I will explain how launch the Springweaver- EclipseLink sample which use Springweaver 0.1.2 with JPA/EclipseLink. I assume you know Spring DM (Spring extender…). This sample was developed and tested with Eclipse Galileo.
Load-Time Weaving for Spring-DM with JPA/EclipseLink [step1]
Martin Lippert has created org.eclipse.equinox.weaving.springweaver (version 0.1.1) bundle to manage Spring LoadTimeWeaver into OSGi context (Equinox only) which is based on Equinox Aspects.
I have tried to use org.eclipse.equinox.weaving.springweaver (version 0.1.1) into JPA context with EclipseLink, but weaving doesn’t work very well ( see SpringWeaver (0.1.1) -JPA problem for more information). I think (but not sure) that Martin Lippert has tested org.eclipse.equinox.weaving.springweaver only with Spring @Configurable.
So I decided to create a new version of org.eclipse.equinox.weaving.springweaver (version 0.1.2) to manage LoadTimeWeaver into JPA context, that you can find on Dynaresume SVN – SpringWeaver.
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 :
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 [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.
Conception d’un client Eclipse RCP et serveur OSGI avec Spring DM [step13]
Dans le billet précédant [step12] nous avons initialisé le client RCP qui affiche une liste statique de Users.
Dans ce billet nous allons faire appel au service UserService pour afficher la liste des Users. Un bouton Refresh Users permettra de rappeler le service UserService pour rafraîchir la liste des users :
Pour récupérer le service UserService dans la View, nous utiliserons 2 techniques possibles :
- un ServiceTracker classique OSGi.
- la déclaration XML Spring DM <osgi:reference ou nous montrerons comment passer par injection de dépendance le service UserService à la View.
Nous montrerons aussi comment créer des launch qui permettent de lancer :
- l’application RCP en tant que Client lourd (les services sont dans le même conteneur OSGi que l’application RCP).
- l’application RCP en tant que Client (Serveur) qui fait appel à un serveur pour utiliser les services.
Conception d’un client Eclipse RCP et serveur OSGI avec Spring DM [step11]
Dans le billet précédant [step10] nous avons mis en place Spring Remoting coté client (client avec/sans OSGi) qui fait appel (via Remoting HTTP Invoker) au service UserService exposé par l’application WEB classique dynaresume-server. Dans ce billet nous allons transformer l’application WEB classique en bundle OSGi.
Voici un schéma de ce que nous allons effectuer dans ce billet concernant le bundle OSGi org.dyanresume.remoting.exporter.http qui va remplacer l’application WEB classique dynaresume-server :
Ce schéma montre que nous allons :
- créer le bundle org.dyanresume.remoting.exporter.http qui s’occupe de :
- récupérer du registre de services OSGi, le service UserService qui a été enregistré par le bundle org.dynaresume.services.impl. Ceci s’effectue déclarativement dans le fichier XML Spring module-osgi-context.xml.
- exposer via Remoting HTTP Invoker le service UserService. Ceci s’effectue déclarativement dans le fichier XML Spring module-context.xml.
- enrichir la Target Platform avec les bundles Spring WEB Extender, Tomcat et/ou Jetty. Le serveur Tomcat/Jetty est un bundle OSGi. Il n’y a pas besoin d’installer un Tomcat ou Jetty classique.
On peut remarquer dans ce schéma que l’implémentation des services ne se trouvent pas dans l’application WEB. Il est récupéré via le registe de services OSGi. Ce procédé permet ainsi d’arrêter/lancer ou d’installer un nouveau bundle qui fournit l’implémentation des services sans arrêter l’application WEB.
Nous verrons ensuite comment utiliser nos différents bundles OSGi à travers des launch (Run) pour avoir :
- une architecture Client / Serveur. Le client appelle les services exportés par le bundle OSGi qui tourne dans un serveur de type :
- Tomcat. Le launch OSGi DynaResume – Server Tomcat 5.5.launch permettra de déployer le bundle application WEB org.dyanresume.remoting.exporter.http dans un serveur Tomcat.
- Jetty. Le launch OSGi DynaResume – Server Jetty 6.1.9.launch permettra de déployer le bundle application WEB org.dyanresume.remoting.exporter.http dans un serveur Jetty.
Le launch OSGi DynaResume – Client (Server).launch permettra de lancer le client qui recherche le services via Remoting HTTP Invoker.
- une architecture Full Client. Tous les bundles client et services (API et Implémentation) se retrouvent dans le même conteneur OSGi. Le launch OSGi DynaResume – Full Client.launch mettra en œuvre cette architecture.
Vous pouvez télécharger org.dynaresume_step11-spring-osgi-remoting.zip qui contient les projets expliqués dans ce billet :
- tous les projets (bundles OSGi + Target Platform créés jusqu’à maintenant) expliqués dans le pré-requis.
- org.dyanresume.remoting.exporter.http, bundle de remoting serveur qui est l’application WEB qui expose les services via Remoting HTTP Invoker.
- le projet spring-target-platform est enrichi :
- avec les bundles OSGi WEB, serveur Tomcat et Jetty.
- les launch (Run) des diverses architectures.
Angelo's Blog 