Reprise du message précédent :
jette un coup d'oeil aux ejb3  si tu l'as pas encore fait ... ca ressemble à ce qu'auraient du être les ejb dès le début

benou > rien à voir, dans te business method (c'est leur nom) tu n'as de toutes façons pas accès directement aux champs de l'objet, donc tu passe aussi par getBidule() (en tamplate method donc).
 
Enfin, les entity beans peuvent collaborer comme des pojos, entre eux, et donc pas question de faire intervenir un session bean là-dedans. surtout que la façade a de grandes chances d'être unique pour l'utilisateur et donc l'appeller depuis un entity bean risque de te re-rentrer dedans.

 
Ah et en quoi c'est bien de les séparer?

bha les ejb c'est sencé être des composants utilisable => pkoi grepher dans leur source UN cas d'utilisation ?

 
Ah
Et donc t'as tes classes qui trainent dans un coin puis ta va injecter un descripteur de déploiement par après?
 
Et quel genre de cas d'utilisation différent tu verrais pour un ejb, un session bean par exemple.
 
(Un MDB, je comprends, tu veux pouvoir le faire se plugger sur des queues différentes et là je rejoins ton avis).

parce qu'on ne package un truc pour réutilisation qu'à sa deuxième utilisation ?

 
vala.

j'ai jamais dis le contaire, j'ai dis que tu exposerais (surement souvent inutilement) les getter et setter
 

je vois pas d'inconvénient à ce qu'un entity communique dirrectement avec un autre ... par contre, je préfère avoir un session facade entre un entity et une appli cliente.

si ton session représente un composant logiciel de to métier, il doit être utilisable (et donc instanciable) dans différentes applications.
L'instanciation c'est le rôle du descripteur de déploiement.
 
C'est comme si tu concevais une API, mais que tu la faisais à usage unique en la polluant d'un cas d'utilisation.

ca dépend des cas d'utilisation ... je vois plutot les EJB comme un truc à utilisation multiple qu'à utilisation unique ... pour moi il décrivent une API métier.
 
mais bon, je suis un puceaux des EJB => peut être qu'une fois qu'on passe à l'acte on oublie tous ces jolis principes

c'est vrai, mais entre ça et gerer 5 fichiers pour un pauvre entity bean, j'ai vite choisi ;-)

mais putain pourquoi ils ont fait ça

benou > j'ai jamais écrit d'EJB non plus, mais des trucs réutilisable inutiles (et probablement pas réutilisables) j'en ai fait de kilos. Conclusion : un truc réutilisable c'est hyper-complexe à faire, ça se fait pas en dev courant mais que en dev de framework (ce qui se fait de pire donc) soit en refactoring pour réutilisation dans 2 projets parallèles.

un bon IDE devrait faire ca pour toi

+1
 

nan pas seulement des framework : dans les gros projets (et surement les plus petits), la logique métier peu être modélisée (avec des ejb ou autre chose) pour être réutilisée. C'est clair que c'est pas évident, et surtout que ca a un coût monstrueux. C'est d'ailleur pour ca que ca n'a un intérêt que sur les gros projets.  
C'est le cas sur un projet de ma boite, par exemple.

en fait java c'est ptet pas si nul que ca mais vous faites tous que des trucs chiants a mourrir avec

moi je fais rien avec.
 
je trolle autour ...

 
 
honnetement, pour avoir testé un des ide en question intensivement depuis un semestre, et à base de 10h/jour depuis 2 semaine, je dis non :  
- pour une raison X ou Y, le descripteur perd le synchro parce qu'il se fout un bug de réflexion, et du coup est pas foutu de relire ses ejb...
- c pas automatique de tt façon, tu dois toujours choisir ce que tu promote dans les interface ou pas..et cliquer sur promote to remote/local interface, ou faire un copier coller de la signature, ca change pas des masses de truc...
 
donc meme sans l'avoir testé, j'ai déjà un penchant pour la méthode xdoclet
 
 
sinon ayant lu votre discussion, j'avoue pas tout comprendre : un EJB, c bien cencé etre un composant qui mappe un objet métier (de granularité variable), et qui encapsule donnée via la persistance, ET comportement, non ?
 
d'ailleurs si vous aviez de la bonne litérature sur les usages "appropriés" de ces trucs là ...ca m'intéresserait

http://www.manageability.org/blog/ [...] t-ejb/view
http://www.amazon.com/exec/obidos/ [...] k_code=xm2
http://www.application-servers.com [...] 6-18:26:07

je viens de comprendre ce que voulait dire pojo  
 
--> merci pour les liens...donc EJB3 à surveiller, et Spring + Hibernate, ou Session + Hibernate quoi...

tu connais que les abreviations compliquées quoi

bah moi je sais toujours pas  

 
Plain Old Java Object

merci
donc ici on est a la pointe de la mode

 
ben vi ...gt plus un vrai apprenti décideur...là maintenant je me suis formé sur les nouveaux trends J2EE, au bingo réunion je vais pouvoir me la donner grave..
 
- ...(blabla) ...utilisation de POJO..
- Foutaises !!!!!
 

 
 
copaing !!!!!!  

boh, pojo, c'était à la mode y'a deux ans

 
C'est un paradoxe du modèle EJB qui s'éloigne du modèle objet en incitant à séparer complètement les données de leur traitement.
 
Hibernate et EJB3 nous réconcilient avec J2EE.

bon, on est bien d'accord qu'un HashSet qui me renvoie true sur un contains(o) alors qu'il devrait pas, c'est un probleme de methode equals et/ou hashcode sur le type d'objets dans le set hein? ... bon ben je soupçonne un bug dans l'implementation générée par idea alors

putain, c't'enfoiré de TreeSet se base sur compare un peu trop à mon gout
 
paske oui en fait ct un TreeSet
 
allez hop, poubelle le TreeSet, on fera le tri à la main, merci, on vous rappellera

tu aurais dû te manger des ClassCastException su ils étaient pas comparable tes objets
 
ou bien t'as fais un compareTo qui est pas en phase avec le equals ... (c'est mal )

(oui, mon compareTo était moisi)

(et ça n'aurait pas eu de sens de le completer, en plus c hyper chiant à maintenir ces methodes - comme equals et hashcode)

(donc je l'ai jareté)

de toute façon, dans la plupart des cas c'est une mauvaise idée d'implémenter Comparable (j'ai déjà débattu là dessus )

http://developer.apple.com/interne [...] ejava.html
 
y a un des maceux qui l'a deja installe?

J'ai mis un jboss 4 sur l'ibook mais c'est lent comme la mort. Ca tourne mieux sur le Celeron 800 avec linux.

je viens d'installer jboss 4.0.1, ca tourne sans probleme sur mon powerbook, je vais tester avec des trucs plus gros mais la ca roule

ben en meme temps un jboss avec rien dedans, c'est beaucoup de bruit pour rien

ma boîte veut lancer une division .net, et me mettre dedant Chuis en train de matter un peu les langages .net, j'ai peur

 
mais non, mais non, spa mal .NET.
 
Bon, après si tu fais du C#, c'est bon, du J# ou du C++ managed, ça craint plus

c prévu qd Java 5 sur mac ? (no troll, c pour savoir)
 
G vu qu'il y avait un early program, mais sinon ?