Как горячее развертывание работает внутри?

Question

Я использую возможности сервера eclipse для развертывания горячего кода. Использование tomcat в качестве веб-сервера. Но я не уверен, как это работает. У меня есть собственное понимание того, как должно работать .

Мое понимание: -. Когда разработчик делает изменения в коде (скажем, класса Employee), Eclipse разместит/опубликовать измененный скомпилированный класс в нужном месте (должен быть определенный сервер веб/приложение позволяет назвать его горячим каталог развертывания (HDD)) под веб-сервером. Теперь будет загружен специальный загрузчик классов для веб-сервера. Он находит новую запись под HDD. Теперь выясняется, был ли класс уже загружен загрузчиком классов в пространстве perm gen, webserver выгрузит его из пространства перменства и загрузит новый внутри без перезапуска сервера, чтобы отразить новые изменения (байт-код). В рамках перезагрузки web-сервер также свяжет существующие объекты Epmloyee с новым определением класса в пространстве perm gen, чтобы отразить новые изменения.

Правильно ли я это понимаю?

Некоторые ссылки, такие как this, говорят, что горячее развертывание Eclipse - это просто автоматизация перераспределения. что я считаю, это означает, что eclipse автоматически останавливает сервер, повторно публикует и перезапускает его без участия разработчика. Buti Я считаю, что это не так, поскольку этот процесс действительно быстрый по сравнению с запуском/публикацией/перезапуском. Также, если бы это было так, как сеанс и другие живые объекты останутся в живых после перезапуска? Может быть, эта ссылка была правдой в прошлом, но не сейчас, так как я нахожу горячие работы по развертыванию для классов в jar также

Answer 1

Распространение горячего кода зависит от возможностей выполнения. Ответ linked не означает, что автоматизация останавливает развертывание нового кода сервера и снова запускает сервер. Это было бы расточительно.

Вместо этого большинство серверов приложений Java могут использовать . Заменить приложение. Это означает, что сервер создаст новый загрузчик класса веб-приложений, загрузит новую версию приложения этим новым загрузчиком классов, в некоторых случаях он перенесет состояние (сериализовать/десериализовать сеанс HTTP) и отказаться от старой версии приложения ,

Теперь скорость перераспределения зависит от самого приложения - от того, как приложение инициализируется. Нужно ли разводить кеши? Должен ли он удовлетворять зависимостям (a-las Spring, CDI)? Нужно ли инициализировать Hibernate SessionFactory? При этом задействованы многие факторы.

Что естественно делает Eclipse WTP, так это то, что он может инициировать процесс перераспределения для контейнера приложения - вот и все. Конечно, небольшое приложение не займет много времени, чтобы перераспределить.

Если не существует специальной технологии/контейнера/фреймворка, и для Eclipse разработан специальный разъем, позволяющий использовать крючок, который активирует горячий код, обновленный для этой конкретной технологии. Хорошим примером является bndtools для среды исполнения OSGi.

И просто удалить некоторую путаницу:

Часто люди путают HotSwap и горячее развертывание. Первый, HotSwap, - это возможность JVM обновлять определение класса во время выполнения.Последнее, горячее развертывание, - это возможность сервера приложений автоматически развертывать приложение либо поэтапно, либо без него, без перезапуска процесса JVM.

Так что мой ответ о горячем развертывании, а не о HotSwap. Поэтому я говорю о горячем развертывании как о «автоматизации», а не о фундаментальном механизме платформы.