Tomcat: déploiement à chaud de nouveaux fichiers

Question

Pouvez-vous déployer à chaud des fichiers JAR sur Tomcat 5? L'idée est d'éviter de redémarrer Tomcat et de pouvoir charger (par réflexion) une classe d'un JAR nouvellement ajouté. Peut-il être fait? Comment? Est-ce déconseillé pour un système de production? Merci

Édition: mon scénario nécessite l'ajout de nouveaux fichiers JAR pour lesquels les noms ne sont pas connus à l'avance. Le serveur peut-il "regarder" un répertoire de fichiers JAR plutôt que des fichiers JAR spécifiques?

Answer 1

Oui, c'est possible. A few tricks from the Tomcat stable, en supposant que le déploiement automatique a été activé:

1. Si un fichier WAR ne dispose pas d'un répertoire correspondant, il sera étendu automatiquement et déployé.
2. Les modifications de WEB-INF \ web.xml provoquent un rechargement de l'application.
3. Mises à jour explosa fichiers WAR entraînera un redéploiement
4. Les modifications apportées aux fichiers de configuration XML sont censés provoquer un redéploiement

Bien sûr, ce n'est pas recommandé pour les systèmes de production. Non que cette fonctionnalité soit défectueuse, mais les applications peuvent être mal codées pour ne pas nettoyer les ressources ou décharger les classes en cas de non-déploiement. Cela aura pour résultat que certaines classes resteront en mémoire. Lorsque la nouvelle version de l'application est redéployée, vous rencontrerez de vagues erreurs dues à la présence de l'ancienne version des classes. Les singletons mal écrits sont souvent la plus grande cause de ce problème. Pour éviter tout problème similaire, le protocole que je suis consiste à annuler le déploiement de l'application, à supprimer Tomcat, à vérifier la 'santé mentale' des répertoires du système de fichiers de Tomcat, à supprimer les ressources restantes, à redémarrer l'instance Tomcat et à redéployer application. Il a l'air un peu lourd, mais j'ai été assez brûlé.

Answer 2

Tomcat ne fournit aucun mécanisme pour recharger un fichier JAR unique. Cependant, le contexte entier peut être rechargé.

Vous avez juste besoin de dire Tomcat pour surveiller votre JAR dans context.xml, comme celui-ci,

<?xml version="1.0" encoding="UTF-8"?> 
<Context override="true" swallowOutput="true" useNaming="false"> 
    <WatchedResource>WEB-INF/web.xml</WatchedResource> 
    <WatchedResource>WEB-INF/lib/your.jar</WatchedResource> 
    <Manager pathname=""/> 
</Context> 

Nous le faisons sur la production. Tomcat avait l'habitude d'avoir quelques fuites de mémoire mais nous n'avons trouvé aucun problème avec Tomcat 5.5 ou plus tard.

Je ne sais pas si c'est encore nécessaire. Nous devons faire les appels suivants pour éviter les fuites de mémoire lors du déploiement à chaud.

public void contextDestroyed(ServletContextEvent sce) { 
     // To fix the known memory leaks during re-deploy 
     ClassLoader contextClassLoader = 
      Thread.currentThread().getContextClassLoader(); 
     LogFactory.release(contextClassLoader); 

     java.beans.Introspector.flushCaches(); 
     ... 
    }