Можно ли обновить веб-приложение на Java, заменив только файлы одного класса?

Question

Иногда, когда мы делаем небольшие изменения в наших веб-приложениях, например Исправления ошибок: мы не создаем целый новый WAR-файл каждый раз, а просто заменяем только файлы затронутых классов в разобранном каталоге веб-приложения в WEB-INF/classes и перезапускаем приложение.

Это нормально?

Answer 1

Я бы сказал, что, вероятно, это не лучшая практика из-за управления версиями: откуда вы знаете, какую версию приложения вы развернули? Если вы развертываете .war-файл, ваш процесс сборки может позаботиться об обновлении номера сборки (из системы контроля версий или отдельно, как угодно - до тех пор, пока у каждой сборки свой номер, это нормально).

Если вы используете непрерывную интеграцию (и это определенно хорошая идея), тогда процесс сборки должен выводить «артефакт» (файл войны) каждый раз, когда вы вносите изменения в исходный код. также возможно пометить код в управлении версиями номером сборки.

Итак, когда вы развертываете свое веб-приложение, вы точно знаете, какая версия запущена и какой исходный код составляет эту версию.

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

Answer 2

@ Фил Сакре и другие затронули большинство аспектов этого вопроса. Я столкнулся с другим аспектом и хотел бы внести свой вклад.

Краткий ответ: Нет, может быть недостаточно заменить только файлы классов для измененных файлов Java. Продолжайте читать для деталей.

Вот мой сценарий.

• У меня был .java, содержащий в основном SQL-запросы. Я изменил один запрос, поместил новый файл .class и сбросил Tomcat (не подключен к моей IDE). Предыдущий запрос все еще выполнялся.
• Когда я заменил все файлы .class, выполнялся новый запрос.

Для диагностики,

• Я взял две сборки maven и произвел сравнение каталогов.
• К моему удивлению, я обнаружил, что файлы 2 .class вместо 1 были изменены.
  • Этот дополнительный файл .class фактически использовал измененный файл .class.
• Когда я посмотрел декомпилированную версию дополнительного файла .class, я обнаружил, что SQL-запрос (строка) был там как inline .

Это ясно объясняет, почему замена одного класса не решила проблему. Замена первого файла .class в этом случае не будет эффективной.

Извлеченные уроки. Вот как я суммировал свое обучение из этого:

• Во время разработки IDE (я использую Eclipse) заботится о горячем развертывании.
• В производственных системах было бы неразумно предполагать, что достаточно заменить только один файл .class. Следует рассмотреть возможность полного развертывания.

Answer 3

Вы можете решать задачи развертывания, используя maven.

Каждый раз, когда вы что-то меняете, просто наберите

svn update
mvn clean compile war:exploded tomcat:inplace -P deployment

в вашем файле pom.xml есть профиль развертывания, содержащий все настройки, необходимые для среды развертывания.

таким образом, вы можете автоматизировать процесс развертывания и никогда не потерпеть неудачу при ручном копировании неправильных / старых / etc файлов.

Answer 4

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

Answer 5

Технически говоря, если сигнатуры классов / методов одинаковы, это должно работать. Но, как отмечает Фил, это не лучшая идея в мире.

Я предполагаю, что вы не используете Apache Ant и Apache Maven для создания вашего .war-файла. Я настоятельно рекомендую вам выбрать инструмент, который может автоматизировать создание файла .war, именно для того, чтобы избежать таких ручных взломов, о которых вы говорите. Я лично использую Maven, и он заботится о компиляции, запуске модульных тестов и упаковке моего приложения. Хорошие вещи :) 1007 *

Answer 6

Согласен с PHill; кажется, что экономия времени незначительна, а потенциальные риски очень велики