Project

General

Profile

Actions

Bug #384

closed

Mauvais cast generique dans la déclaration de NodeHome.findByFatherPrimaryKey(NodePK fatherPK)

Added by Philippe Bazart over 11 years ago. Updated over 11 years ago.

Status:
Closed
Priority:
Normal
Category:
Publication
Start date:
05/09/2010
Due date:
% Done:

100%

Estimated time:
Navigateur:
Votre version de Silverpeas:
5.1
Système d'exploitation:
Votre base de données:
PostgreSQL
Livraison en TEST:
Livraison en PROD:

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.

Actions #1

Updated by Nicolas Eysseric over 11 years ago

  • Status changed from New to 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.

Actions #2

Updated by Philippe Bazart over 11 years ago

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).

Actions #3

Updated by Emmanuel Hugonnet over 11 years ago

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

Actions #4

Updated by Philippe Bazart over 11 years ago

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.

Actions #5

Updated by Philippe Bazart over 11 years ago

  • Assignee set to Philippe Bazart
Actions #6

Updated by Philippe Bazart over 11 years ago

  • Status changed from Feedback to Assigned
Actions #7

Updated by Philippe Bazart over 11 years ago

  • Target version set to Version 5.2
Actions #8

Updated by Philippe Bazart over 11 years ago

  • Status changed from Assigned to Resolved
Actions #9

Updated by Nicolas Eysseric over 11 years ago

  • Category set to Publication
  • Status changed from Resolved to Closed
  • % Done changed from 0 to 100
Actions

Also available in: Atom PDF