2013-07-02 2 views
21

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

Существует также возможность сделать заказ горячий класс перегрузочный ClassLoader, но я чувствую, что это похоже на «изобретать колесо» если уже так много плагинов, которые могут сделать эту работу .. делать другие люди согласны с этим?

Java-плагинов, которые я нашел, которые я думаю, может сделать эту работу:

Так ли кто-нибудь случится знать, что различия находятся между плагинами? А также какой плагин является самым интуитивным?

В качестве примечания: то, что я на самом деле хочу сделать, это перезагрузить зависимость jar-файла моего приложения Java. У меня есть код java, который очень часто компилируется автоматически, а затем преобразовывается в .jar-файл. Это зависимость моего Java-приложения, и мое приложение должно использовать самую новую версию этого .jar-файла каждый раз.

+1

Вы можете изучить OSGI. Он поддерживает перезагрузку пакетов во время выполнения. –

+2

Ive использовал Jrebel и изумился, насколько хорошо он перезагружает классы в проектах и ​​его зависимостях. Бесплатная социальная лицензия позволяет легко тестировать. JRebel имеет довольно обширную базу пользователей. – vcetinick

+1

Спасибо за ваши комментарии. Я уже смотрю в OSGi и JRebel, я еще не решил, какой из них был бы лучше для меня. Кроме того, я добавлю OSGi в список выше. – PJvG

ответ

29

Отказ от ответственности:Я занимаюсь разработкой JRebel, и поэтому мой ответ может выглядеть немного предвзятым, но я сделаю все возможное, чтобы объяснить.

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

модульность решение, как OSGi или JBoss модулей обеспечивают преимущества, если вы будете следовать правильному пути и модуляризуют приложения. В противном случае, если вы развертываете один комплект силоса, это в основном означает, что вы перезапускаете/перераспределяете все приложение, тем самым уменьшая любые преимущества, получаемые от этого подхода.

Play Framework на самом деле представляет собой полнотекстовую инфраструктуру, которая обладает возможностями «горячего развертывания».Эти возможности различаются в зависимости от версии используемой структуры. Но опять же, такая же история, как и с модулярностью - структура обеспечивает определенную модель программирования.

Apache Commons JCI на самом деле не является решением для быстрого обновления кода. AFAIK, он просто компилирует и загружает класс через новый загрузчик классов. Это также связано с изменением кода приложения, как в случаях, упомянутых выше. Я не уверен, хорошо это или плохо. Недостатком является то, что вы вряд ли можете сделать какую-либо широкую интеграцию с экосистемой таким образом. Такой подход является вполне осуществимым для самодельной структуры, которая использовала бы эту функцию. Я бы предпочел использовать язык сценариев, такой как Groovy, JRuby или JavaScript, для достижения того же. Например, например, this.

JRebel, Fakereplace и DCEVM - эти парни не заботятся о модели программирования. Но разница довольно велика:

DCEVM исправляет JVM, и его цель - предоставить полное решение для горячей замены, которое оно делает.

JRebel - это Java-агент (подключенный с аргументом -javaagent VM), который обрабатывает код приложения и загружает новые версии классов путем их версии. Основное значение JRebel заключается в том, что он обеспечивает гибкую конфигурацию вместе с huge amount of framework specific integrations, так что вы можете сделать намного больше, чем просто hotswap классов java. Например, добавлять и autowire новые бобы в контексте приложения Spring, добавлять новые EJBs на лету, и новые Struts действия и т.д.

Fakereplace также оснащающий агент, как JRebel, но она имеет намного меньше поддержка изменений кода Java (я полагаю), а число поддерживаемых фреймворков не так впечатляет.

Feenix может делать так, как позволяет Java Instrumentation API. Что в основном означает, что на самом деле это не добавляет ценности поверх стандартного HotSwap JVM. То же самое для AgentSmith

UPDATE: этот ответ мотивировано автор Финикса, чтобы придумать новую версию - Финикса 2.0 который напоминает путь JRebel работает с классами. Но, как говорит сам автор, Феникс все еще значительно уступает Джеребу. Есть также несколько аналогичных решений, таких как HotswapAgent и Весна загружена - эти инструменты также обеспечивают аналогичную функциональность, но ограничены по-своему.

Теперь немного о ваших конкретных проблемах, как она может быть решена с JRebel:

Каждого модуль приложения должен иметь свой собственный конфигурационный файл, rebel.xml. Под модулем мы подразумеваем либо EAR, WAR, либо любую из JAR-зависимостей в WEB-INF/lib (например, в вашем случае) или серверных библиотек. Файл конфигурации с указанием каталога, в котором скомпилированы классы, и JRebel будет загружать классы непосредственно из этого местоположения. Это означает, что вам не требуется необходимо собрать весь JAR после внесения изменений в класс Java. Вместо этого вы внесете изменения и скомпилируете источник (используйте IDE вместо скрипта сборки).Скомпилированный класс будет перезагружен JRebel после вызова класса в коде приложения.

+0

Спасибо за подробный ответ! Это очень полезно. Есть ли причина, почему вы не упомянули Apache Commons JCI FAM и AgentSmith в своем ответе? – PJvG

+1

обновил мой ответ –

+0

Поскольку ZeroTurnaround отменяет свою модель с плавающей лицензией, я ищу альтернативы JRebel и нашел этот отличный ответ. Тем временем появляется новый ребенок в блоке: https://github.com/spring-projects/spring-loaded. У него есть свои ограничения, но то, что он делает, хорошо. –

2

В блоке есть новый ребенок, RelProxy, он с открытым исходным кодом, не настолько продвинутый, как JRebel, но его можно использовать, чтобы свободно изменять подмножество вашего кода во время выполнения и перезагружать его практически без штрафа за производительность. необходимость перегрузки контекста (без потери сеанса) в разработке и производстве, если вы хотите.