2009-09-07 2 views
12

Können Sie JAR-Dateien auf Tomcat 5 im laufenden Betrieb bereitstellen? Die Idee besteht darin, den Neustart von Tomcat zu vermeiden und trotzdem in der Lage zu sein, (über Reflektion) eine Klasse aus einem neu hinzugefügten JAR zu laden. Kann es getan werden? Wie? Ist es für ein Produktionssystem nicht ratsam? DankeTomcat: Hot-Bereitstellung neuer Gefäße

Bearbeiten: mein Szenario erfordert das Hinzufügen neuer JAR-Dateien, für die die Namen nicht im Voraus bekannt sind. Kann der Server ein Verzeichnis von JARs anstelle von bestimmten JARs "beobachten"?

Antwort

9

Ja, es ist möglich. A few tricks from the Tomcat stable, dass die automatische Bereitstellung angenommen wurde eingeschaltet:

  1. Wenn eine WAR-Datei ein entsprechendes Verzeichnis nicht hat, wird er automatisch erweitert und eingesetzt werden.
  2. Änderungen an WEB-INF \ web.xml führen zum Neuladen der Anwendung.
  3. Updates für WAR-Dateien explodierte eine Umschichtung verursachen
  4. Änderungen an den XML-Konfigurationsdateien sollen eine Umschichtung für Produktionssysteme

Natürlich ist dies nicht ratsam, verursachen. Nicht, dass diese Funktion fehlerhaft ist, aber Anwendungen können schlecht codiert werden, um Ressourcen bei der Bereitstellung nicht zu bereinigen oder Klassen zu entladen. Dies führt dazu, dass bestimmte Klassen im Speicher verbleiben. Wenn die neuere Version der Anwendung erneut bereitgestellt wird, treten vage Fehler aufgrund der älteren Version der Klassen auf. Schlecht geschriebene Singletons sind oft die größte Ursache für dieses Problem. Das Protokoll, das ich befolge, um ähnliche Probleme zu vermeiden, besteht darin, die Anwendung zu deimplementieren, Tomcat herunterzufahren, die 'Gesundheit' der Dateisystemverzeichnisse von Tomcat zu überprüfen, alle zurückgelassenen Ressourcen zu löschen, die Tomcat-Instanz neu zu starten und die Anwendung. Es sieht ein wenig schwer aus, aber ich wurde genug verbrannt.

11

Tomcat bietet keinen Mechanismus zum Nachladen eines einzelnen JAR. Der gesamte Kontext kann jedoch erneut geladen werden.

Sie müssen nur Tomcat sagen für Ihre JAR in context.xml zu sehen, wie diese,

<?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> 

Wir tun dies auf die Produktion. Tomcat hatte einige Speicherlecks, aber wir haben keine Probleme mit Tomcat 5.5 oder höher gefunden.

Weiß nicht, ob es noch notwendig ist. Wir müssen folgende Aufrufe ausführen, um Speicherverluste während der Bereitstellung zu vermeiden.

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(); 
     ... 
    } 
+0

+1 für LogFactory.release() aufrufen. Obwohl ich Apache Commons Logging nicht verwende, ist es Code wie dieser, der das Vertrauen in eine App erhöht. Mehr Infos @http: //wiki.apache.org/jakarta-commons/Logging/UndeployMemoryLeak –

+0

Danke Jungs ... siehe bearbeiten in OP. –