J’ai un EAR sympa comme tout qui se déploie bien dans jboss, pendant son déploiement, l’appli effectue des contrôles de validité dans la base de données sur laquelle se base l’appli. Si ces contrôles renvoient une erreur l’appli est quand même déployée et donc on a une appli qui fonctionne sur une base de données bancale.
Est ce que l’un d’entre vous connait un moyen de dire à Jboss de ne pas déployer sur une exception en particulier ou de lancer un undeploy dans le code de mon appli.
Bon, le plus propre je pense serait de renvoyer une exception assez grave pour que JBoss ne deploie pas l’appli du coup.
Merci de votre aide !!
Edit : Par deploiement je parle du déploiement de l’application lors du démarrage de JBoss en fait.
Et vérifier l’état de la base avant de déployer à la place… non? trop dur?
En prod tu ne dois pas mettre à jour tous les 2 jours (j’espère pour vous) donc y’a moyen d’être carré.
Et pour le dev/recette il suffit d’acheter un fouet pour ceux qui font n’importe quoi.
Sinon au pire tu scriptes tout le déploiement et tu sors tes contrôles dans un jar à part qui fait la vérif avant. Mais ça devient de l’intégration un peu tordue là…
Si t’as vraiment besoin de flexibilité/infos pour les bases de données (switcher facilement, avoir un état fonctionnel de certaines tables, etc.) il vaut surement mieux ajouter un petit module (genre une petite servlet d’admin avec du changement/rechargement de paramètres à chaud, etc.) au lieu de chercher à bloquer le déploiement… non?
En fait j’ai une servlet qui dans init (une méthode overridée) qui lance mon déploiement « maison » qui fait les controles en base tout ça …
@chmop alors oui on pourrait le faire avant mais non le client veut faire un minimum de chose avant et ca fait parti de la philosophie de l’appli de faire un maximum de truc toute seule.
il est vrai qu’ils installent pas non plus tous les jours mais ils installent quand même assez régulièrement (me demandez pas pourquoi hein) et on met assez régulièrement à jour aussi. Autant faire la vérif de la base au lancement c’est facile, mais empêcher le déploiement je vois pas, je sais pas comment causer a JBoss …
Et le truc c’est que dans l’instance JBoss qu’on file au client (à sa demande hein), pour des raisons de sécurité (oui ils sont un peu paranos), il n’y a pas du tout de console JMX, mais pas du tout hein on peut même pas faire du twiddle ou autre truc du style, on a été obligé de tout virer. Donc un module hors de mon appli pour gérer ça il ne faut même pas y penser.
L’init de la servlet ce n’est pas vraiment « pendant le déploiement ».
Si le code de l’appli se lance, c’est qu’elle est déployée… (ça parait con écrit comme ça :sweating: )
Au pire tu es pendant l’initialisation de certains bouts/contextes essentiels au fonctionnement du code dans ton appli (si tu utilise cette servlet pour ça). Donc tu dois peut-être pouvoir, au mieux, faire en sorte que l’appli crashe (même si ça me parait idiot…) mais probablement pas casser le déploiement.
Après entre ce que le client veut et ce qui est possible techniquement… ou entre ce que le client veut et ce qui serait le plus logique… y’a comme des fossés horribles infestés de monstres velus dans lequel t’as vite fait de perdre les développeurs qu’ont pas le niveau
A toi de savoir lui dire « non mais là ça va pas être possible » ou alors « on peut faire ça, il n’y aura pas de problème de sécurité ». Si t’es sûr de toi c’est mieux, mais sinon la plupart du temps il suffit d’avoir l’air très convaincu
Et dans les quelques cas où ton client est technique, tu l’invites à se jeter lui même dans la fosse aux monstres : « on a pas trouvé, si vous voulez essayer faites vous plaisir ».
Si il trouve là où vous aviez échoué, c’est que vous êtes mauvais… il faut arrêter de jouer les SSII et embaucher un gars expérimenté sur le projet ! :rolleyes:
Comme je te l’ai suggeré sur le chat (miaou), tu peux utiliser ant pour:
lancer tes scripts de migration
lancer le deploiement Jboss
Le deploiement est conditionné à la réussite de la migration. Evidemment ca te fait peter ta servlet. Et encore plus evidemment, j’ai jamais utilisé jboss, donc je ne sais pas ce que vaut la tache de deploiement jboos
[quote=« doumdoum, post:8, topic: 52637 »]
Comme je te l’ai suggeré sur le chat (miaou), tu peux utiliser ant pour:
lancer tes scripts de migration
lancer le deploiement Jboss
Le deploiement est conditionné à la réussite de la migration. Evidemment ca te fait peter ta servlet. Et encore plus evidemment, j’ai jamais utilisé jboss, donc je ne sais pas ce que vaut la tache de deploiement jboos
[/quote] Bah ouais voilà, on en revient à ce que je disais, faire en sorte que tout soit bon AVANT de déployer l’appli
Sinon, y’a une méthode en utilisant un ServletContextListener qui renvoie n’importe quelle RuntimeException en cas de mauvaise initialisation. Ou qui positionne un attribut lu par un Filter qui redirige vers une page d’erreur si l’init s’est mal déroulé.
Bon en fait ce n’est plus prioritaire du tout … comme quoi … du coup ça reste en suspens j�??arrête. Bref tout ça pour rien quoi !!
Mais je retiendrai deux trucs :
ajouter dans le script de lancement de l’instance la verif qui si ca se passe mal ne lance même pas l’instance du coup ! (je sais pas si ils vont aimer ça, mais j’arriverai a les convaincre la dessus je pense)
etudier la solution de Micedre avec le ServletContextListener.
Voilà on va en rester la du coup hein !! et je vous tiendrai au courant si ca rebouge sur ce sujet.
