Bug #384
fermé
Mauvais cast generique dans la déclaration de NodeHome.findByFatherPrimaryKey(NodePK fatherPK)
100%
Description
Dans l'interface d'EJB Entity com.stratelia.webactiv.util.node.ejb.NodeHome, la méthode findByFatherPrimaryKey(NodePK fatherPK) retourne une collection. L'ajout de "generics" depuis la version 3 de Silverpeas est ici erronée : il est fait mention de collection de clés de type NodePK, alors qu'il s'agit de collections d'entités de type Node.
En effet, la spécification EJB est très claire : pour toute méthode "finder" sur la home d'un EJB Entity, le conteneur retourne une collection de handles (en fait des proxies) d'instances Entity, donc ici des instances de Node.
Il se trouve que cette erreur de déclaration n'a pas eu d'impacts jusqu'à présent car :
1) Partout où la méthode est utilisée, en héritage du code de la V4, il y a des cast (Node) explicites
2) En Java et contrairement à C++, les "generics" ne sont que déclaratifs et automatisent les cast, sans modifier les types (donc le typage de Collection<NodePK> est le même que Collection<Node> et ne contiennent que des Object).
En revanche, dès que du code nouveau exploite cette écriture Java5, il ne compile plus. C'est le cas notamment du code du module de synchronisation inter-Silverpeas.
Mis à jour par Nicolas Eysseric il y a presque 14 ans
- Statut changé de New à Feedback
OK mais peux-tu me dire quelle classe utilise cette méthode ?
Normalement, seul l'EJB session stateless NodeBm utilise l'entity. Ce dernier ne devrait pas être utilisé directement.
Mis à jour par Anonyme il y a presque 14 ans
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).
Mis à jour par Emmanuel Hugonnet il y a presque 14 ans
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
Mis à jour par Anonyme il y a presque 14 ans
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.
Mis à jour par Nicolas Eysseric il y a presque 14 ans
- Catégorie mis à Publication
- Statut changé de Resolved à Closed
- % réalisé changé de 0 à 100