January 2009 - Topia-devel - mailman.cloud.codelutin.com

How to
by Julien Ruchaud Jan. 30, 2009

Jan. 30, 2009

How to ====== Ce document a pour objectif de prendre en main le framework Topia. Le document est constitué de 4 parties, la modèlisation, la génération, la configuration et l'utilisation. Modélisation ------------ La première étape constiste à réaliser le modèle UML soit avec Argouml (http://argouml.tigris.org) soit avec Poséidon (http://www.gentleware.com) Le stérotype «entity» sur les classes permet de préciser que la classe est persistée par Topia. D'autre stérotypes (extern, service, ...) sont disponiples mais ne sont pas présentés. Le fichier de modélisation peut être compléter par un fichier de configuration nommé <nom fichier modélisation>.properties. Il contient des informations techniques propres au librairie utilisé par Topia. Exemple : # Précise comment est mappé un type # model.tagvalue.<type java>=<type base de donnée> model.tagvalue.java.lang.String=text # Précise le schema de la base de données par défaut # model.tagvalue.dbSchema=<nom schéma> model.tagvalue.dbSchema=test # Précise l'entête de l'ensemble des fichiers générés # model.tagvalue.copyright=<valeur> model.tagvalue.copyright=/* *##%\n Copyright (C) 2007 Code Lutin\n *##% */ # Force le chargement d'un attribut # <nom paquetage>.<nom entité>.attribute.<nom attribut>.tagvalue.lazy=false attribut>org.codelutin.Person.attribute.association.tagvalue.lazy=false Génération ---------- La génération des fichiers Topia se font par l'utilisation d'un plugin maven. Le plugin est disponnible sur le repository maven de Code Lutin à l'adresse suivante http://lutinbuilder.labs.libre-entreprise.org/maven2. Configuration du plugin maven : <plugin> <groupId>org.codelutin</groupId> <artifactId>maven-generator-plugin</artifactId> <version>0.63</version> <executions> <execution> <phase>process-sources</phase>  <configuration> <addCompileDirectory>true</addCompileDirectory> <srcDirZuml>${maven.src.dir}/main/xmi</srcDirZuml> <srcXmiDest>${maven.gen.dir}/xmi/</srcXmiDest> <srcGenDest>${maven.gen.dir}/objectmodel/</srcGenDest> <includes>**/*.objectmodel</includes> <templates>org.codelutin.topia.generator.TopiaMetaGenerator</templates> <destDirGen>${maven.gen.dir}/java</destDirGen> <defaultPackage>org.codelutin</defaultPackage> <extractedPackages>org.codelutin</extractedPackages> </configuration> <goals> <goal>zargo2xmi</goal> <goal>xmi2objectmodel</goal> <goal>generate</goal> </goals> </execution> </executions> <dependencies> <dependency> <groupId>org.codelutin.topia</groupId> <artifactId>topia-persistence</artifactId> <version>2.1.0-SNAPSHOT</version> <scope>compile</scope> </dependency> </dependencies> </plugin> Le plugin utilise lutin generator avec les templates de génération de Topia, le fichier argouml ou poséidon doit se trouver dans le répertoire ${maven.src.dir}/main/xmi. Les fichiers sont générés dans le répertoire ${maven.gen.dir}/java. Il faut préciser au plugin les paquetages à traiter avec le defaultPackage et extractedPackages. Ajout dans des dépendances de Topia pour la compilation des fichiers générés : <dependency> <groupId>org.codelutin.topia</groupId> <artifactId>topia-persistence</artifactId> <version>2.1.1</version> <scope>compile</scope> </dependency> Pour une classe modélisé, nous retrouvons 6 fichiers : * Une interface * Une classe abstraite * Une implantation * Une configuration hibernate * Un DAO abstrait * Une implantation du DAO Une classe Helper est aussi générée, permettant l'accès à l'ensemble des DAO. Configuration ------------- Un fichier contenant les informations de connexion à la base de données et de configuration de Topia doit être créé au niveau des ressources du projet. Exemple : # Permet la création, la modification, ou pas automatique de la base de données # [create | update | none] hibernate.hbm2ddl.auto=update # Affichage des requêtes dans la console # [true | false] hibernate.show_sql=false # Permet de préciser les classes à persister topia.persistence.classes=org.codelutin.Person, org.codelutin.Pet # Informations de connection : # Dialect à utiliser hibernate.dialect=org.hibernate.dialect.PostgreSQLDialect # Driver JDBC hibernate.connection.driver_class=org.postgresql.Driver # URL de connection hibernate.connection.url=jdbc:postgresql://localhost/mydb # Login de l'utilisateur qui se connecte hibernate.connection.username=user # Mot de passe de l'utilisateur hibernate.connection.password=xxxx Utilisation ----------- Implantation des méthodes ~~~~~~~~~~~~~~~~~~~~~~~~~ Si des méthodes ont été définis dans le modèle de données il faut créer l'implantation correspondante. Le paquetage doit porter le même nom que celui de la génération. Gestion des transactions ~~~~~~~~~~~~~~~~~~~~~~~~ >>> Properties conf = >>> Resource.getConfigProperties("/TopiaContext.properties"); Permet de charger un fichier contenant les informations de connexion à la base et de configuration de Topia. >>> TopiaContext rootContext = TopiaContextFactory.getContext(conf); Récupère le context de départ pour la création de sous context pour la gestion des entités. >>> TopiaContext transaction = rootContext.beginTransaction(); Création d'un sous context pour la gestion des entités. >>> transaction.commitTransaction(); Validation de l'état du context, les modifications des entités sont reportées dans la base de données. >>> transaction.rollBackTransaction(); Invalidation de l'état du context, les modifications des entités ne sont pas reportées dans la base de données. >>> transaction.closeContext(); Relâche la connexion JDBC d'un sous context et de ses sous contexts sans validation de l'état des contexts. >>> rootContext.closeContext(); Relâche l'ensemble des ressources (cache, pools, ...) et relâche la connexion JDBC des sous contexts avec validation de l'état des contexts. Manipulation des entités ~~~~~~~~~~~~~~~~~~~~~~~~ >>> PersonDAO personDAO = <nom modele>Helper.getPersonDAO(transaction); Récupération d'un DAO pour accéder à une entité. >>> Person person = personDAO.findByTopiaId(id); Les méthodes find permettent de récupérer une ou plusieurs selon différents critères. >>> person.setName("tutu"); Manipulation de l'entité par les getters et setters. >>> Person person = personDAO.create(); Création d'une entité. Si vous utilisez l'instanciation classique java avec le new, l'entité n'est pas persistée. >>> personDAO.update(person); Modification d'un entité. >>> personDAO.delete(person); Suppression d'une entité. Exemple ~~~~~~~ Properties conf = Resource.getConfigProperties("/TopiaContext.properties"); TopiaContext rootContext = TopiaContextFactory.getContext(conf); TopiaContext transaction = rootContext.beginTransaction(); PersonDAO personDAO = ModelHelper.getPersonDAO(transaction); Person person = personDAO.create(); person.set...(...); person.set...(...); personDAO.update(person); person.get...(...); person.get...(...); personDAO.delete(person); transaction.commitTransaction(); transaction.closeContext(); rootContext.closeContext(); Julien

