Tomcat: горячая установка новых банок

Можете ли вы развернуть JAR файлы на Tomcat 5? Идея состоит в том, чтобы избежать перезапуска Tomcat и по-прежнему иметь возможность загружать (через отражение) некоторый класс из недавно добавленного JAR. Это можно сделать? Как? Нецелесообразно ли для производственной системы? Благодаря

Изменить. Мой сценарий требует добавления новых файлов JAR, для которых имена неизвестны заранее. Может ли сервер "смотреть" каталог JAR, а не конкретные JAR?

Ответ 1

Tomcat не предоставляет никакого механизма для перезагрузки одного JAR. Однако весь контекст можно перезагрузить.

Вам просто нужно сказать Tomcat, чтобы он смотрел ваш JAR в context.xml, например,

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

Мы делаем это на производстве. У Tomcat были некоторые утечки памяти, но мы не обнаружили никаких проблем с Tomcat 5.5 или новее.

Не знаю, нужна ли она еще. Мы должны сделать следующие вызовы, чтобы избежать утечки памяти во время горячего развертывания.

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

Ответ 2

Да, это возможно. Несколько трюков от стабилизации Tomcat, предполагая, что автоматическое развертывание включено:

Если у WAR файла нет соответствующего каталога, он будет автоматически расширяться и развертываться.
Изменения в WEB-INF\web.xml вызовут перезагрузку приложения.
Обновления для взорванных WAR файлов приведут к перераспределению
Изменения в файлах конфигурации XML должны вызывать перераспределение

Конечно, это нецелесообразно для производственных систем. Не то, что эта функция неисправна, но приложения могут быть плохо закодированы, чтобы не очищать ресурсы или выгружать классы при развертывании. Это приведет к тому, что некоторые классы останутся в памяти. Когда более новая версия приложения будет перераспределена, вы столкнетесь с неопределенными ошибками из-за более старой версии присутствующих классов. Плохо написанные синглтоны часто являются самой большой причиной этой проблемы.

Протокол, который я следую, чтобы избежать подобных проблем, заключается в том, чтобы развернуть приложение, снести Tomcat, проверить "здравомыслие" каталогов файловой системы Tomcat, удалить все оставшиеся ресурсы, перезапустить экземпляр Tomcat и повторно развернуть приложение, Это выглядит немного тяжело, но я был сожжен.