Est-il possible de scripter le deploiment d'un ear?

Bonjour,

Je suis actuellement en train de développer une solution logicielle basée sur JAVA.

Cette dernière disposera d'un serveur glassFish V2 sur lequel se trouvera différents EJB.
De plus, différentes IHM (web et swing ou JavaFx je sais pas encore) se connecterons sur le serveur glassfish afin d'y faire des opérations "métiers".

Toutefois j'aimerais notifier les IHMs quand une nouvelle version de l'EAR sera disponible.
L'utilisateur cliquerait ensuite sur "mettre à jour" puis:
- une application Java se lancerais,
- téléchargerait en le nouvel ear en local,
- sauvegarderait le système (sauvegarde SGBD),
- mettrait à jour l'EAR sur le serveur,
- et ferait les modifications éventuelles en base de données (ALTER, CREATE... TABLE).

Je pense savoir techniquement comment faire pour tous ces points sauf pour:
"mettrait à jour l'EAR sur le serveur".
Est-il possible de faire en sorte qu'une application java mette à jour Glassfish (par le biais d'un script ... peut être à l'aide d'un outil tel que Cargo?)

Bref si quelqu'un à une idée ou une expérience sur le sujet, je suis preneur.

Merci d'avance :)

Bah normalement les outils en ligne de commande tels que asadmin (option deploy) et asant (via la task ant sun-appserv-deploy) doivent le permettre, mais je n'en sais pas plus, à toi de fouiller ces fonctions. ;)

Bonjour

Asadmin permet de scripter le deploiement d'EAR.
cf doc Sun

Merci les gens :D
Je vais essayer tout cela et je vous tiendrais au courant... bon c'est pas pour tout de suite, il faut d'abord que je finisse le développement de l'appli avant de vouloir distribuer les mise à jour ;) et il y'a encore qq centaines d'heures je pense ;)

++

Salut


Je ne suis pas sur de bien saisir ce que tu entends par "mettre a jour", s'agit-il de passer d'un EAR vX a v(X+1)? Un changement de version donc?


Si c'est bien ça,ton programme est probablement réalisable seulement sera probablement limité a cause de certaines contraintes...


Tu peux utiliser
- asadmin list-components (pour avoir le nom exact de ton ear si il est dynamique et si tu as un pattern de nom etc...)
- asadmin undeploy "nomEarVx"
- asadmin deploy "nomEarVx+1.ear"


A coté de çà, le point le plus délicat semble pour moi être la migration de version de base de données. Il existe des outils pour faire des modifications automatiques de ta db en fonction des changements détectés (comme le hbm2ddl=auto de hibernate), seulement de ceux que j'ai pu rencontrer, il a toujours été conseillé de repasser derrière.

En effet ces outils ne marchent pas dans plusieurs situations:
- Si tu renommes une colonne, ils ne savent pas nécessairement qu'il s'agit d'un renommage et font un drop / create de la table ou de la colonne, et tes données sont perdues, ou alors juste un create en laissant l'ancienne table/colonne et il faut arranger les choses manuellement.
- Pire encore, avec hbm2ddl, j'avais testé, si tu changes le type d'une colonne, il ne peut rien faire... étant donné qu'il ne sait pas comment tu veux convertir tes données déjà existantes... bref il laisse l'ancien type et après a toi de faire les choses a la main ;)


Bref si ton nouveau ear n'implique pas de grands changements en base a mon avis ça ne pose pas de problèmes.



Pour le reste, la mise a jour de l'ear par un script est assez utilisée en intégration continue... Pour ma part, n'ayant pas eu besoin de conserver les données de la base, sur un projet nous avons mis en place un script qui drop et recréé toute la base avec le nouveau schéma (encore généré avec hbm2ddl...), ainsi pas de problème... Bref le probleme se pose a partir du moment ou tu souhaites conserver les données existantes... D'apres ce que j'ai lu sur le sujet ca a toujours été assez délicat les migrations de database et souvent c'est fait a la main avec des .sql...



Si la problématique t'intéresse, regarde du coté d'un outil appelé Liquibase, qui est plus ou moins complémentaire a hbm2ddl et permet de générer un "changelog de la config de la db". J'ai pas reussi a le faire marcher dans le temps que j'y ai accordé cependant tu auras peut etre plus de succes que moi ;)

Merci pour ce complément d'informations. Effectivement pour le sql je pensais faire un drop/create et avant de lancer la mise a jour une sauvegarde de la base et une moulinette sql qui réintègre les données. En fait cette manière me semble efficace car ce n'est pas une base volumineuse, elle permettra essentiellement de sauvegarder le paramétrage de l'application et l'état des équipement qu'elle contrôlera.

Concernant Liquibase, je regarderai et te tiendrai informé si tu veux... mais bon comme dit avant de vouloir livrer la version 1.1 faut déjà faire la 1.0 ;-) donc ce n'est pas pour tout de suite.

++