Reprise du message précédent :

 
+1  

 
et moi   ?  
 
 
je donne des cours de baterie aussi mais c plus cher  

 
quoi

 
repond a tes MP toi

 
mais j'ai vu mais j'ai rien compris

on appelle pas le GC soi-même, ça tue les perfs et ça donne du grain à moudre aux partisans de "java c'est lent".

tu vois comment ça se passe une relation sexuelle homme-femme ? ben là il te propose pareil mais avec un homme à la place de la femme.

 
ok, jl ai fait une fois que je me mangeai tout ces outOfMemory aussi mais bon j'ai compris maintenant    
 
 
juste une chose pourquoi permettent t il de l'appeler si c'est mal ?
 
rien n'est précisé dans la javadoc qui plus est
 
 
( de memoire hein , pas tapai)
 

 
quand tu veux pour les tutos java ...
si tu veux on echange des smileys verts et pas beaux contre des cours de java

 
t'es invité toi aussi
 
et ma nouvelle copine BI apportera ses copines  
 
 

 
ben pas besoin de cours, des que tu buche tu crée un topic  
 
 

je me disais aussi

parce qu'il existe des moments où on peut l'appeller pour être sympa avec l'utilisateur.
1) quand il a le dos tourné (à la mise en veille par ex.)
2) quand on fait un gros traitement bloquant, à la fin, avant de lui rendre la main.

hop, je vais planter un drapeau la dedans aussi

question assez étrange :
 
dans mon super bouquin que je viens de récupérer, il est dit que dans les ejb 2.0, tous les accesseurs sont abstraits et on met pas les champs pour les propriétés dans le bean, ils seront implémentés concrètement par le proxy (ce a du sens à mes yeux).
 
or dans le tuto que je fais, on met des accesseur concrets et les champs dans le bean, mais le elb-jar.xml indique fièrement ejb 2.0 dans son doctype.
 
un peu comme s'il y avait couillage quoi.
 
 
J'imagine que c'est compatible et mélangeable les ejb 1.1 et 2.0, me trompe-je ?

je me souviens plus bien de ce truc ... il me semble que dans les CMP faut laisser les attributs en public et pas mettre d'accesseur ... par contre, faut surement en mettre dans les BMP ...
 
pfiou, ca fait longtemps que j'ai plus fait d'EJB

rooh le bordel, ils peuvent pas tenter de réduire la différence CMP/BMP un peu ?
 
je vais essayer d'éclairer le mystère et je poste le résultat de ma puissante analyse pour les curieux.

ben c'est quand même normal que ce soit pas pareil ...
 
par contre le coup d'obliger les attribut public j'ai toujours trouvé ca à chier : comme ci le container était pas capable de regarder si y a des get/set

 
je vais sans doute me faire flamer mais pourquoi

n'est pas bon dasn ce cas
 
edit: si il y a d'autre conseils de ce type pour les templates eclipse, je suis preneur

bon, je comprends un peu mieux (encore que) : dans le bouquin je viens de voir un ejb-bmp qui avait le code SQL directement dans les callback de l'ejb.
 
Comme quoi du code crade permet parfois d'apréhender un peu mieux les choses.
 
J'avais uniquement vu du code avec la classe d'accès à la BDD (DAO) séparée et le lien entre les 2 généré par xdoclet. Comme je ne me suis pas encore penché sur xdoclet, je fais pas la différence entre le code qu'il génère pour simplifier la vie du dev. et ce qui est du rôle normal du conteneur.

parce que c'est le comportement par défaut d'une exception que de pêter.
 
par exemple, tu ouvres un fichier et tu as pas envie de t'emmerder avec de la gestion d'erreur, la bonne démarche est de relancer l'exception, comme ça le programme s'arrête avec une erreur par défaut relativement lisible. Mais tu continues pas avec un fichier pas ouvert, avec des opérations I/O avec toutes des exceptions bouffées etc. C'est un coup à tout pêter.
 
Si on veut pas s'emmerder avec les erreurs, on relance.

Rien ne vaut l'infâme "catch & burry" à toutes les sauces

je suis épargné \o/

 
merci

mon dieu... ejb est déjà assez pourri comme ça tu trouves pas?
non, nraynaud, c bien comme tu as lu: les getters et setters sont declarés abstract pour le cmp

je lis, je comprends rien, mais une chose est sur : ca donne pas envie le J2EE...

Ca ira mieux avec EJB 3.0  

 
tu veux être mon tuteur java ?

oui mais relancer une runtime c'est aussi un bon moyen pour oublier de la traiter.. et autant dans une application standalone tu le verras tout de suite, autant quand ton appli sera dans un server d'appli tu vas vite perdre la trace.. t'auras déjà du pot si l'exception est loggée...

bon je vais peut etre rester avec mon stacktarace alors...
  remarque je fais plus de j2ee la...

 
ptain je suis trop fort pour inventer des mots cultes sur ce forum

bordel y'a un todo c'est pas fait pour le chèvres !
 
maintenant, mate le résultat sur uriel !

 
eh je suis la
 
 je vais laisser comme ca, il est temps que j'apprenne a bien programmer en java, me  servir des todo je commence ( )... et comme je fais pas de j2ee, je vais garder ta solution, si y en a marre je demanderais ici  

ma template:
 
} catch ($exception e) {
  throw e; // todo: handle exception!
}
 

c'est fondamentalement différent du mien
 
tiens, ça me rappelle un truc.
 

 
updated

ben.. oui. ça passera pas la compile si on fait rien et que c'est pas géré au dessus

(parce que bon les todos c'est joli, mais ça s'empile et on finit pas les laisser s'empiler hein... il m'est meme déjà arrivé de trouver des todos que j'avais écrit moi meme, et qui n'etait plus valides depuis un bon moment parce que j'avais moi meme done le truc à faire, mais sans avoir vu/lu le todo en question...)

non

sircam > tu veux utiliser quoi à la place ?