1 0

[Fwd: [Topia-commits] r1329 - topia/trunk/topia-soa/src/main/java/org/codelutin/topia/generator]
by Arnaud Thimel Jan. 29, 2009

Jan. 29, 2009

Oula, je m'appretai à le refactorer !! Tu vas encore y toucher Eric ? -- Société Code Lutin http://www.codelutin.com tel : 02 40 50 29 28 fax : 09 59 92 29 28

2 1

[Fwd: [Topia-commits] r1318 - in topia/trunk/topia-persistence/src/main/java/org/codelutin/topia: generator persistence]
by Arnaud Thimel Jan. 29, 2009

Jan. 29, 2009

:'( Nan pas un commit sur un générateur alors que je les ai tous refactoré dans le train ;'( Bon bah en avant les merges -- Société Code Lutin http://www.codelutin.com tel : 02 40 50 29 28 fax : 09 59 92 29 28

1 0

"Linkage error" en buildant topia
by Arnaud Thimel Jan. 29, 2009

Jan. 29, 2009

Salut, suite aux dernières modifs, j'ai un soucis avec ToPIA. Pour résumer, j'ai l'impression que le bloc ci-dessous pose problème : <plugin> <groupId>org.codelutin</groupId> <artifactId>maven-generator-plugin</artifactId> <version>${generator.version}</version> <executions> <execution> <id>Test Generator</id> <phase>generate-test-sources</phase> <configuration> <srcDirZuml>src/test/xmi</srcDirZuml> <srcXmiDest>${maven.gen.dir}/test-xmi/</srcXmiDest> <fullPackagePath>org.codelutin.topia</fullPackagePath> <extractedPackages>org.codelutin.topia</extractedPackages>  <srcGenDest>${maven.gen.dir}/test-objectmodel/</srcGenDest> <includes>**/*.objectmodel</includes> <templates>org.codelutin.topia.generator.TopiaMetaGenerator</templates> <destDirGen>${maven.gen.dir}/test-java</destDirGen> <defaultPackage>org.codelutin.topia</defaultPackage> </configuration> <goals> <goal>zargo2xmi</goal> <goal>xmi2objectmodel</goal> <goal>generate</goal> </goals> </execution> </executions> <dependencies> <dependency> <groupId>${project.groupId}</groupId> <artifactId>topia-persistence</artifactId> <version>${project.version}</version> </dependency> </dependencies> </plugin> Je pense que la dependency vers topia-persistence va chercher le jar dans le repo local. Or j'ai modifié des trucs dans LutinGenerator et mon jar en local pointe vers une classe que j'ai renommé, donc j'obtiens : [FATAL ERROR] org.codelutin.generator.plugin.GeneratorPlugin#execute() caused a linkage error (java.lang.NoClassDefFoundError) and may be out-of-date. Check the realms: [FATAL ERROR] Plugin realm = app0.child-container[org.codelutin:maven-generator-plugin] [INFO] ------------------------------------------------------------------------ [ERROR] FATAL ERROR [INFO] ------------------------------------------------------------------------ [INFO] org/codelutin/generator/Util org.codelutin.generator.Util [INFO] ------------------------------------------------------------------------ [INFO] Trace java.lang.NoClassDefFoundError: org/codelutin/generator/Util at org.codelutin.topia.generator.TopiaRelationValidator.validateAttribute(TopiaRelationValidator.java:71) at ... Je n'ai pas essayé, mais je pense qu'on peut vérifier cette hypothèse en changeant la version de ToPIA puis faire un "mvn clean install". Arnaud. -- Société Code Lutin http://www.codelutin.com tel : 02 40 50 29 28 fax : 09 59 92 29 28

3 3

Re: [Topia-devel] [Topia-commits] r1318 - in topia/trunk/topia-persistence/src/main/java/org/codelutin/topia: generator persistence
by tony Chemit Jan. 28, 2009

Jan. 28, 2009

On Wed, 28 Jan 2009 18:19:18 +0100 (CET) bpoussin(a)users.labs.libre-entreprise.org wrote: Oulala il a tout cassé le môssieur :) Il manquait un import vers EntityVisitor; De plus dans le corps de la méthode générée, tu utilisais accept et c'était visit, pas de chance... Par contre, je comprends pas pourquoi t'as pas perdu 10 points sur Hudson :) car ça a ensuite pété ObServe et Lima. Bon c'est pas grave (pour cette fois -:D) Tony. > Author: bpoussin > Date: 2009-01-28 17:19:17 +0000 (Wed, 28 Jan 2009) > New Revision: 1318 > > Added: > topia/trunk/topia-persistence/src/main/java/org/codelutin/topia/persistence/EntityVisitor.java > Modified: > topia/trunk/topia-persistence/src/main/java/org/codelutin/topia/generator/EntityAbstractGenerator.java > Log: > ajout d'un methode accept pour visite tous les attributs d'une entity > et de la class EntityVisitor (je laisse en exercice les tests et le > debuggage, on dit merci qui :)) > > Modified: > topia/trunk/topia-persistence/src/main/java/org/codelutin/topia/generator/EntityAbstractGenerator.java > =================================================================== > --- > topia/trunk/topia-persistence/src/main/java/org/codelutin/topia/generator/EntityAbstractGenerator.java > 2009-01-26 22:19:33 UTC (rev 1317) +++ > topia/trunk/topia-persistence/src/main/java/org/codelutin/topia/generator/EntityAbstractGenerator.java > 2009-01-28 17:19:17 UTC (rev 1318) @@ -225,7 +225,75 @@ }*/ > + > /*{ > + /** > + * Envoi via les methodes du visitor l'ensemble des champs de > l'entity > + * avec leur type et leur valeur > + *) > + public void accept(EntityVisitor visitor) throws TopiaException { > + visitor.start(this); > +}*/ > + > + for (ObjectModelAttribute attr : clazz.getAttributes()) { > + ObjectModelAttribute reverse = > attr.getReverseAttribute(); + > + // pour les asso quoi qu'il arrive il faut les lier des > 2 cotes > + // pour pouvoir supprimer en cascade l'asso lors de la > suppression > + // d'un des cotes > + if (!(attr.isNavigable() > + || > hasUnidirectionalRelationOnAbstractType(reverse, model) > + || attr.hasAssociationClass())) { > + continue; > + } > + > + if (!Util.isNMultiplicity(attr)) { > + if (!attr.hasAssociationClass()) { > + // FIXME il faut encapsuler getType() pour > retourner la version objet des types simples > +/*{ visitor.accept(this, <%=attr.getType()%>.class, > <%=attr.getName()%>); + +}*/ > + } else { > + String assocAttrName = > GeneratorUtil.getAssocAttrName(attr); +/*{ visitor.accept(this, > <%=attr.getAssociationClass().getQualifiedName()%>.class, > <%=Util.toLowerCaseFirstLetter(assocAttrName)%>); + +}*/ > + } > + } else { > + String collectionType = > GeneratorUtil.getNMultiplicityInterfaceType(attr); > + if (!attr.hasAssociationClass()) { > +/*{ visitor.accept(this, <%=collectionType%>.class, > <%=attr.getType()%>.class, <%=attr.getName()%>); + > +}*/ > + } else { > + String assocAttrName = > GeneratorUtil.getAssocAttrName(attr); +/*{ visitor.accept(this, > <%=collectionType%>.class, > <%=attr.getAssociationClass().getQualifiedName()%>.class, > <%=Util.toLowerCaseFirstLetter(assocAttrName)%>); + +}*/ > + } > + } > + } > + > + //Déclaration des attributs d'une classe d'associations > + if (clazz instanceof ObjectModelAssociationClass) { > + ObjectModelAssociationClass assoc = > (ObjectModelAssociationClass) clazz; > + for (ObjectModelAttribute attr : > assoc.getParticipantsAttributes()) { > + if (attr != null) { > +/*{ visitor.accept(this, <%=attr.getType()%>.class, > <%=Util.toLowerCaseFirstLetter(attr.getName())%>); + > +}*/ > + } > + } > + } > +/*{ > + visitor.end(this); > + } > + > +}*/ > + > + > + > +/*{ > public List<TopiaEntity> getAggregate() throws TopiaException { > List<TopiaEntity> tmp = new ArrayList<TopiaEntity>(); > // pour tous les attributs rechecher les composites et les > class d'asso > > Added: > topia/trunk/topia-persistence/src/main/java/org/codelutin/topia/persistence/EntityVisitor.java > =================================================================== > --- > topia/trunk/topia-persistence/src/main/java/org/codelutin/topia/persistence/EntityVisitor.java > (rev 0) +++ > topia/trunk/topia-persistence/src/main/java/org/codelutin/topia/persistence/EntityVisitor.java > 2009-01-28 17:19:17 UTC (rev 1318) @@ -0,0 +1,36 @@ +/* *##% ToPIA - > Tools for Portable and Independent Architecture > + * Copyright (C) 2004 - 2009 CodeLutin > + * > + * This program is free software: you can redistribute it and/or > modify > + * it under the terms of the GNU Lesser General Public License as > + * published by the Free Software Foundation, either version 3 of the > + * License, or (at your option) any later version. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Lesser Public License for more details. > + * > + * You should have received a copy of the GNU General Lesser Public > + * License along with this program. If not, see > + * <http://www.gnu.org/licenses/lgpl-3.0.html>. ##%*/ > + > +package org.codelutin.topia.persistence; > + > +/** > + * > + * Created: 28 janv. 2009 18:10:34 > + * > + * @author poussin > + * @version $Revision$ > + * > + * Last update: $Date$ > + * by : $Author$ > + */ > +public interface EntityVisitor { > + > + public void start(TopiaEntity e); > + public void end(TopiaEntity e); > + public void visit(TopiaEntity e, Class type, Object value); > + public void visit(TopiaEntity e, Class collectionType, Class > type, Object value); +} > > _______________________________________________ > Topia-commits mailing list > Topia-commits(a)lists.labs.libre-entreprise.org > https://lists.labs.libre-entreprise.org/mailman/listinfo/topia-commits

