Bon, j'ai sous tomcat un objet qui implemente ServletContextListener pour initialiser mon appli. Cet objet, dans sa methode ContextInitialized, crée un pool de connexions vers une base de données, et detrui celui-ci dans sa methode ContextDestroyed.
Le probleme est que je viens de m'apercevoir que dans le cas d'un reload "à chaud" du contexte, ContextDestroyed n'est pas appelée, ce qui fait qu'au bout d'un certain nombre de rechargements, ce qui arrive en période de tests, et bien mon SGBD s'écroule sous les connexions restées ouvertes.
Ce n'est pas très génant, puisque le problème ne se pose que dans un environnement de développement, et que de toute façon j'ai qu'à faire des trucs propres, mais si il existait un moyen de détecter le rechargement du contexte, ca serait pratique.

ServletContextListener?

ben oui.
 
en réponse à la question: je pense que c un bug de tomcat.
(enfin, qu'entends tu par  " reload à chaud du contexte " ?)
vérifie dans la liste des bugs fixés sur les dernieres version.
y'avait un bug du meme genre dans resin, et il a été fixé (c moi qui l'avait signalé )
 
sinon au pire tu appelles la methode contextDestroyed au debut de ta methode contextInitiliazed
ou bien en plus propre, tu verifie que la pool est vide, auquel cas tu la vide

quand je dis "reload à chaud", je veux dire que je mets reloadable=true dans mon web.xml, et que quand je change une classe dans mon appli, elle est rechargée sans que j'ai besoin de redemarrer le serveur.
 
une question alors : le ServletContextListener utilisé est-il toujours le même, ou un nouvel objet est-il créé à chaque fois ?
 
DarkLord >> hébékoi ?

ha bon y'a ça dans tomcat, c nouveau?
t'as vérifié les bugs de tomcat?
 

logiquement ça devrait etre le meme, mais c pas gagné. tu devrais pas compter dessus à mon avis. pq?

 
quoi quoi? Je te donnais une piste là non ? Qu'est ce que j'ai encore fait  

DarkLord a écrit a écrit :     quoi quoi? Je te donnais une piste là non ? Qu'est ce que j'ai encore fait

relis son post alors....

pff je suis à la masse moi.
 
désolé

Dans ton web.xml de ton appli, tu as une balise qui doit s'appeler initFirst. Dedans, il suffit que tu places une servlet qui appelle ta methode detruisant ton ServletContextListener.
 
Je pense que ca devrait suffire...
 

si tu commences à faire des cochoneries comme ça, autant tout faire dans la servlet alors, le ServletContextListener n'a plus aucun interet...

ce ne sont pas des cochonneries
moi, je m'en sers en general pour lire un fichier de proprietés  
 
ensuite, un bean dont le scope est application me permet de les retrouver sans avoir aucune adresse ni chemin en dur dans mon code.
 
ya certainement mieux comme methode, mais je ne la trouvais pas plus conne qu'une autre...
 
et puis, de cette facon, meme si ton appli tourne avec plusieurs servlets, elles se partageront le meme context qui contiendra les dites variables. Tu n'auras pas besoin de 'tout faire' dans toutes tes servlets.

alien_nan a écrit a écrit : ce ne sont pas des cochonneries moi, je m'en sers en general pour lire un fichier de proprietés     ensuite, un bean dont le scope est application me permet de les retrouver sans avoir aucune adresse ni chemin en dur dans mon code.   ya certainement mieux comme methode, mais je ne la trouvais pas plus conne qu'une autre...   et puis, de cette facon, meme si ton appli tourne avec plusieurs servlets, elles se partageront le meme context qui contiendra les dites variables. Tu n'auras pas besoin de 'tout faire' dans toutes tes servlets.

oui oui mais le ServletContextListener fait exactement ça, plus proprement

ok, desolé d'avoir repondu a coté alors ...

le reloadable, c'est pas uniquement pour les JSP, hummm ?

 
nan

Nan, deja sorry c'est dans le server.xml bien sur. Ca fait que tomcat surveille les pages jsp ET les classes java, te qu'il recharge toute l'application dès que l'une d'elle est changée.

DarkLord a écrit a écrit : pff je suis à la masse moi.   désolé

C'est rien, j'avais cru que tu voulais sous-entendre que j'avais fait une connerie.

Non, ca marche pas comme ca le reloadable=true.
Ca ne surveille que les classes java et encore, si on change certaines, parfois ca ne redémarre rien du tout et il est dans les choux !
Bref, juste pour dire que si tu changes un JSP, ca va pas recharger toute ton appli, le JSP est juste regénérer en tant que servlet puis ensuite exécuté ...

mais bon il a raison le monsieurs, dans la doc, ca dit que si la class correspondant à une servlet change, ca recharge la webb_app. Mais bon, en pratique, j'ai bien l'impression que ca marche pô

 
sisi, mais pas tout le temps  

HappyHarry a écrit a écrit :   sisi, mais pas tout le temps

bha pour moi, c'est plu jamais que pas tout le temps ...

 
ca marche qd ca veut ca (tomcat 4.0.3)

bha mon tomcat 4.1 est pas très coopératif alors ...

resin rulez

Je connais pas resin ; c'est gratuit aussi ? C'est beaucoup mieux que tomcat ?

c gratuit dans certaines limites
c pas BCP mieux, mais ça me parait plus simple a installer
bon en meme temps, j'ai jamais vraiment essayé tomcat
www.caucho.com

   
en plus, vu que les webapps sont utilisées en interne uniquement, je de vrais pouvoir l'utiliser gratuitement, si j'ai bien compris ?
 
Faut que j'essaye !!!

ouaip
enfin rappelle toi que c qd meme un lent, surtout si tu fais des reload à chaque mini modif

pour info il recharge la web-app à chaud si tu modifies le web.xml aussi.
(pratique quand tu veux reloader une web app sur un hebergement, sans recompiler quoi que ce soit)

Ouai je savais. Le reload je l'utilise avec parcimonie, uniquement dans certains cas de debogage (les cas  :tiens, et si j'enlève cette ligne là, ca marche ?)