April 2012 - Lima-devel - mailman.cloud.codelutin.com

Architecture d'utilisation des services de Lima
by Eric Chatellier 09 May '12

09 May '12

Bonjour, J'ai essayé de synthétiser l'architecture de lima telle qu'il est à l'heure actuelle. Donc nous avons: * les handler qui s'enregistrent sur les proxy monitorable et qui sont notifiés des modifications suite à l'appel d'une méthode sur un service. Cela reste interne à un client, et cela permet de mettre à jour facilement les interfaces qui manipule les mêmes données. * L'interceptor qui initie une topia context et qui l'enregistre dans la transaction courante (enlist). Même si ça fonctionne, je ne suis pas fan du fonctionnement: - thread local, avec accès statiques - j'ai l'impression que c'est plus un hack qu'autre chose. - la xaresource implémente 2 méthodes sur 8 À cogiter pour une prochaine discussion... -- Éric Chatellier <chatellier(a)codelutin.com> Tel: 02.40.50.29.28 http://www.codelutin.com

1 2

Re: [Lima-devel] [Lima-commits] r3391 - trunk/lima-business/src/test/java/org/chorem/lima/business
by Tony Chemit 25 Apr '12

25 Apr '12

On Wed, 25 Apr 2012 10:28:20 +0200 (CEST) echatellier(a)users.chorem.org wrote: > /** > @@ -47,7 +46,7 @@ > public class AccountServiceImplTest extends AbstractLimaTest { > > @Before > - public void initTest() throws LimaException, ParseException { > + public void initTest() throws Exception { > initTestDatabase(); > } > Je t'aurais bien proposé d'utiliser plutôt une Rule avec un object qui contient les services, la transaction et autres plutôt qu'une architecture en héritage, mais j'ai un peu peur de ta réponse (et certes oui on en a parlé parlé en réuniondev, ...). Ca me parait une meilleure approche que des tests avec héritage. -- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 email: chemit(a)codelutin.com http://www.codelutin.com

1 0

Re: [Lima-devel] [Lima-commits] r3385 - in trunk: lima-business/src/main/java/org/chorem/lima/business/ejb lima-business/src/test/java/org/chorem/lima/business lima-business-api/src/main/java/org/chorem/lima/business/api
by Tony Chemit 24 Apr '12

24 Apr '12

On Tue, 24 Apr 2012 16:19:59 +0200 (CEST) echatellier(a)users.chorem.org wrote: > Author: echatellier > Date: 2012-04-24 16:19:58 +0200 (Tue, 24 Apr 2012) > New Revision: 3385 > > Url: http://chorem.org/repositories/revision/lima/3385 > > Log: > Fix import entry book from ebp test t'as pas envie de tester nuiton-csv ? -- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 email: chemit(a)codelutin.com http://www.codelutin.com

2 2

Re: [Lima-devel] Gestion des transactions dans les EJB
by Eric Chatellier 17 Apr '12

17 Apr '12

Le 11/04/2012 18:28, Eric Chatellier a écrit : > > Après un nouvel essai, j'ai un debut d'implémentation qui marche. > > L'interceptor ouvre une transaction (topiacontext) et l'enregistre > dans la transaction du conteneur. > Il enregistre le topiacontext egalement dans une map de données > de InvocationContext de l'intercepteur. Finalement, cela ne fonctionne pas. La map de l'InvocationContext n'est disponible que pour l'ejb qui est la cible de l'intercepteur, pas pour les appels suivants :( Je suis donc revenu au thread local. C'est mieux que ce qu'il y a actuellement, mais c'est pas top. > > L'EJB service utilise un DAOHelper (qui est un ejb aussi) qui > a accès à l'EJBContext qui contient la même map > que celle de l'intercepteur avec le context topia qu'il > peut utiliser pour instancier les dao. Le DAOHelper n'est plus un EJB et les règles (AccountingRule) non plus. -- Éric Chatellier <chatellier(a)codelutin.com> Tel: 02.40.50.29.28 http://www.codelutin.com

1 0

MVC et service pour les interfaces
by Eric Chatellier 16 Apr '12

16 Apr '12

Bonjour, Après avoir refactorés quelques interfaces et services, voici les modifications qui sont en cours sur les interfaces et comment elles exploitent les services. Version 0.5 ----------- En version 0.5, voici comment cela fonctionnait: - le contrôleur instançiait le modèle et la vue - le modèle était le seul a connaître les services - le modèle récupérait les données (parfois en plusieurs appel : pour les arbres par exemple) - lors d'une modification, le contrôleur appelait une méthode du modèle qui appelait le service et qui mettait ensuite à jour la vue. - lors d'une mise à jour du modèle, les données de cache était trop souvent "invalidées" et récupérée entièrement depuis le service :( On en avait quand même convenu que le fait que le modèle utilise le service était une bonne solution. Cependant, j'ai changer cette façon de faire :( Version 0.6 ----------- En version 0.6, voilà comment cela a été modifié: - le contrôleur récupère les données, de préférences en un unique appel au webservice - il instancie ensuite le modèle avec ces données qui lui serviront de cache, et la vue avec ce modèle - le controleur gere seul le service. Lors d'une modification le contrôleur appelle le service et si l'appel du WS s'est bien passé, il notifie le modèle (qui met à jour son cache) qui notifie ensuite la vue. Les données ne sont plus entièrement rechargée - les listeners de service sont maintenant les contrôleurs et non les modèles comme auparavant. -- Éric Chatellier <chatellier(a)codelutin.com> Tel: 02.40.50.29.28 http://www.codelutin.com

1 0

Modifications à venir sur le modèle
by Eric Chatellier 12 Apr '12

12 Apr '12

Bonjour, Voici l'état actuel du modèle de données de lima (v 0.5). Voici la liste des modifications qui vont lui être apportés: - suppression de "Record" : aucune idée de l'utilité - suppression de la boucle "masterAccount" sur account - suppression de la boucle "generalLedger" sur account * (la hiérarchie est basé sur les accountNumber) - suppression de la classe "letter" (remplacée par un attribut letter:String dans Entry) - suppression de l'attribut "amount" de VatStatement - réduction de visibilités entre: * Entry et FinancialTransaction * FinancialTransaction et FinancialPeriod Les services vont également être modifiés en conséquence pour rapatrier toutes les données d'un écran via un seul appel de webservice. Les "bean" générés à partir du modèle vont en partit être supprimés (au moins ceux qui ne servent qu'à l'import EBP). Cordialement, -- Éric Chatellier <chatellier(a)codelutin.com> Tel: 02.40.50.29.28 http://www.codelutin.com

1 2

EJB Lite sur openejb 4
by Eric Chatellier 12 Apr '12

12 Apr '12

Bonjour, J'ai réussi à supprimer les interfaces local/remote/monitorable que les ejb. Ça fonctionne, mais on ne peut pas s'en servir sans interface dans le cas de lima, car entre le avant le proxy openejb que le service distant, on rajoute encore un autre proxy pour les listeners de service qui ne peut être construit qu'avec une interface (InvocationHandler). Les interfaces que l'on pourrait potentiellement supprimer sont les "Monitorable". -- Éric Chatellier <chatellier(a)codelutin.com> Tel: 02.40.50.29.28 http://www.codelutin.com

1 2

Gestion des transactions dans les EJB
by Eric Chatellier 11 Apr '12

11 Apr '12

Bonjour, La gestion manuelle des transactions dans les EJB étant très lourde et sans intérêt metier, il serait bien de la modifier. Solution 1 ---------- La première solution consisterait a ajouter un interceptor qui ouvrirait et fermerait la transaction. Le principe consiste à se basé sur le fait que les EJB ne manipule pas la transaction mais seulement les DAO. Le but est donc d'obtenir un DAO avec une transaction topia par un moyen a élaborer. Un solution pourrait être de que l'interceptor stocke la transaction qu'il vient d'ouvrir dans un ThreadLocal et que le DAOHelper soit remplacé par une autre implementation qui instancie les DAO avec la transaction du ThreadLocal. Cela permettrait également d'appeler d'autre méthode d'autres EJB avec une unique transaction correctement. Solution 2 ---------- L'autre solution serait de faire gérée par le conteneur EJB, donc potentiellement que Topia devienne "JTA complaint". Je vais essayer de me pencher sur cette 2eme option -- Éric Chatellier <chatellier(a)codelutin.com> Tel: 02.40.50.29.28 http://www.codelutin.com

2 3