1 0

Re: [Topia-devel] [Dev] Hudson build is back to stable: topia » ToPIA - Persistence #268
by tony Chemit Jan. 26, 2009

Jan. 26, 2009

J'ai volontairement ignorer le test sur isolation :) Arnaud, J'ai commité les tests de génération, à toi de jouer ;) Bon voyage. Tony. On Mon, 26 Jan 2009 23:26:49 +0100 (CET) admin+hudson(a)codelutin.com wrote: > See > http://monitor:8080/job/topia/org.codelutin.topia$topia-persistence/268/cha… > > > _______________________________________________ > Dev mailing list > Dev(a)list.codelutin.com > http://list.codelutin.com/cgi-bin/mailman/listinfo/dev

1 0

code uniforme des generateurs de topia ? pas sur...
by tony Chemit Jan. 20, 2009

Jan. 20, 2009

Salut les lutins, désolé de faire mon rabat-joie une fois de plus mais je suis un peu étonné du code que je trouve dans les générateurs de ToPIA : 1) y'a du code dupliqué à gogo, on fait n fois le même test, par example pour vérifier une propriété sur un attribut, à quoi ça sert ? 2) du code qui devrait être identique (donc déjà dupliqué...) mais pas écrit pareil pour avoir le même résultat ? à quoi ça sert ? 3) du code en commentaire qui a mon avis devrait être supprimé (sinon ça sert à quoi le versionning svn ?) 4) des if-else à l'infini et cela est d'un compliqué à savoir où on en est (surtout avec le formattage à la Eclipse...) 5) les tag values ne sont même pas en constantes et donc on est obligé de parcourir le code des générateurs pour voir quel tagValue existe :je trouve ça trop violent, trop crade et à l'encontre d'une quelconque maintenance du code. A ce propose j'ai commencé dès que je vois un truc du genre attr.getTagValue("lazy") à définir la constante dans GeneratorUtil et à l'utiliser : attr.getTagValue(GeneratorUtil.TAG_LAZY) 6) du code sans javadoc (et J'y suis pour quelque chose (lol... et mea culpa)) Je trouve déjà assez dur de lire les classe de template alors je pense qu'on devrait faire quelque chose pour harmoniser tout cela, mais peut-être pas tout de suite (passage a JPA). Je dois (ou on doit bientôt passer sur JPA et donc revoir tous les générateurs), j'espère qu'on prendra soin de rendre nos générateurs plus compréhensibles et moins (comment dirais-je sans blesser personne LM-atelier-esque...) De manière générale je trouve qu'on ne prette vraiment pas attention à la propreté de notre code et que coder à l'arrache est une hérésie alors que y'a plein de très bonnes choses et idées dans notre code, alors un peu de rigueur dans le codage serait cool... Tout ce dont je vous ai énoncé dans les points précédents sont pour moi le beaba d'un codeur et je ne vous parle pas des best-pratices de sharengo ;) mais du simple bon sens... Ne vous sentez en aucun cas aggresser par mes propos, c'est pas le but, juste ça serait bien que ça avance dans le bon sens. Tony. ps: et c'était pas une gueulante, juste un constat :)

