Re: Partager un modèle jpa entre plusieurs war

Oui les ejbs amènent la démarcation tx mais là on la fait avec Spring donc
c'est équivalent

Sinon une autre question connexe par rapport à ce que disait Cedric. Si je
pars sur n modules qui ensembles vont générer un seul artefact de type war :
ce genre de configuration s'articule bien avec un environnement de dev comme
eclipse ? Le redéploiement pour tester une nouvelle version n'est pas trop
long ? On est obligé de passer par la génération d'un war maven ou bien on
est compatible wtp ?

A+
Seb

Le 27 juillet 2011 10:50, Baptiste MATHUS <[email protected]> a écrit :

> Oups, j'avais répondu en privé involontairement.
>
> Ok si tomcat t'est obligatoire. Ok.
>
> Pr ce que tu dis: c ça, c pas plus lourd que sens EJB. Ce que ça apporte ?
> Au ms démarcation tx, sécurité par défaut sans rien à faire.
>
> Et vu que tes besoins sont notamment sur la modularité, ça pouvait bien
> correspondre.
>
> -- Baptiste
> Le 27 juil. 2011 09:42, "Sebastien Cesbron" <[email protected]> a écrit :
>
> > Non c'est du tomcat/spring.
> >
> > perso j'ai mis en prod des applis sous weblo avec appel ejb3 entre les
> > parties ihm et j'ai pas été convaincu par la techno. C'est pas que c'est
> > lourd mais je ne trouve pas que ça apporte grand chose
> >
> > seb
> >
> > Le 27 juillet 2011 09:40, Baptiste MATHUS <[email protected]> a écrit :
> >
> >> Salut,
> >> Tu es ds un serveur JavaEE ou non ?
> >> Parce que tu peux aussi faire des EJB de tes services et là tu as le
> même
> >> typage ou que tu sois, la démarcation transactionnelle...
> >>
> >> --
> >> Baptiste
> >>
> >> Le 27 juil. 2011 09:34, "Sebastien Cesbron" <[email protected]> a
> écrit :
> >>
> >> >
> >> > Salut et merci pour les réponses
> >> >
> >> > Au niveau du découpage, ce que je vois là où je suis c'est qu'il y a
> >> plusieurs domaines fonctionnels et dans chaque domaine on a plusieurs
> >> modules
> >> >
> >> > actuellement on a un war par module et comme vous le dites tous j'ai
> peur
> >> d'avoir des problèmes de versionning en prod
> >> >
> >> > par contre au niveau des grands modules fonctionnels, ça me parait pas
> >> mal d'avoir des wars indépendants car ils ont un peu chacun leur vie
> propre.
> >> Après ces modules dialoguent entre eux par appel de service, c'est vrai
> >> qu'on perd un peu au niveau du typage mais on découple donc l'un dans
> >> l'autre ça évite d'aller dans l'autre sens à avoir une application
> énorme
> >> qui régresse d'un bout à chaque fois que l'on met en prod un autre bout
> >> >
> >> > seb
> >> >
>
> >> > Le 27 juillet 2011 09:24, Patrice Godard <[email protected]>
> a
> >> écrit :
> >> >
> >> >> Bonjour,
> >> >> J'ai aussi tendance à être de cet avis.
> >> >> Je suis actuellement spectateur d'un tel début de "war
> nightmare"....et
> >> d'enfer de gestion de conf.
> >> >> Sans parler de l'EAR final qui frole déjà les 150MO et qui va encore
> >> grossir... (va falloir penser à mutualiser des dépendances!...)
> >> >>
> >> >> Même il peut être intéressant de scinder une grosse appli en .war
> >> multiples tout de même. Reste à déterminer le niveau de granularité.
> >> >>
> >> >> J'aime assez l'idée de déployer dans un conteneur OSGi qui permet une
> >> réutilisation facile des différents modules (mais on se heurte aussi à
> une
> >> gestion de versions qui peut vite devenir casse-tête je présume).
> >> >>
> >> >> My 2 cents,
> >> >> Patrice
> >> >>>
> >> >>> > Message du 27/07/11 09:08
> >> >>> > De : "Cédric Beust ♔"
> >> >>> > A : "Sebastien Cesbron"
> >> >>> > Copie à : "java"
> >> >>> > Objet : Re: Partager un modèle jpa entre plusieurs war
> >> >>>
> >> >>> >
> >> >>> > Mon expérience, c'est que ce genre de modèle (wars multiples)
> tourne
> >> très rapidement au cauchemar. Tu abandonnes toute la sécurité du typage
> >> statique et tu entres dans le domaine de l'enfer des versions. Déploie
> deux
> >> wars incompatibles, tu récupères des tonnes d'erreurs au déploiement.
> Les
> >> rollbacks sont également considérablement plus difficiles à effectuer.
> >> >>>
> >> >>>
> >> >>> >
> >> >>>
> >> >>> Rien ne t'empêche d'organiser tes fichiers en modules, mais quand tu
> en
> >> viens à la création de l'artefact, crée un seul war/jar. Ce modèle a
> aussi
> >> des tas d'avantages d'un point de vue collaboration en équipe, mais je
> ne
> >> vais pas trop m'attarder là-dessus.
> >> >>>
> >> >>>
> >> >>> --
> >> >>>
> >> >>> Cédric
> >> >>> >
> >> >>> >
> >> >>>
> >> >>>
> >> >>> >
> >> >>> >
> >> >>> >
> >> >>>
> >> >>> 2011/7/26 Sebastien Cesbron <[email protected]>
> >> >>> >
> >> >>>>
> >> >>>> Salut la liste
> >> >>>> >
> >> >>>> > En ce bel été fort peu ensoleillé, je me permets de soumettre
> >> quelques questions à la sagacité collective.
> >> >>>> >
> >> >>>> > Je me remets à faire du dev après quelques années passées les
> mains
> >> dans l'infra et je me repose quelques questions existentielles car les
> >> personnes avec qui je travaille n'ont pas forcément la même approche que
> >> celle à laquelle j'étais habitué.
> >> >>>> >
> >> >>>> > Pour ma part j'étais habitué à avoir pour un domaine fonctionnel
> >> donné une application se composant d'une base et d'une appli jee au
> dessus
> >> généralement sous la forme d'un war avec hibernate pour la partie
> mapping.
> >> >>>> >
> >> >>>> > On me soumet l'idée que pour faciliter l'évolutivité des
> différents
> >> composants du domaine fonctionnel on pourrait splitter ce war unique en
> n
> >> war qui chacun contiennent la définition du modèle (partagé sous forme
> d'un
> >> module maven) et d'un service donné. Cela permet de faire évoluer les
> >> services indépendamment les uns des autres tant que le modèle est
> stable.
> >> >>>> >
> >> >>>> > Que pensez vous de cette solution ? Quels inconvénients y voyez
> vous
> >> ? L'avez vous déjà mise en oeuvre et si oui quels problèmes avez vous
> >> rencontrés ?
> >> >>>> >
> >> >>>> > Pour ma part je vois deux problèmes potentiels mais non
> >> rhédibitoires :
> >> >>>> >
> >> >>>> consommation mémoire légèrement supérieure car on instancie n fois
> la
> >> glue hibernate / spring
> >> >>>> pas de possibilité d'utilisation du cache de second niveau
> d'hibernate
> >> sinon on peut avoir des pbs de désynchronisation entre le cache et le
> base
> >> >>>> Voilà si certains ont un avis je suis preneur
> >> >>>> >
> >> >>>> > A+
> >> >>>> > Seb
> >> >>>> >
> >> >>>
> >> >>>
> >> >>> >
> >> >>
> >> >>
> >> >>
> >> >
> >>
> >>
>