dimanche 30 mai 2010

Generation de classes de méta-model

L'un des apports les plus intéressants de JEE6 est sans aucun doute JPA 2, en effet cette version apporte une multitude de nouvelle fonctionnalité par rapport a JPA 1 afin d'accroitre la productivité des développeurs. Certes la plupart des nouveautés de JPA 2 sont des fonctionnalités qui existaient déjà dans Hibernate 3.3. Mais JPA2 a le mérite de standardiser la gestion de la persistance des objets Java et donc de faciliter la migration entres ORM. Une fonctionnalité qui m'a tout particulièrement plu dans JPA2 est l'utilisation de méta modèle, elle permet de ne plus référencer les champs des objets a persister dans les requêtes de types criteria avec des chaines de caractères, mais avec des classes un peu particulières appelées méta modèles. Je vous engage à lire la documentation d' Hibernate 3,5, d' EclipseLink et d' OpenJPA 2 pour plus d'information sur le sujet. Bien évidement ces classes doivent êtres crées a partir des classes des objets a persister. Bien évidement, il existe des outils pour générer automatiquement ces classes « méta modèles ». Bien évidement Hibernate 3.5, EclipseLink et OpenJPA 2 fournissent des outils pour générer ces classes.

N'étant pas un fan de JEE, j'ai pris l'habitude d'utiliser Spring, néanmoins je souhaite gérer ma persistance avec JPA2, j'ai donc tenté d'utiliser EclipseLink qui est censé être compatible. C'est probablement le cas mais j'ai été confronté a une anomalie (l'absence de génération automatique du schéma au démarrage du serveur ) lorsque j'ai voulu l'intégrer avec Spring, et je pense qu'il va falloir alourdir la configuration de l' ORM à cause du weaving ce qui ne m'enchante guère. Bref j'ai essayé d'intégrer Spring et Hibernate 3.5 , mais là j'ai été confronté a des anomalies assez étranges, morceau choisi : un ClassCastException, il n'arrivait pas à caster la classe PostgreSQLDialect en Dialect, c'est bête, la classe Dialect est la classe mère de PostgreSQLDialect, je soupçonne Hibernate 3.5 d'être incompatible avec Spring 3.0.2 . Par contre OpenJPA 2 a marché du premier coup, sans anomalie. Je ne vous le cache pas, jusqu'à présent je n'était pas un fan d' OpenJPA, a l'époque de JPA 1 cet ORM se contentait d'implémenter la norme et n'offrait pas toute les fonctionnalités d' Hibernate 3.3 et n'offrait pas non plus les performances de TopLink essentials et d' Hibernate. Je rajouterais que OpenJPA bien qu'il soit soutenu par la prestigieuse fondation Apache manque sérieusement de « street credibility » par rapport à ses concurrents, en effet, Hibernate a pour lui le fait d'avoir influencé JPA, on sait que sans Hibernate, JPA ne serait pas ce qu'il est aujourd'hui. Hibernate est de surcroit l' ORM Java le plus utilisé, je soupçonne en outre NHibernate d'être l' ORM .NET le plus utilisé. Faut-il le rappeler Hibernate est soutenu par Red Hat proclamé leader du middleware open source. EclipseLink a pour lui le fait qu'il soit soutenu par la fondation Eclipse (et donc probablement par IBM), qu'il est le cœur de TopLink (l' ORM d' Oracle), qu'il est donc soutenu par Oracle, il est de surcroit l'implémentation de référence de JPA 2. Voilà de quoi justifier la crédibilité d' Hibernate et d' EclipseLink. Cela dit, OpenJPA étant la seule implémentation de JPA que j'arrive a faire fonctionner simplement avec Spring 3 c'est dorénavant celle ci que je privilégierais.

OpenJPA 2 propose de générer ces classes de méta-modèle. L'inconvénient du générateur de classe d' OpenJPA 2 est qu'il génère les classes de méta-modèle dans le même package que les classes des objets a persister, en soit ce n'est pas dramatique, mais ça m'embête un peu. Les classes de méta-modèle font pour ma partie intégrante de la couche de persistance, on a besoin de ces classes uniquement pour faire des requêtes, ces classes ne devraient pas êtres accessibles en dehors des packages relatifs à la persistance. Vous l'avez compris je souhaite que le générateur d' OpenJPA 2 puisse générer les classes dans un autre package. Cet ORM étant libre j'ai donc téléchargé le code source et je l'ai modifié afin qu'il puisse prendre en compte cette fonctionnalité. Cela se fait en rajoutant a la commande de génération le paramètre -Aopenjpa.destpackage=nom.du.package.

Vous pouvez télécharger ce générateur sur ce lien : (n'hésitez pas à me contacter si le lien ne marche plus)

http://www.megaupload.com/?d=J479TUTT

Aucun commentaire: