Отказ от ответственности. Я участвую в разработке JRebel, поэтому мой ответ может показаться немного предвзятым, но я постараюсь объяснить.
Чтобы ответить на этот вопрос, я сначала хочу обратить ваше внимание на то, что одно из основных отличий среди названий, которые вы перечислили, состоит в том, что некоторые решения требуют от вас изменения дизайна приложения, другие - нет.
Решения модульности, такие как OSGi или модули JBoss, дают преимущества, если вы следуете правильному пути и модулируете свое приложение. В противном случае, если вы развертываете один изолированный пакет, это в основном означает, что вы перезапускаете/повторно развертываете все приложение, тем самым уменьшая любые преимущества, полученные от этого подхода.
Play Framework на самом деле представляет собой полнофункциональную платформу с возможностью горячего развертывания. Эти возможности различаются в зависимости от используемой версии фреймворка. Но опять же, та же история, что и с модульностью — фреймворк навязывает определенную модель программирования.
Apache Commons JCI на самом деле не является решением для оперативного обновления кода. Насколько я знаю, он просто компилирует и загружает класс через новый загрузчик классов. Это также включает в себя изменение кода приложения, как в случаях, упомянутых выше. Я не совсем уверен, хорошо это или плохо. Недостатком является то, что вы вряд ли сможете сделать какую-либо широкую интеграцию с экосистемой таким образом. Такой подход вполне осуществим для самодельного фреймворка, использующего эту функцию. Лично я бы предпочел использовать язык сценариев, такой как Groovy, JRuby или JavaScript, для достижения того же. Например, что-то вроде этого.
JRebel, Fakereplace и DCEVM — этим ребятам наплевать на модель программирования. Но разница довольно большая:
DCEVM исправляет JVM, и его цель — предоставить полное решение для горячей замены, что она и делает.
JRebel – это Java-агент (подключенный с помощью аргумента -javaagent VM), который обрабатывает код приложения и загружает новые версии классов, управляя их версиями. Основная ценность JRebel заключается в том, что он обеспечивает гибкую настройку наряду с огромным количеством интеграций с конкретными фреймворками, так что вы можете делать намного больше, чем просто горячая замена классов Java. Например, добавляйте и автоматически связывайте новые bean-компоненты в контексте приложения Spring, добавляйте новые EJB на лету, новые действия Struts и т. д.
Fakereplace также является инструментальным агентом, как и JRebel, но он гораздо меньше поддерживает изменения кода Java (я полагаю), а количество поддерживаемых фреймворков не так впечатляет.
Fenix может делать столько, сколько позволяет ему Java Instrumentation API. Что в основном означает, что на самом деле он не добавляет ценности поверх стандартного HotSwap JVM. То же самое для AgentSmith
ОБНОВЛЕНИЕ: этот ответ побудил автора Feenix придумать новую версию - Feenix 2.0, которая напоминает способ работы JRebel с классами. Но как говорит сам автор - Feenix все равно сильно уступает JRebel. Есть также несколько похожих решений, таких как HotswapAgent и Spring Loaded — эти инструменты также предоставляют аналогичные функции, но по-своему ограничены.
Теперь немного о вашей конкретной проблеме, как ее можно решить с помощью JRebel:
Каждый модуль приложения должен иметь собственный файл конфигурации rebel.xml. Под модулем мы подразумеваем либо EAR, WAR, либо любую из JAR-зависимостей в WEB-INF/lib (как в вашем случае), либо специфичные для сервера библиотеки. Файл конфигурации указывает на каталог, в котором находятся скомпилированные классы, и JRebel загрузит классы непосредственно из этого места. Все это означает, что вам не нужно собирать весь JAR после внесения изменений в класс Java. Вместо этого вы вносите изменения и компилируете исходный код (используя IDE вместо скрипта сборки). Скомпилированный класс будет перезагружен JRebel после вызова класса в коде приложения.
person
Anton Arhipov
schedule
14.07.2013
