Reprise du message précédent :

 
Oublie le modèle objet quand tu utilises les CMP. Ce sont des composants plus que des objets. Cela n'a absolument rien à voir avec les possibilités fines proposées par Hibernate.
 
 

 
Autant faire directement Stateless => Hibernate.

peut être mais faut pas se leurer : il est mort né !

Salut quelqu'un connait un utilitaire pour faire des war avec le bouton droit sous windows ?
 

 
mais avec l'option pour creer direct un war

euh winzip ?

je voudrai l'option directement add to "apptest.war" pour pas avoir à renommer le zip en war apres cout

boh tu te fais un pov script que tu assignes au click-droit sur les dossiers alors.

à vot' bon coeur
http://forum.hardware.fr/hardwaref [...] 5787-1.htm
 
-->replix : ok

 
comment tu fais ça   stp ?

miam g regardé l'avancée de la prochaine d'IDEA, ca a vance super vite...subversion en cours, plein de trucs finis...
 
vivement que je paie des impots, que je puisse me l'offir en détaxé

ben prend toi la version en eap en attendant

up

ouhais...je pense que je v faire mon projet perso sous IDEA à partir de maintenant...
 
d'un autre coté, Eclipse sert de base à un paquet de trucs utilisés en entreprise (WSAD, les prochains jBuilder, ou même tel quel), et y'a un gros support J2EE de la part des fournisseurs de framework (on trouve tt les plugins pour Sping, Hibernate, etc... pour eclipe, et IDEA...et rien d'autre en fait)

Intéressant :  
http://jamie.ideasasylum.com/notebook/index.php?id=4
 
J'y connais rien, et tout ce que j'ai testé des 3 , c Derby (Cloudscape) ...ca vous parle à vous ?

boh, je lis pas tout, mais faut voir au niveau des features aussi... il me semble qu'avec hsql, les transaction, y'a pas...

Tiens jsais pas si vous avez testé la beta 2 d'openoffice (ils en parlent dans l'article spour ça que j'y ai pensé), mais y a un module DB assez dingue, qui se ocnnecte à n'importe quoi en pluggant juste des drivers jdbc...et qui permet de faire des reports par exemple, et d'autre trucs qu'on trouve dans des softs destinés à une seule DB en général et qui sont vendus hyper chers (du style crystal report)

mes scripts ant windows passent pas sous linux

 
 
ce qui me fait peur, c les commentaires...avec HSQL apparement, ta db fait en mémoire la taille des données...si tu fous du binaire, ou manipule bcp de données, c dans le mur cash...

question méthodologique de noob en J2EE qui fait ce qu'on lui a appris à l'école mais qui s'interroge furieusement sur le bien fondé de la chose :  
 
On nous a appris à coder avec une approche MVC (bon là ok), basée sur :  
un pool de CMP --> Facade statefull --> servlet --> jsp
 
y'a qu'une servlet, qui fait controleur...
 
pour se passer des infos, on crée des wrappers qui encapsulent tt les attributs d'un bean, et c ce qu'on se passe d'un bean à l'autre...
 
seulement c lourd à en mourrir :  
- si t'a besoin de faire une modif sur un attribut de ton CMP, ca se propage en cascade de partout, c l'horreur (le refactoring de WSAD suxx)
- la facade et la servlet sont un tas informe de méthodes, c inmaintenable
 
c ca le J2EE, ou c qu'on a une orga de merde ?

un peu des deux

http://java.sun.com/blueprints/cor [...] ntity.html

c'est la première fois que j'entends ça. Mais ça serait bien de le mettre dans les documents d'intro aux EJB, pas dans le fond d'un doc obscur.

euh ouais moi aussi

ceci dit, ça se tient : un EJB ça coûte cher, donc un minimum d'EJB et un max de pojo.

oué enfin mélanger le modèle et le business

j'ai pas compris ta remarque.

normalement, c'est le sexe et le business qu'il ne faut pas mélanger

moi, je ne baise qu'avec des top-modèles.

... et avec avec ta copine.
 
 
mais j'ai pas compris ta remarque, c'est quoi la différence entre un modèle et un objet business ?

ben euh, sans affirmer quoi que ce soit, pour moi le modèle c'est la representation objet d'entités métier (errr...), et "le business" (j'ai pas de bon terme en tete là), des composants qui manipulent ce modèle. si les manipulation sont complexes, j'aurais tendance à les sortir du modèle. evidemment, faut s'entendre sur la notion de "complexe". des calculs de monnaie, j'appelle pas ça du complexe, ptet que sun oui.
 

j'ai pas tout compris.
 
si tu parle de séparation traitements/données à la Merise, alors on doit mettre les traitements dans des session beans et les données dans des entity beans.
 
Mais normalement, dans le paradigme objet (pojo en l'occurence), on découpe par responsabilité dans la soupe globale des objets sans trop réfléchir à savoir si c'est beancoup de traitement ou beaucoup de mémoire qu'occupe l'objet.
 

je me basais sur la "complexité" des traitements, i.e le fait qu'ils soient plus ou moins "business-critical"

je crois qu'il y a aussi une distinction à faire entre logique business (réutilisable) et business applicative (non réutilisable)

perso, je vois pas à quoi un entity peut serveir si ce n'est faire des create/delete et autre get/set persistants ...
je vois d'ailleur pas comment ce serait faisable dans un CMP par exemple ...

t'es pas obligé d'avoir *que* des méthodes abstraites...

create/delete, c'est pas sensé être le home ? /o\

oui c'est vrai que techniquement c'est faisable ...
 
mais si tu ajoutes des méthodes qui utilisent ces méthodes abstratites, tu mélanges 2 couches en une => tu expose les méthodes abstraites inutilement => risque de mauvaise utilisation ...
 
bref, ca me parait abhérant de faire des entity qui contiennent une part d'inteligence. C'est pas pour rien que le pattern façade existe

ben j'aime pas non plus l'idée

si mais bon, quand je parle d'entity j'inclut aussi la home ... un EJB n'a pas de sens sans sa home et inversement ...
 
(me semble d'ailleur qu'en EJB3 tout ca se fait en une seule classe (avec les annotations))

(ça se fait déjà en ejb2 avec xdoclet - enfin, pas *pour du vrai* mais j'ai perso jamais touché à plus d'un fichier source pour un ejb)

je connais assez peu xdoclet (et les EJB), mais j'ai jamais trouvé que c'était bien de mélangé le source et le descripteur de déploiement ...

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