В общем суть такова.
Есть несложное приложение под web.
Обычный war, Spring+Hibernate+Vaadin, Jetty как контейнер.
Бизнеслогика совсем не сложная.

Но вот приложение понравилось пользователям и его решено перенести на несколько филиалов. "перенести" это громко сказано, просто дали доступ к серваку в корпоративной VPN.
И тут возникла проблема. Эти несколько филиалов работают в разных временных зонах и получается, что приложение востребовано что называется 24/7.
А оно в процессе активной разработки, т.е. часто обновляется и вариант "всех выгнать" и перезалить war выглядит не очень. Пользователи ругаются.
Ну в общем для тех кто "в теме" ситуация должна быть уже ясна.

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

Приложение на данный момент маленькое, время для экспериментов есть, и не составит труда его переписать архитектурно по другому.
Так что мы ничем не ограничены.

oneHalfТо чего ты хочешь называется JRebel, но он, вроде за бабло.

За Jrebel в курсе. Но это немного не то.

Возможно в EJB можно модулями разрабатывать и обновлять на ходу или еще как?
Тот же OSGI... может еще кто пользовался какими радостями...

Может у нас подход совсем неверный... и 1 приложение = 1 war, это хреново и надо его как-то разбивать и по отдельности обновлять.

Интересует проблема в целом так сказать, как делают люди в своей повседневной работе.

ЛагманЕсли у вас сильно меняются классы, как ни крути, придется выгонять (ну или сессии рубить, что в принципе с точки зрения пользователя равноценно).
Вы могли бы разбить приложение на части и связать их через jms+xml например, чтоб деплоить кусочками. В таком случае клиентская часть может просто поджидать ответа сервисной части, пока та редеплоится.

Блин кстати да... JMS мы не рассматривали. А оно походу поможет. Бешеных скоростей не надо. Если разбить на кусочки, то можно через очереди разрулить ситуацию...

СПС