3 3

isolation des contexts
by tony Chemit Jan. 20, 2009

Jan. 20, 2009

Hello les lutins, dans ToPIA-persistence, y'a plus qu'un seul test qui ne passe plus : celui sur l'isolation des contexts. Est-ce du à un changement de version d'hibernate ? Il faudrait qu'on arrive à corriger ce problème car moi il me fait un peu peur (surtout si on veut se base sur l'isolation des contexts!) Et... faire passer tous les tests de ToPIA-service et là je pense que cela revient plutot à ceux qui les ont écrit car j'ai un gros doute que cela est un jour fonctionné :) A part ça bon week-end à vous. Tony.

2 1

[Vote] ToPIA-test dans le projet ToPIA
by tony Chemit Jan. 15, 2009

Jan. 15, 2009

Salut les lutins, je me demandais pourquoi le projet ToPIA-test était tout seul dans son coin alors qu'il me parrait plus naturel de le mettre en tant que module du projet ToPIA. L'intérêt serait de pouvoir vérifier qu'une modification dans les générateurs de ToPIA-persistence ne provoque pas de régression sur un modèle xmi. Les votes sont ouverts pendant 72 heures :) (on se la fait à la maven?) [+1] yes do it [0] don't care [-1] No, I'm against it! +1 Tony.

1 0

embed-xml="true" or not ?
by tony Chemit Jan. 14, 2009

Jan. 14, 2009

Salut les lutins, je comprends pas trop un point dans la generation du mapping hibernate sur des associations : dans la méthode generateHibernateOneToMany : on a : si !indexed alors embed-xml="true" sinon embed-xml="false" y'a une subtilité ? car quand on veut faire un export xml ça marche pas bien avec embed-xml="true" tony.

2 1