Silverpeas » Silverpeas Core

En fait, je m'en suis rendu compte en commençant le portage en V5 du module de synchronisation (initialisé pour les HCL). En effet, la synchro intervient à un niveau plus bas et je n'ai pas toujours souhaité utiliser les méthodes "métiers". De plus, j'avais vraiment besoin de cette méthode. Et après tout c'est un finder et c'est théoriquement fait pour cela.

Donc oui, je suis probablement le seul à l'utiliser en direct (hormis NodeBmEJB bien sûr).

Ce qui m'inquiète c'est que vu que tu appeles directement l'entity, on risque de se retrouver coincés si on veut virer l'es EJBs : si sur l'EJB session on peut garder l'interface, l'entity risque d'être remplacé par un pojo + dao

C'est simple : j'ai besoin d'un contrôleur transactionnel. Or actuellement, Silverpeas utilise un conteneur d'EJB pour faire cela, donc j'utilise des EJB. C'est indispensable, je n'ai pas d'autres solutions (c'est ce que me garantit le DataSource fourni par le conteneur en relation avec les instruction des descripteurs de déploiement). La synchronisation doit absolument s'effectuer dans un contexte transactionnel général, c'est même vital pour la cohérence des données.

Changer le conteneur d'EJB en autre chose ne pose pas de pb particulier, puisque tu le remplaceras probablement par un autre conteneur comme Spring ou EJB3, ce qui fonctionne de la même façon (en plus facile pour la mise en oeuvre mais le principe reste rigoureusement le même).

Concernant le modèle EJB, je ne fais que le respecter : utiliser les entity pour les données. Et c'est mieux d'ailleurs qu'un EJB session transporte des Entity que des Pojo simplement sérialisés (bcp plus couteux en terme de marshalisation et d'échange de données). Si tu changes, il faut tout changer y compris les EJB Sessions. Et dans ce cas OK. Mais de toute façon, il faudra revoir partout où il y en a (EJB session y compris), donc y compris dans mon code.