Задача:
Нужно автоматизировать рабочее место пользователя, который имеет ноутбук и медленный 3G/edge и часто даже просто отсутствующий интернет. Пользователь должен не зависимо от наличия интернета редактировать свои простые документы и периодически заливать на сервер, заодно обновляя справочную информацию.
Доступа к ноутбуку пользователя не будет и даже если будет, то админить каждый ноут будет очень накладно по времени, т.к. может быть 100+ пользователей.
Требования:
1. Web-интерфейс, потому что он наиболее rich, кросс-платформенный и под него полно дизайнеров
2. Приложение должно легко устанавливаться и обновляться (одной кнопкой)
3. Приложение должно сохранять вводимые специалистом данные в in-process базу и по мере наличия интернета "синхронизироваться" с основной базой.
1 Вариант решения:
Написать приложение-сервис, которое хостит в себе веб-севис (Jetty) с сайтом (на Grails) и базу (H2 / Mongo).
Плюс, отдельное update-приложение, которое занимается обновлением сервиса — останавливает сервис, поднимать рядом новую версию сервиса, накатывать на базу миграции, проверяет работоспособность поднятого, удаляет старое и если что — все корректно откатывает и т.д.
Меня смущает такой способ обновления по нескольким причинам:
1. Сложность написания приложения без ошибок и трудность автоматизации тестирования обновления (время разработки может растянуться на неопределенный срок)
2. В случае бага, падения update-приложения, разрядки батареи ноута и т.д. возможна ситауция, когда работа приложения не будет восстановлена и пользователь не сможет работать с приложением, а это критично для бизнеса, а так же не просто будет выяснить как именно все сломалось и написать приложение для восстанавления работы сломанного приложения.
2 Вариант решения:
(сразу скажу, что в Java опыта нет, но прилично пописал в .net, поэтому делайте скидку на случай бредовости решения)
Вместо сервиса сделать standalone-приложение, которое не только хостит в себе веб-сервер и базу, но и окно в котором хоститься браузер (ui-элемент), который в себе отображает хостящийся сайт.
Для обновления использовать Web Start (jnlp). База будет лежать рядом вне jnlp-файла.
При обновлении jnlp-приложения (на сколько я понимаю механизм уже хорошо отлажен) и первом запуске обновленного приложения будет проверяться версия базы и если нужно — накатываться миграции.
Тут все выглядит проще и надежнее (для меня):
— не нужно писать свой механизм обновления
— не нужно посылать пользователя в браузер по урлу localhost:xxxx — он просто работает с приложением
— не нужно писать сервис, который сложнее в администрировании, отладке и обновлении (могут требоваться перезагрузки)
— если что-то сломается, можно обновить jnlp файл, он автоматом обновится у пользователя и все заработает как надо (хотя фаза выяснения состояния сломанного приложения на ноуте пользователя все равно есть и может сильно все усложнять).

Вопросы:
1. На сколько рабочий 1 вариант решения?
1. На сколько состоятелен 2 вариант решения?
2. Какие более простые способы есть написания такого типа приложения? Из ограничений — JVM и open source.

Здравствуйте, Keith, Вы писали:

K>1. На сколько рабочий 1 вариант решения?

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

K>1. На сколько состоятелен 2 вариант решения?

Получше, но если не писал GUI на Java ты затрахаешься.

K>2. Какие более простые способы есть написания такого типа приложения? Из ограничений — JVM и open source.

HTML 5 Rich UI. Пока связь есть работаем с сервером. Связь пропала начинаем работать с WebDB и Local Storage. Связь вернулась, синхронизуемся с сервером. GWT все это умеет из коробки.

Здравствуйте, Keith, Вы писали:

1 Вариант решения:
Немного не понял что означает приложение-сервис.
Допустим у вас будет приложение в виде сервера (Jetty) поднятого локально с сайтом (на Grails) и базой (H2 / Mongo).
Работать будет все время с локальной базой. По шедулеру, скажем раз в час, или по явной просьбе юзера производится синхронизация базы (если есть интернет).
Далее по шедулеру будет чекать новую версию. Если есть, то скачивается архив с сервером и sql сприпт обновления.
Удалось скачать? Если да то информируем пользователся, что есть новая версия, хотите обновить и перезапустить?
Далее выполняется скрипт обновления который:
1) делаем копию базы.
2) применяем скрипт обновления базы. -> если все ок считаем что скрипт рабочий
2) поднимает новую версию на копию базы (на другом порте)
3) дергает REST api основных сервисов для проверки работоспособности.
Если все ОК тогда
4) Тушим основной сервер.
5) делаем swap между основной версией севера/базы и копией.
Теперь у нас старая версия вместе со старой базой хранятся на всякий случай, если что-то пойдет не так, всегда можно будет вернуться к ним.
5) Поднимаем сервер.

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

Мерж базы тоже должен быть таким, чтобы если отпадет интернет база не осталась в неконсистентном состоянии.
И его можно было продолжить с той же точки, когда интернет появится. Это отдельная тема, надо подумать..
Желательно больше информации о структуре базы.

K>>1. На сколько состоятелен 2 вариант решения?
А>Получше, но если не писал GUI на Java ты затрахаешься.

А в чем, собственно, проблема? Писал на WinForms, оно сильно отличается?
Тем более там приложение-то — одно окно с браузером (контрол) на все окно, а втури этого браузера уже сайт.

K>>2. Какие более простые способы есть написания такого типа приложения? Из ограничений — JVM и open source.
А>HTML 5 Rich UI. Пока связь есть работаем с сервером. Связь пропала начинаем работать с WebDB и Local Storage. Связь вернулась, синхронизуемся с сервером. GWT все это умеет из коробки.

1. А можно html 5 приложение запустить без интернета? Он локально кэширует страницы или все страницы упакованы в некий package?
2. На гугл неохота завязываться, он себя в последнее время плохо ведет.

Здравствуйте, GreenTea, Вы писали:

GT>1 Вариант решения:
GT>Немного не понял что означает приложение-сервис.

Имел ввиду такой сервис.

GT>Допустим у вас будет приложение в виде сервера (Jetty) поднятого локально с сайтом (на Grails) и базой (H2 / Mongo).
GT>Работать будет все время с локальной базой. По шедулеру, скажем раз в час, или по явной просьбе юзера производится синхронизация базы (если есть интернет).
GT>Далее по шедулеру будет чекать новую версию. Если есть, то скачивается архив с сервером и sql сприпт обновления.
GT>Удалось скачать? Если да то информируем пользователся, что есть новая версия, хотите обновить и перезапустить?
GT>Далее выполняется скрипт обновления который:
GT>1) делаем копию базы.
[поскипал]
GT>5) Поднимаем сервер.

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

GT>И его можно было продолжить с той же точки, когда интернет появится. Это отдельная тема, надо подумать..
GT>Желательно больше информации о структуре базы.

Структура базы вроде не сложная пока, но пути заказчика неиповедимы, поэтому ограничивать себя в этом не хотелось бы.
Пока что структура такая — несколько справочников, которые подтягиваются из центрального хранилища и набор иерархических документов,
которые создает пользователь. Это чем-то похоже на evernote.

А что на счет варианта №2?

Здравствуйте, Keith, Вы писали:

K>1. А можно html 5 приложение запустить без интернета? Он локально кэширует страницы или все страницы упакованы в некий package?

Можно. Оно выкачивает и кэширует все страницы указанные в кэш-манифесте.

K>2. На гугл неохота завязываться, он себя в последнее время плохо ведет.

HTML5 не имеет отношения к гуглу. Можно хоть руками на голом JS писать. Кстати, если взять extjs, то это будет даже удобно.

Здравствуйте, Miroff, Вы писали:

K>>1. А можно html 5 приложение запустить без интернета? Он локально кэширует страницы или все страницы упакованы в некий package?
M>Можно. Оно выкачивает и кэширует все страницы указанные в кэш-манифесте.
K>>2. На гугл неохота завязываться, он себя в последнее время плохо ведет.
M>HTML5 не имеет отношения к гуглу. Можно хоть руками на голом JS писать. Кстати, если взять extjs, то это будет даже удобно.

Я имел ввиду, что GWT не охота, хотя вариант интересный, учитывая, что GWT-сайт можно собрать в war и захостить где угодно, не завися от гугла.

На сколько легко писать приложение чистом HTML 5 + JS , которое работает то с локальной базой, то с удаленным сервисом?
Видимо, нужно написать два DAL'а — один для локального хранилища, другой для сервисов удаленной базы и в процессе работы проверять интернет и разруливать куда писать.
А кэш обновляется сам, когда размер страницы меняется или по времени?
А миграции к структуре локального хранилища из коробки есть? Или нужно самому вести историю миграций?

Здравствуйте, Keith, Вы писали:

K>Я имел ввиду, что GWT не охота, хотя вариант интересный, учитывая, что GWT-сайт можно собрать в war и захостить где угодно, не завися от гугла.
Google уже фактически бросил GWT. Сейчас его поддержкой активно занимается Vaadin.
http://googlewebtoolkit.blogspot.ru/2012/09/gwt-survey.html

Здравствуйте, Keith, Вы писали:

K>Я имел ввиду, что GWT не охота, хотя вариант интересный, учитывая, что GWT-сайт можно собрать в war и захостить где угодно, не завися от гугла.

Лично мне GWT не нравится из-за чрезмерной переусложненности и завязанности на вендора.

K>На сколько легко писать приложение чистом HTML 5 + JS , которое работает то с локальной базой, то с удаленным сервисом?

Не особенно сложно, но лучше все же использовать какую-нибудь библиотеку.

K>Видимо, нужно написать два DAL'а — один для локального хранилища, другой для сервисов удаленной базы и в процессе работы проверять интернет и разруливать куда писать.

Я бы сделал один слой доступа к данным внутри которого разруливал все вопросы синхронизации локального и удаленного хранилища.

K>А кэш обновляется сам, когда размер страницы меняется или по времени?

Почитай спеку, там есть разные режимы.

K>А миграции к структуре локального хранилища из коробки есть? Или нужно самому вести историю миграций?

Самому. А вообще из локальной базы легким движением руки делается no sql хранилище которое при правильном использовании не требует миграций.

Здравствуйте, Keith, Вы писали:

K>2. Какие более простые способы есть написания такого типа приложения? Из ограничений — JVM и open source.

Серверная часть стандартная, в ней вопросов нет. Как я вижу проблема именно с UI. Попробуйте посмотрет в сторону Adobe Flex/AIR. Интерфейс там программировать на много приятнее чам на HTML/JS и уж тем более чем на Java. Сама технология по своей идее очень похожа на HTML/JS. С одной стороны вы получите интерфейс не хуже десктопного, с другой нет проблем с кроссбраузерностью и обновлениями, т.к. все работает во Флэш Плеере. Сама Флекс СДК — бесплатная, платные только среды разработки. Я с Флекс Билдером работал, есть еще для идеи надстройка.

K>А что на счет варианта №2?

Я его не очень понял. Веб стартовое приложение с окном браузера, допустим понятно, но еще нужен сервер + веб приложение, правильно я понимаю? Их тоже закачивать вебстартом? Я честно говоря слабо такое представляю. Ничего вроде не упрощается, все проверки при обновлении апликухи/базы остаются.

по поводу варианта 1 понимаю что сложно.. Да и 1 север на 1 клиента поднимать как то стремно. Чтобы проще, надо делать десктопную апликуху. Может стоит посмотреть в сторону osgi. Тогда, если правильно разбить на модули (бандлы), то можно будет отдельные изменившиеся бандлы подгружать в реальном времени и обновлять без перезапуска всего приложения. GUI swing на джаве писать не так уже и сложно, был опыт. Также можно обратить внимание на java fx.

Здравствуйте, noofiz, Вы писали:

K>>2. Какие более простые способы есть написания такого типа приложения? Из ограничений — JVM и open source.

N>Серверная часть стандартная, в ней вопросов нет. Как я вижу проблема именно с UI. Попробуйте посмотрет в сторону Adobe Flex/AIR. Интерфейс там программировать на много приятнее чам на HTML/JS и уж тем более чем на Java. Сама технология по своей идее очень похожа на HTML/JS. С одной стороны вы получите интерфейс не хуже десктопного, с другой нет проблем с кроссбраузерностью и обновлениями, т.к. все работает во Флэш Плеере. Сама Флекс СДК — бесплатная, платные только среды разработки. Я с Флекс Билдером работал, есть еще для идеи надстройка.

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

Здравствуйте, GreenTea, Вы писали:

K>>А что на счет варианта №2?
GT>Я его не очень понял. Веб стартовое приложение с окном браузера, допустим понятно, но еще нужен сервер + веб приложение, правильно я понимаю? Их тоже закачивать вебстартом? Я честно говоря слабо такое представляю.

Да, и веб-сервер с сайтом будут хоститься в том же приложении с окном браузера.
Т.е. состав приложения такой:
1. Standalone-приложение: втроенный веб-сервер с сайтом, встроенная база. Все это внутри jnlp, который и обновляется.
2. Файл базы с данными. Лежит рядом и не обновляется.
При запуске приложения проверяется версия базы и если она более древняя, то накатываются миграции.
Процесс обновления ложится полностью на Web Start, который стабилен и отлажен.
Мне остается только собирать новые версии приложений и выкладывать "в паблик", чтобы Web Start сам обновил приложение по возможности.

GT>Ничего вроде не упрощается, все проверки при обновлении апликухи/базы остаются.
Проще тем, что:
— нет приложения-сервиса, которое писать и админить далеко не так просто как standalone.
— нет самописного механизма обновления, который долго писать/отлаживать и ошибки в котором стоят очень дорого.

GT>по поводу варианта 1 понимаю что сложно.. Да и 1 север на 1 клиента поднимать как то стремно.
GT>Чтобы проще, надо делать десктопную апликуху.
Я тоже так считаю.

GT>Может стоит посмотреть в сторону osgi.
Смотрел, но сходу не понял как оно работает.
Вроде менеджера пакетов на стороне клиента, который может подтягивать указанные в конфиге зависимости?
Можете на пальцах описать как его тут можно прикрутить?

GT>Тогда, если правильно разбить на модули (бандлы), то можно будет отдельные изменившиеся бандлы подгружать в реальном времени и обновлять без перезапуска всего приложения.
Ну мне не обязательно без перезагрузки, можно и при запуске приложения обновится, если есть что обновить.
И разные пакеты подтягивать мне не обязательно и даже проще было бы с одним пакетом типа jnlp.

GT>GUI swing на джаве писать не так уже и сложно, был опыт. Также можно обратить внимание на java fx.
А с WinForms в .net можете сравнить?
Вообще, gui должен быть на html — это одно из главных требований, поэтому и предполагается внутри десктопного приложения хостить веб-сервер с сайтом.

Здравствуйте, Keith, Вы писали:

K>1. Standalone-приложение: втроенный веб-сервер с сайтом, встроенная база. Все это внутри jnlp, который и обновляется.
Небольшая поправка — jnlp будет отдельно от основного jar-файла, котороый уже будет содержать в себе все необходимое.
Я в Web Start только разбираюсь...

Здравствуйте, Keith, Вы писали:

K>2. В случае бага, падения update-приложения, разрядки батареи ноута и т.д. возможна ситауция, когда работа приложения не будет восстановлена и пользователь не сможет работать с приложением, а это критично для бизнеса, а так же не просто будет выяснить как именно все сломалось и написать приложение для восстанавления работы сломанного приложения.
Все данные хранятся в СУБД, синхронизация данных — берём symmetricds. Должна быть возможность загрузить чистую базу с сервера, если вдруг поломалась клиентская.
Изменение структуры БД — liquibase/аналоги.
Приложение, если не сильно увесистое, запаковать в один jar-файл — обновлять целиком, при проблемах — использовать предыдущий.
Т.е. все изменения транзакционные — если что-то прервалось, продолжится дальше, либо будет работать старое.

Здравствуйте, ., Вы писали:

K>>2. В случае бага, падения update-приложения, разрядки батареи ноута и т.д. возможна ситауция, когда работа приложения не будет восстановлена и пользователь не сможет работать с приложением, а это критично для бизнеса, а так же не просто будет выяснить как именно все сломалось и написать приложение для восстанавления работы сломанного приложения.
.>Все данные хранятся в СУБД, синхронизация данных — берём symmetricds.

Спасибо за symmetricds — очень интересная штука.

.>Должна быть возможность загрузить чистую базу с сервера, если вдруг поломалась клиентская.

Потеря данных критична для бизнеса, т.е. базу нужно в таком случае чинить.

.>Изменение структуры БД — liquibase/аналоги.

О, еще одна интересная библиотека, спасибо!

.>Приложение, если не сильно увесистое, запаковать в один jar-файл — обновлять целиком, при проблемах — использовать предыдущий.
.>Т.е. все изменения транзакционные — если что-то прервалось, продолжится дальше, либо будет работать старое.

А механизм для обновлений какой использовать? Свой писать или Web Start / аналоги ?

Здравствуйте, Keith, Вы писали:

K>Здравствуйте, Keith, Вы писали:

K>>1. Standalone-приложение: втроенный веб-сервер с сайтом, встроенная база. Все это внутри jnlp, который и обновляется.
K>Небольшая поправка — jnlp будет отдельно от основного jar-файла, котороый уже будет содержать в себе все необходимое.
K>Я в Web Start только разбираюсь...

Я с веб стартом не работал, но.. надеятся что он магическим образом все обновит не стал бы. А если новая версия окажется не рабочая (изза ошибка программиста)? То откатить на старую не получится же.
"При обновлении jnlp-приложения (на сколько я понимаю механизм уже хорошо отлажен) и первом запуске обновленного приложения будет проверяться версия базы и если нужно — накатываться миграции." А если накатить миграции не удалось (по ошибке программиста) а новая версия уже не может работать со старой базой? jnlp не спасет от всего этого.. Ваша задача не стандартная. Не думаю что есть стандартный инструмент для решения нестандартной задачи.

osgi поможет, если приложение будет разрастаться, не обновлять его целиком. А так же может обновлять бандлы без перезапуска всего приложения (бывает ему все же не удается), тогда уже надо перезапускать.
Между бандлами явно прописываются зависимости, чтобы osgi контейнер их разрулил при апдейте. Например если обновляется бандл B и от него зависит A, то A приостанавливается, B обновляется, и A перезапускается уже ссылаясь на новую версию B. Между собой бандлы взаимодействуют через специальные интерфейсы. Мы на работе пишем веб приложение на osgi, все круто сейчас, но стоила эта архитектура большой крови. Т.к. в идеале используемые либы и фреймворки должны быть osgi-ные, а это не всегда так. Приходится извращаться. Еще много либ, неявно полагают что работают с одним класслоадером, в osgi же каждый бандл имеет свой. Если у вас мало опыта в java я бы не стал браться реализовывать первый проект на osgi, это надо хорошо шарить во внутренней структуре jvm. Так же надо неслабо голову поломать по поводу того как именно / по какому принципу разбивать приложение на бандлы. Можно бить горизонально, можно вертикально, можно по диагонали

В javafx у меня опыта совсем не много. По идее в нем можно рисовать очень красивые интерфейсы, а рендерится будет видеокартой. Разметка конечно не html, но вот только что загуглил http://docs.oracle.com/javafx/2/webview/jfxpub-webview.htm, т.е. можно делать html вставки.. С возможностью взаимодействия джаваскрипта на html страницах с апликухой на javafx, в обоих направления. Возможно таким макаром получится реализовать весь интерфейс.

Здравствуйте, Keith, Вы писали:

K>Здравствуйте, ., Вы писали:

K>>>2. В случае бага, падения update-приложения, разрядки батареи ноута и т.д. возможна ситауция, когда работа приложения не будет восстановлена и пользователь не сможет работать с приложением, а это критично для бизнеса, а так же не просто будет выяснить как именно все сломалось и написать приложение для восстанавления работы сломанного приложения.
.>>Все данные хранятся в СУБД, синхронизация данных — берём symmetricds.
K>Спасибо за symmetricds — очень интересная штука.
Мы использовали — работает. Но мы допиливали под наши условия. Идея там правильная для некоторых типов приложений, но надо хорошо продумать что там с чем будет обмениваться, использовать приёмы построения распределённых систем.

.>>Должна быть возможность загрузить чистую базу с сервера, если вдруг поломалась клиентская.
K>Потеря данных критична для бизнеса, т.е. базу нужно в таком случае чинить.
Это таки редкая вещь, если субд спроектирована правильно, целостность поддерживается. Это случается не чаще, чем поломалось-потерялось железо.
Рекомендуйте пользователям синхронизироваться почаще, и как-то хорошо давайте знать, что пока не ушло на сервер — критичным для бизнеса быть не должно, ибо клиентское железо сделать надёжным невозможно.

.>>Приложение, если не сильно увесистое, запаковать в один jar-файл — обновлять целиком, при проблемах — использовать предыдущий.
.>>Т.е. все изменения транзакционные — если что-то прервалось, продолжится дальше, либо будет работать старое.
K>А механизм для обновлений какой использовать? Свой писать или Web Start / аналоги ?
Веб-старт в принципе работает... но глючный он какой-то и старый. Можете с него начать, но, думаю, несложно будет перейти на что-то своё.

Здравствуйте, GreenTea, Вы писали:

GT>Я с веб стартом не работал, но.. надеятся что он магическим образом все обновит не стал бы.
GT>А если новая версия окажется не рабочая (изза ошибка программиста)?
GT>То откатить на старую не получится же.

Не получится, но разработчик может выложить исправленное приложение и оно автоматом обновится. В теории, я пока только разбираюсь с Web Start.

K>"При обновлении jnlp-приложения (на сколько я понимаю механизм уже хорошо отлажен) и первом запуске обновленного приложения будет проверяться версия базы и если нужно — накатываться миграции."
GT>А если накатить миграции не удалось (по ошибке программиста) а новая версия уже не может работать со старой базой?

Похожая ситуация — разработчик выясняет почему не удалось накатить миграции и выкладывает новую версию, которая уже накатывает миграции.

GT>jnlp не спасет от всего этого..

Да, но он спасет от написания своего механизма обновления, который, на мой взгляд, довольно тяжело написать и отладить самостоятельно.

GT>Ваша задача не стандартная. Не думаю что есть стандартный инструмент для решения нестандартной задачи.

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

GT>osgi поможет, если приложение будет разрастаться, не обновлять его целиком. А так же может обновлять бандлы без перезапуска всего приложения (бывает ему все же не удается), тогда уже надо перезапускать.
GT>Между бандлами явно прописываются зависимости, чтобы osgi контейнер их разрулил при апдейте. Например если обновляется бандл B и от него зависит A, то A приостанавливается, B обновляется, и A перезапускается уже ссылаясь на новую версию B. Между собой бандлы взаимодействуют через специальные интерфейсы. Мы на работе пишем веб приложение на osgi, все круто сейчас, но стоила эта архитектура большой крови. Т.к. в идеале используемые либы и фреймворки должны быть osgi-ные, а это не всегда так. Приходится извращаться. Еще много либ, неявно полагают что работают с одним класслоадером, в osgi же каждый бандл имеет свой. Если у вас мало опыта в java я бы не стал браться реализовывать первый проект на osgi, это надо хорошо шарить во внутренней структуре jvm. Так же надо неслабо голову поломать по поводу того как именно / по какому принципу разбивать приложение на бандлы. Можно бить горизонально, можно вертикально, можно по диагонали

Да, это я, похоже, не осилю без опыта в Java.

GT>В javafx у меня опыта совсем не много. По идее в нем можно рисовать очень красивые интерфейсы, а рендерится будет видеокартой. Разметка конечно не html, но вот только что загуглил http://docs.oracle.com/javafx/2/webview/jfxpub-webview.htm, т.е. можно делать html вставки.. С возможностью взаимодействия джаваскрипта на html страницах с апликухой на javafx, в обоих направления. Возможно таким макаром получится реализовать весь интерфейс.

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

Здравствуйте, ., Вы писали:

K>>>>2. В случае бага, падения update-приложения, разрядки батареи ноута и т.д. возможна ситауция, когда работа приложения не будет восстановлена и пользователь не сможет работать с приложением, а это критично для бизнеса, а так же не просто будет выяснить как именно все сломалось и написать приложение для восстанавления работы сломанного приложения.
.>>>Все данные хранятся в СУБД, синхронизация данных — берём symmetricds.
K>>Спасибо за symmetricds — очень интересная штука.
.>Мы использовали — работает. Но мы допиливали под наши условия. Идея там правильная для некоторых типов приложений, но надо хорошо продумать что там с чем будет обмениваться, использовать приёмы построения распределённых систем.

А можно вкратце как там разруливается синхронизация структуры с циклическими зависимостями?
Оно умеет само внутри одной транзакции снимать foreign key'и, заливать данные, восстанавливать foreign key'и?
Как происходит разруливание конфликтов при, например, иземнении структуры или основных таблиц типа справочников?
Вообще — тема очень интересная, но очень сложная, удивлен, что кто-то написал такую либу для любых структур данных..
У микрософта есть Sync, но тот очень громоздкий и примитивный — все на тригерах, структуру обновлять нельзя и если что-то сломается, то хрен починишь.

.>>>Приложение, если не сильно увесистое, запаковать в один jar-файл — обновлять целиком, при проблемах — использовать предыдущий.
.>>>Т.е. все изменения транзакционные — если что-то прервалось, продолжится дальше, либо будет работать старое.
K>>А механизм для обновлений какой использовать? Свой писать или Web Start / аналоги ?
.>Веб-старт в принципе работает... но глючный он какой-то и старый. Можете с него начать, но, думаю, несложно будет перейти на что-то своё.

Спасибо за мнение, решил пока с ним разобраться, а дальше буду смотреть...

Здравствуйте, Keith, Вы писали:

.>>Мы использовали — работает. Но мы допиливали под наши условия. Идея там правильная для некоторых типов приложений, но надо хорошо продумать что там с чем будет обмениваться, использовать приёмы построения распределённых систем.
K>А можно вкратце как там разруливается синхронизация структуры с циклическими зависимостями?
K>Оно умеет само внутри одной транзакции снимать foreign key'и, заливать данные, восстанавливать foreign key'и?
K>Как происходит разруливание конфликтов при, например, иземнении структуры или основных таблиц типа справочников?
K>Вообще — тема очень интересная, но очень сложная, удивлен, что кто-то написал такую либу для любых структур данных..
K>У микрософта есть Sync, но тот очень громоздкий и примитивный — все на тригерах, структуру обновлять нельзя и если что-то сломается, то хрен починишь.
Оно тоже работает на основе триггеров. Но не громоздкий, и, по-моему, довольно простой. Изменения структуры решается версированием структуры данных.
Все модифицирующие запросы — insert/update/delete — записываются в упорядоченный лог. Потом этот лог отправляется клиентам и они проигрывают ровно те же изменения на тех же данных в ровно том же порядке, и т.к. это всё сработало в одном месте, сработает и в другом. Поэтому никаких сниманий foreign key нет и не надо. Одно надо — хорошо продумать структуру данных, чтобы она была централизована на сервере или создавалась клиентами безконфликтно, возможно придётся вводить какие-то механизмы мержей. Например, если 2 клиента добавили одно и то же значение в справочник, то ID изначально должны быть разные (вообще в качестве ID в распределённых системах должен быть UUID), появится дубликат, но можно сделать механизм схлопывания дубликатов (и этим будет заниматься сервер централизовано, чтобы избежать конфликтов).
Хотя на самом деле когда мы это применяли, у нас изменением данных в БД занимался только сервер, а клиентские БД были read-only, т.е. просто кеш. Но принцип вроде такой же.

.>>Веб-старт в принципе работает... но глючный он какой-то и старый. Можете с него начать, но, думаю, несложно будет перейти на что-то своё.
K>Спасибо за мнение, решил пока с ним разобраться, а дальше буду смотреть...

Здравствуйте, Keith, Вы писали:

K>1. Web-интерфейс, потому что он наиболее rich, кросс-платформенный и под него полно дизайнеров
То есть пользователь это не оператор. Он не вбивает данные в формы в течении 8-ми часового рабочего дня. Так?
K>3. Приложение должно сохранять вводимые специалистом данные в in-process базу и по мере наличия интернета "синхронизироваться" с основной базой.
Синхронизация достаточно сложный процесс. У нас немного другая схема и нам пришлось реализовывать её с нуля. Если к синхронизации много бизнес-требований, то готовые решения потом замучаешься тюнинговать.

K>Написать приложение-сервис, которое хостит в себе веб-севис (Jetty) с сайтом (на Grails) и базу (H2 / Mongo).
Почему NoSQL?
K>Плюс, отдельное update-приложение, которое занимается обновлением сервиса — останавливает сервис, поднимать рядом новую версию сервиса, накатывать на базу миграции, проверяет работоспособность поднятого, удаляет старое и если что — все корректно откатывает и т.д.
Умеют ли вышеуказанные базы откатывать изменения схемы без последствий?

K>1. Сложность написания приложения без ошибок и трудность автоматизации тестирования обновления (время разработки может растянуться на неопределенный срок)
Не очень понял. В приложении буду ошибки всегда. Это можно принять за аксиому. Обновление можно встроить в Continuous Integration. Другого теста ему не нужно.

K>2. В случае бага, падения update-приложения, разрядки батареи ноута и т.д. возможна ситауция, когда работа приложения не будет восстановлена и пользователь не сможет работать с приложением, а это критично для бизнеса, а так же не просто будет выяснить как именно все сломалось и написать приложение для восстанавления работы сломанного приложения.
Вывод. Переключение между версиями должно занимать минимальное время. Всё остальное нужно выносить в фоновый процесс.

K>Вместо сервиса сделать standalone-приложение, которое не только хостит в себе веб-сервер и базу
Это разумно.
K>но и окно в котором хоститься браузер (ui-элемент), который в себе отображает хостящийся сайт.
В этом нет необходимости. Браузер всегда можно стартовать отдельно по определенным событиям.

K>Для обновления использовать Web Start (jnlp). База будет лежать рядом вне jnlp-файла.
K>При обновлении jnlp-приложения (на сколько я понимаю механизм уже хорошо отлажен) и первом запуске обновленного приложения будет проверяться версия базы и если нужно — накатываться миграции.
Не вижу особых преимуществ. Кроме того что не нужно изобретать велосипед с обновлением. Но вопрос отката в случае ошибки обновления схемы остаётся открытым.

K>Тут все выглядит проще и надежнее (для меня):
K>- не нужно писать свой механизм обновления
Да.

K>- не нужно посылать пользователя в браузер по урлу localhost:xxxx — он просто работает с приложением
Это легко автомтизировать.

K>- не нужно писать сервис, который сложнее в администрировании, отладке и обновлении (могут требоваться перезагрузки)
Писать сервис не нужно. Существуют готовые решения. Перезагрузки тоже не нужны. Сервис это просто обертка над Java процессом. Особой разницы нет, кроме той что останавливать\запускать процесс нужно другим способом.

K>- если что-то сломается, можно обновить jnlp файл, он автоматом обновится у пользователя и все заработает как надо (хотя фаза выяснения состояния сломанного приложения на ноуте пользователя все равно есть и может сильно все усложнять).
Оптимистично.

K>2. Какие более простые способы есть написания такого типа приложения? Из ограничений — JVM и open source.
Напишите прототип jnlp, jetty, procrun и выбраная база. И протестируйте на этом прототипе обновления с откатом и ошибками.

Здравствуйте, LeonidV, Вы писали:

K>>Я имел ввиду, что GWT не охота, хотя вариант интересный, учитывая, что GWT-сайт можно собрать в war и захостить где угодно, не завися от гугла.
LV>Google уже фактически бросил GWT. Сейчас его поддержкой активно занимается Vaadin.
LV>http://googlewebtoolkit.blogspot.ru/2012/09/gwt-survey.html
В GWT уже нет смысла, так как JavaScript решения сейчас бурно развиваются и множество из них делают разработку на JavaScript намного вкуснее чем на GWT.

Здравствуйте, GreenTea, Вы писали:

GT>Далее по шедулеру будет чекать новую версию. Если есть, то скачивается архив с сервером и sql сприпт обновления.
Большинство SQL серверов не умеют транзакционно откатывать DDL.

GT>1) делаем копию базы.
Возможность этого шага сильно зависит от размера локальной базы. Ноутбук не тресене целую базу копировать при каждом обновлении?

GT>Мерж базы тоже должен быть таким, чтобы если отпадет интернет база не осталась в неконсистентном состоянии.
Какой ещё мерж? Апдейты накатываются локальными заранее скачаными скриптами.
Синхронизация с сервером что ли? Так её просто нужно транзакционной сделать.

Здравствуйте, ., Вы писали:

.>Все данные хранятся в СУБД, синхронизация данных — берём symmetricds. Должна быть возможность загрузить чистую базу с сервера, если вдруг поломалась клиентская.
Если в синхронизацию вклинится бизнес-логика, то будет много вопросов в том как то или иное сделать в symmetricds.

.>Изменение структуры БД — liquibase/аналоги.
Flyway мне понравился значительно меньше liquibase. Хотя у него есть и свои плюсы.

.>Приложение, если не сильно увесистое, запаковать в один jar-файл — обновлять целиком, при проблемах — использовать предыдущий.
JNLP позволяет выкачивать только diff между версиями.

.>Т.е. все изменения транзакционные — если что-то прервалось, продолжится дальше, либо будет работать старое.
Это на словах хорошо. А если разбить весь процесс по шагам, то будет очень много вопросов так как далеко не все из них с пол пинка делаются транзакционными.

Здравствуйте, Blazkowicz, Вы писали:

.>>Все данные хранятся в СУБД, синхронизация данных — берём symmetricds. Должна быть возможность загрузить чистую базу с сервера, если вдруг поломалась клиентская.
B>Если в синхронизацию вклинится бизнес-логика, то будет много вопросов в том как то или иное сделать в symmetricds.
Так не надо вклинивать, в том-то и дело.

.>>Изменение структуры БД — liquibase/аналоги.
B>Flyway мне понравился значительно меньше liquibase. Хотя у него есть и свои плюсы.
Я liquibase только трогал, вроде ничё так, работает.

.>>Приложение, если не сильно увесистое, запаковать в один jar-файл — обновлять целиком, при проблемах — использовать предыдущий.
B>JNLP позволяет выкачивать только diff между версиями.
Если аппликуха небольшая, то можно не заморачиваться.

.>>Т.е. все изменения транзакционные — если что-то прервалось, продолжится дальше, либо будет работать старое.
B>Это на словах хорошо. А если разбить весь процесс по шагам, то будет очень много вопросов так как далеко не все из них с пол пинка делаются транзакционными.
Согласен, придётся замахнуться на полтора пинка, а в некоторых случаях на π пинков, но, как мне кажется, ничего невозможного нет.

Здравствуйте, ., Вы писали:

B>>Если в синхронизацию вклинится бизнес-логика, то будет много вопросов в том как то или иное сделать в symmetricds.
Кстати. Если не сложно, можешь поделится опытом использования symmetricds? Что получилось клево и быстро, а с чем пришлось повозится?
Какая топология серверов?

.>Так не надо вклинивать, в том-то и дело.
Синхронизация без логики это тупая репликация.
А требований к синхронизации может возникнуть масса:
Это синхронизируем сейчас, а это синхронизируем потом, по какому-то событию.
Здесь конфликт данных в изменениях со стороны сервера, надо отложить, и дать возможность юзеру исправить.
Здесь просто неожиданная ошибка и надо её изолировать от остальной синхронизации.
Какие-то ошибки можно игнорировать, а какие-то должны останавливать весь процесс.
...и т.п.

.>Я liquibase только трогал, вроде ничё так, работает.
Клёвый. Смущает только XML формат. В .sql файлах не надо <> символы эскейпить и IDE умеют в них подсветку делать.

Здравствуйте, Blazkowicz, Вы писали:

B>Здравствуйте, Keith, Вы писали:

K>>1. Web-интерфейс, потому что он наиболее rich, кросс-платформенный и под него полно дизайнеров
B>То есть пользователь это не оператор. Он не вбивает данные в формы в течении 8-ми часового рабочего дня. Так?

Он именно оператор и вбивает данные, но форму для ввода данных на html можно сделать красивую, в отличие от др. способов.

K>>3. Приложение должно сохранять вводимые специалистом данные в in-process базу и по мере наличия интернета "синхронизироваться" с основной базой.
B>Синхронизация достаточно сложный процесс. У нас немного другая схема и нам пришлось реализовывать её с нуля. Если к синхронизации много бизнес-требований, то готовые решения потом замучаешься тюнинговать.

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

K>>Написать приложение-сервис, которое хостит в себе веб-севис (Jetty) с сайтом (на Grails) и базу (H2 / Mongo).
B>Почему NoSQL?

Это требование не мое, но можно пока и на H2 — оно sql, в отличие от Mongo.

K>>Плюс, отдельное update-приложение, которое занимается обновлением сервиса — останавливает сервис, поднимать рядом новую версию сервиса, накатывать на базу миграции, проверяет работоспособность поднятого, удаляет старое и если что — все корректно откатывает и т.д.
B>Умеют ли вышеуказанные базы откатывать изменения схемы без последствий?

H2 должен умень — он sql и транзакции есть.

K>>1. Сложность написания приложения без ошибок и трудность автоматизации тестирования обновления (время разработки может растянуться на неопределенный срок)
B>Не очень понял.
B>В приложении буду ошибки всегда.

Это точно.

B>Это можно принять за аксиому. Обновление можно встроить в Continuous Integration. Другого теста ему не нужно.

Как это? А если при обновлении у пользователей миграции не накатяться, хотя на моей тестовой базе все будет ок?
Тут речь о том, что механизм апдейтов писать самому — это перебор, т.к. ошибки в нем могут ломать полностью работу пользователей...
Если только рядом новую версию не поднимать, но тут тоже есть проблема — пользователю не нужны две версии, хотя иначе не понятно как сделать надежно.

K>>2. В случае бага, падения update-приложения, разрядки батареи ноута и т.д. возможна ситауция, когда работа приложения не будет восстановлена и пользователь не сможет работать с приложением, а это критично для бизнеса, а так же не просто будет выяснить как именно все сломалось и написать приложение для восстанавления работы сломанного приложения.
B>Вывод. Переключение между версиями должно занимать минимальное время. Всё остальное нужно выносить в фоновый процесс.

Не важно как мало времени будет занимать, важно, что при наличии бага все может сломаться.

K>>Вместо сервиса сделать standalone-приложение, которое не только хостит в себе веб-сервер и базу
B>Это разумно.
K>>но и окно в котором хоститься браузер (ui-элемент), который в себе отображает хостящийся сайт.
B>В этом нет необходимости. Браузер всегда можно стартовать отдельно по определенным событиям.

Пользователю будет не удобно запускать мой процесс, который висит и ничего не делает и идти руками в браузер на localhost:80ХХ/ чтобы там что-то делать.
Ну и строка браузера с браузерной навигацией пользователю не нужны, поэтому я все-таки хочу встроить браузер сюда же.

K>>Для обновления использовать Web Start (jnlp). База будет лежать рядом вне jnlp-файла.
K>>При обновлении jnlp-приложения (на сколько я понимаю механизм уже хорошо отлажен) и первом запуске обновленного приложения будет проверяться версия базы и если нужно — накатываться миграции.
B>Не вижу особых преимуществ. Кроме того что не нужно изобретать велосипед с обновлением. Но вопрос отката в случае ошибки обновления схемы остаётся открытым.

K>>Тут все выглядит проще и надежнее (для меня):
K>>- не нужно писать свой механизм обновления
B>Да.

K>>- не нужно посылать пользователя в браузер по урлу localhost:xxxx — он просто работает с приложением
B>Это легко автомтизировать.

Автоматизировать легко, но это не юзер френдли. Пользователю не нужно знать про то, что после запуска моего приложения (которое ничего не делает) можно пойти по магическому урлу и там работать...

K>>- не нужно писать сервис, который сложнее в администрировании, отладке и обновлении (могут требоваться перезагрузки)
B>Писать сервис не нужно. Существуют готовые решения. Перезагрузки тоже не нужны. Сервис это просто обертка над Java процессом. Особой разницы нет, кроме той что останавливать\запускать процесс нужно другим способом.

Сервисы не мгновенно перезапускаются, в отличие от обычного приложения, плюс бывают всякие проблемы, которые потом по логам нужно искать.
С приложением все равно проще мне кажется.

K>>- если что-то сломается, можно обновить jnlp файл, он автоматом обновится у пользователя и все заработает как надо (хотя фаза выяснения состояния сломанного приложения на ноуте пользователя все равно есть и может сильно все усложнять).
B>Оптимистично.

Согласен, но проще, чем с сервисом.
Плюс можно новую версию выкатывать как отдельное приложение — хочеь пользуйся старым, хочешь — новым.
В принципе с сервисом не на много сложнее, но все же проще.

K>>2. Какие более простые способы есть написания такого типа приложения? Из ограничений — JVM и open source.
B>Напишите прототип jnlp, jetty, procrun и выбраная база. И протестируйте на этом прототипе обновления с откатом и ошибками.

Сейчас как раз пишу прототип. Только про procrun не знал — посмотрю.
В принципе связка JavaXF + Browser (Web View) + Jetty + Grails site + H2 работает, но застрял с правильной сборкой jar'а.
Из IDE все работает, а когда сам jar собираю Jetty молча (без исключений) не стартует и браузер показывает пустую страницу, но это я думаю разберусь...

Здравствуйте, Blazkowicz, Вы писали:

B>>>Если в синхронизацию вклинится бизнес-логика, то будет много вопросов в том как то или иное сделать в symmetricds.
B>Кстати. Если не сложно, можешь поделится опытом использования symmetricds? Что получилось клево и быстро, а с чем пришлось повозится?
B>Какая топология серверов?
У нас было простая архитектура вообщем-то. Сервер psql, клиенты с локальными h2db. Клиенты используют свои БД для тяжелых запросов к данным, но данные read-only. Все изменения отправляются в виде команд на сервер, сервер делает модифицирующие операции, symmetricds собирает триггерами изменения и они потом рассылаются клиентам.
Проблемы были с авторизацией, когда не все изменеия нужно отправлять всем клиентам, а только те, которые данный клиент в данное время имеет право видеть. Но это было тяжело само по себе, из-за сложной модели бизнес-объектов. Приходилось перестраивать структуру данных и вообще жутко хорошо продумывать что где когда.

.>>Так не надо вклинивать, в том-то и дело.
B>Синхронизация без логики это тупая репликация.
B>А требований к синхронизации может возникнуть масса:
B>Это синхронизируем сейчас, а это синхронизируем потом, по какому-то событию.
B>Здесь конфликт данных в изменениях со стороны сервера, надо отложить, и дать возможность юзеру исправить.
B>Здесь просто неожиданная ошибка и надо её изолировать от остальной синхронизации.
B>Какие-то ошибки можно игнорировать, а какие-то должны останавливать весь процесс.
B>...и т.п.
Сама по себе репликация тоже не простая вещь в распределённой системе. Это же не просто пара master-slave СУБД для failover.
Если продумывать по слоям, т.е. реплицировать на уровне БД, а уже в DAO слое всякие бизнес-синхронизирующие заморочки, думаю получится более надёжно и просто. В общем универсального рецепта нет, понятное дело… Надо конкретные требования рассматривать.

.>>Я liquibase только трогал, вроде ничё так, работает.
B>Клёвый. Смущает только XML формат. В .sql файлах не надо <> символы эскейпить и IDE умеют в них подсветку делать.
XML-формат (ксати, для любителей поддерживается так же json и yaml) для описания самого changeset ну и для тривиальных мелких запросиков, а для сложных вещей из xml можно дёрнуть рядом положенный .sql-файл или загрузить данные из .csv-файла.

Здравствуйте, Keith, Вы писали:

K> Он именно оператор и вбивает данные, но форму для ввода данных на html можно сделать красивую, в отличие от др. способов.
Для оператора юзабилити ввода намного важнее рюшечек HTML. Портировать красивый дизайн с HTML на JavaFX — пару дней вместе с дизайнером посидеть. К тому же там CSS имеется.
Поддержка горячих клавишь на JavaScript и табуляция по форме в браузере — продолжительная головная боль. Браузер снандартизирован? Или все нужно поддерживать?

K>Вот этого я и боюсь, хотя на начальном этапе не так сложно — набор сущностей-справочников и пара сущностей, которые вводит оператор на основе справочников.
K>Справочники на сервере могут менятся и во время синхронизации это нужно разруливать.
Нужно use-case с синхронизацией писать и анализировать.

K>H2 должен умень — он sql и транзакции есть.
Ой, ли
https://groups.google.com/forum/#!topic/h2-database/kqaU7wi3_FY
http://www.h2database.com/html/roadmap.html
Есть SQL транзакции. Транзакционный DDL это отдельная тема.

B>>Это можно принять за аксиому. Обновление можно встроить в Continuous Integration. Другого теста ему не нужно.
K>Как это? А если при обновлении у пользователей миграции не накатяться, хотя на моей тестовой базе все будет ок?
Вероятность этого достаточно мала.

K>Тут речь о том, что механизм апдейтов писать самому — это перебор, т.к. ошибки в нем могут ломать полностью работу пользователей...
Верно. Кстати, в liquibase, по-моему можно для каждого апдейта прописывать rollback скрипт, который он накатит в случае ошибки. Не транзакционно, но зато увеличиват надежность.
Проблема только в том что скрипты эти (rollback) писать каждый раз тоже отдельная работа. А нужны они раз в год.

K>Если только рядом новую версию не поднимать, но тут тоже есть проблема — пользователю не нужны две версии, хотя иначе не понятно как сделать надежно.
Если рядом подымать вторую версию базы, то все равно пользователя нужно отправлять в режим ожидания.
К тому же подумайте над тем как держать две версии базы? Копировать польностью?? Или просто бэкапить?

K>Не важно как мало времени будет занимать, важно, что при наличии бага все может сломаться.
Без этого никуда. Бэкапы разве что делать.

K>Пользователю будет не удобно запускать мой процесс, который висит и ничего не делает и идти руками в браузер на localhost:80ХХ/ чтобы там что-то делать.
С сервисом запускать не нужно. Ссылку можно собрать из настроек и открыть с ней браузер.

K>Ну и строка браузера с браузерной навигацией пользователю не нужны, поэтому я все-таки хочу встроить браузер сюда же.
Ну, не знаю.

K>Автоматизировать легко, но это не юзер френдли. Пользователю не нужно знать про то, что после запуска моего приложения (которое ничего не делает) можно пойти по магическому урлу и там работать...
Если приложение — сервис. Оно всегда онлайн. У юзера на десктопе ярлык с URL, который открывает браузер.
Если приложени — standalone, то оно после запуска может открыть браузер по нужному URL. Проблем юзабилити не вижу.

K>Сервисы не мгновенно перезапускаются, в отличие от обычного приложения, плюс бывают всякие проблемы, которые потом по логам нужно искать.
Это какое-то наследние .NET опыта сказывается. У меня никаких проблем с WebSphere CE и Tomcat запущеными как сервис никогда не было. Время перезапуска сервиса точно такое же как и время перезапуска контейнера.

K>С приложением все равно проще мне кажется.
Ну, кроме того что пользователю надо ждать пока не запустится контейнер. А разработчику нужно следить за тем чтобы запуск контейнера не превышал N секунд.
Можно и standalone. Я особой разницы не вижу, кроме времени запуска.

K>Плюс можно новую версию выкатывать как отдельное приложение — хочеь пользуйся старым, хочешь — новым.
Я себе не представляю как это будет реализовано и как пользователь будет решать которую версию ему запустить.

K>В принципе с сервисом не на много сложнее, но все же проще.


K>Сейчас как раз пишу прототип. Только про procrun не знал — посмотрю.
K>В принципе связка JavaXF + Browser (Web View) + Jetty + Grails site + H2 работает, но застрял с правильной сборкой jar'а.
Смысл не в том что эта связка работает\не работает. Смысл в том что нужно на ней проверить процесс обновления.

K>Из IDE все работает, а когда сам jar собираю Jetty молча (без исключений) не стартует и браузер показывает пустую страницу, но это я думаю разберусь...
Значит что-то не так с логированием.

Здравствуйте, Keith, Вы писали:

K>Доступа к ноутбуку пользователя не будет и даже если будет, то админить каждый ноут будет очень накладно по времени, т.к. может быть 100+ пользователей.
100+, конечно, не так много. У нас вот 1500+. Но я все же рекомендую наладить процесс доставки логов, exception-ов и другой информации от клиентских приложений в support.
На одном проекте у нас юзеру вываливает форма, с помощью которой он может отправить скрин, exception и log.
На другом проекте просто все exception-ы отправляем на суппорт email. Дополнительно аттачим snapshot данных. Вот с доставкой логов я как-то проморгал. Приходится пока админов просить. Но нужно было всего пару раз за 4 месяца. Так что не критично.

K>> Он именно оператор и вбивает данные, но форму для ввода данных на html можно сделать красивую, в отличие от др. способов.
B>Для оператора юзабилити ввода намного важнее рюшечек HTML. Портировать красивый дизайн с HTML на JavaFX — пару дней вместе с дизайнером посидеть. К тому же там CSS имеется.

Политика партии делать на вебе.

B>Поддержка горячих клавишь на JavaScript и табуляция по форме в браузере — продолжительная головная боль. Браузер снандартизирован? Или все нужно поддерживать?

Пока считаем, что стандартизован — последний десктопный ИЕ.

K>>Вот этого я и боюсь, хотя на начальном этапе не так сложно — набор сущностей-справочников и пара сущностей, которые вводит оператор на основе справочников.
K>>Справочники на сервере могут менятся и во время синхронизации это нужно разруливать.
B>Нужно use-case с синхронизацией писать и анализировать.

В смысле, обдумывать какие данные могут быть и как они могут ложится/не ложиться и что в каждом случае делать?
Это само собой, пока пытаюсь просто "взлететь со всем этим".

K>>H2 должен умень — он sql и транзакции есть.
B>Ой, ли
B>https://groups.google.com/forum/#!topic/h2-database/kqaU7wi3_FY
B>http://www.h2database.com/html/roadmap.html
B>Есть SQL транзакции. Транзакционный DDL это отдельная тема.

DDL — это create/alter table? Я и не знал, что это отдельная категория запросов, которая может не транзакционно выполняться

B>>>Это можно принять за аксиому. Обновление можно встроить в Continuous Integration. Другого теста ему не нужно.
K>>Как это? А если при обновлении у пользователей миграции не накатяться, хотя на моей тестовой базе все будет ок?
B>Вероятность этого достаточно мала.

На моей правктике случалось, хотя и нечасто.

K>>Если только рядом новую версию не поднимать, но тут тоже есть проблема — пользователю не нужны две версии, хотя иначе не понятно как сделать надежно.
B>Если рядом подымать вторую версию базы, то все равно пользователя нужно отправлять в режим ожидания.
B>К тому же подумайте над тем как держать две версии базы? Копировать польностью?? Или просто бэкапить?

На самом деле их можно полностью разделить и ничего не копировать.
Получится, что у пользователя есть старая версия со старой базой, которая работает и синхронизируется и
есть новая версия с новой чистой базой.
Когда данные в старой версии будут синхронизированы, можно от нее отказатся и перейти полностью на новую,
а если новая версия с багами, то можно старую запустить.
Только одна проблема — пользователю не желательно знать про две версии...
Можно сделать одну точку входа для пользователя (ярлык для запуска, грубо говоря), и при запуске уже спрашивать какую версию он хочет и какую можно удалить, но
это все равно усложняет процесс для пользователя.

K>>Сервисы не мгновенно перезапускаются, в отличие от обычного приложения, плюс бывают всякие проблемы, которые потом по логам нужно искать.
B>Это какое-то наследние .NET опыта сказывается. У меня никаких проблем с WebSphere CE и Tomcat запущеными как сервис никогда не было. Время перезапуска сервиса точно такое же как и время перезапуска контейнера.

Ох ) А я имел счастье админить Jira на своем сервере, которая как раз в сервисе с tomcat'ом крутилась...
Иногда сервис запускался, а tomcat нет и вроде сервис работает, а по урлу 404 — нужно было руками перезапускать сервис.
Обновление этого барахла — вообще отдельная тема, последний раз не осилил даже, хотя это больше на проблемы Atlassian похоже.

K>>Плюс можно новую версию выкатывать как отдельное приложение — хочеь пользуйся старым, хочешь — новым.
B>Я себе не представляю как это будет реализовано и как пользователь будет решать которую версию ему запустить.

С Web Start'ом просто = есть просто две ссылки (два ярлыка), одна запускает новое приложение, другая — старое.

K>>Из IDE все работает, а когда сам jar собираю Jetty молча (без исключений) не стартует и браузер показывает пустую страницу, но это я думаю разберусь...
B>Значит что-то не так с логированием.

Да, как раз логи настраиваю.
Никак не пойму как c executable jar направить весь вывод в файл.
Получается если сделать так:
java -verbose -jar MyJar.jar > output.txt
но все, что я вижу — это сотня строк с Loaded some.jar типа:
[Loaded java.lang.Object from C:\Program Files\Java\jre7\lib\rt.jar]

Здравствуйте, Blazkowicz, Вы писали:

B>Здравствуйте, Keith, Вы писали:

K>>Доступа к ноутбуку пользователя не будет и даже если будет, то админить каждый ноут будет очень накладно по времени, т.к. может быть 100+ пользователей.
B>100+, конечно, не так много. У нас вот 1500+. Но я все же рекомендую наладить процесс доставки логов, exception-ов и другой информации от клиентских приложений в support.
B>На одном проекте у нас юзеру вываливает форма, с помощью которой он может отправить скрин, exception и log.
B>На другом проекте просто все exception-ы отправляем на суппорт email. Дополнительно аттачим snapshot данных. Вот с доставкой логов я как-то проморгал. Приходится пока админов просить. Но нужно было всего пару раз за 4 месяца. Так что не критично.

Спасибо что сказали, я собирался при необработанном исключении сразу посылать письмо с подробностями в свой трекер.
Есть ли смысл открывать пользователю письмо? Мне кажется, что лучше это делать без участия пользователя.

Здравствуйте, Keith, Вы писали:

K>Пока считаем, что стандартизован — последний десктопный ИЕ.
Нужно посмотреть как JavaFX выбирает браузер, который он использует.

K>В смысле, обдумывать какие данные могут быть и как они могут ложится/не ложиться и что в каждом случае делать?
K>Это само собой, пока пытаюсь просто "взлететь со всем этим".
Ну, вообще потоки данных, поведение юзера. От этого очень много всего зависит. Конфликты там, требования к синхронизации. Мы же не знаем вашего workflow.

K>DDL — это create/alter table? Я и не знал, что это отдельная категория запросов, которая может не транзакционно выполняться :shuffle:
Именно. И она почти везде не транзакционна.

K>На самом деле их можно полностью разделить и ничего не копировать.
K>Получится, что у пользователя есть старая версия со старой базой, которая работает и синхронизируется и
K>есть новая версия с новой чистой базой.
Ну, вот это уже исходя из каких-то требований можно иметь чистую базу. А что делать если каким-то SQL нужно преобразовать данные?

K>Когда данные в старой версии будут синхронизированы, можно от нее отказатся и перейти полностью на новую,
K>а если новая версия с багами, то можно старую запустить.
Дык вопрос о существующих данных. Как они между разными базами будет передаваться? Через бэкап? Через копирование? Или новая версия — всё с чистого листа?

K>Только одна проблема — пользователю не желательно знать про две версии...
Вооот. А потом ты говоришь про два ярлыка на рабочем столе. :))

K>Можно сделать одну точку входа для пользователя (ярлык для запуска, грубо говоря), и при запуске уже спрашивать какую версию он хочет и какую можно удалить, но
K>это все равно усложняет процесс для пользователя.
Пользователь не хочет этого знать и не хочет принимать такого решения. Я бы здесь на него не полагался.
Вообще 100+ юзеров это не много и единичные проблемы вполне может разруливать админ\девелопер. Суппорт ведь нужен в любом случае.


K>Ох ) А я имел счастье админить Jira на своем сервере, которая как раз в сервисе с tomcat'ом крутилась...
K>Иногда сервис запускался, а tomcat нет и вроде сервис работает, а по урлу 404 — нужно было руками перезапускать сервис.
Это не томкат не запускался. А jira апликуха внутри него. Это сугубо вопрос деплоймента и к взаимоотношениям сервис-томкат отношения не имеет.

K>Обновление этого барахла — вообще отдельная тема, последний раз не осилил даже, хотя это больше на проблемы Atlassian похоже.
Мне тоже кажется что к Windows Service это никакого отношения не имеет.

K>С Web Start'ом просто = есть просто две ссылки (два ярлыка), одна запускает новое приложение, другая — старое.
Пользователь будет в шоке.

K>Да, как раз логи настраиваю.
K>Никак не пойму как c executable jar направить весь вывод в файл.
K>Получается если сделать так:
K>java -verbose -jar MyJar.jar > output.txt
K>но все, что я вижу — это сотня строк с Loaded some.jar типа:
K>[Loaded java.lang.Object from C:\Program Files\Java\jre7\lib\rt.jar]
Это уже "добро пожаловать в Java форум". Лучше таки установить логгер, который и system.out в свои логи редиректит.

K>>Когда данные в старой версии будут синхронизированы, можно от нее отказатся и перейти полностью на новую,
K>>а если новая версия с багами, то можно старую запустить.
B>Дык вопрос о существующих данных. Как они между разными базами будет передаваться? Через бэкап? Через копирование? Или новая версия — всё с чистого листа?

Да, можно с чистого листа.
Пользователь в старой версии все синхронизирует и может работать с новой версией. А может со старой, если новая с багами.
Понятно, что могут быть требования перетаскивать данные — в принципе, не вижу проблемы.
Если структура изменилась, то 1. старую базу можно клонировать, 2. накатить на клон миграции и 3. перетащить нужные данные в новую базу.
Транзакций не будет на шаге 1 и 2, но в случае их поломки можно начать с начала, очистив каталог для клона.
На шаге 3 транзакции будут.

K>>Только одна проблема — пользователю не желательно знать про две версии...
B>Вооот. А потом ты говоришь про два ярлыка на рабочем столе.
Да, я фантазирую на тему, т.к. сделать прототип нужно уже сейчас, а требования еще до конца не ясны.
Я пока решил сделать standalone приложение и выложить его с помощью web start'а, а дальше уже по обстоятельствам можно будет что угодно подсунуть при обновлении — хоть сервис.

K>>Можно сделать одну точку входа для пользователя (ярлык для запуска, грубо говоря), и при запуске уже спрашивать какую версию он хочет и какую можно удалить, но
K>>это все равно усложняет процесс для пользователя.
B>Пользователь не хочет этого знать и не хочет принимать такого решения. Я бы здесь на него не полагался.

Согласен.
Учитывая сложность темы обновления, я бы для начала просто миграции накатывал на туже базу и смотрел как много пользователей при этом отваливается и на сколько
это критично. А дальше уже придумывал какие-то страховочные механизмы.

B>Вообще 100+ юзеров это не много и единичные проблемы вполне может разруливать админ\девелопер. Суппорт ведь нужен в любом случае.
Сапорт пока не подразумевается, если только в лице меня ) А мне еще код писать, поэтому лучше бы администрирование сократить до минимума.
Это число ориентировочное и будет в начале, сколько будет потом — неизвестно, может быть и 1000+.

K>>С Web Start'ом просто = есть просто две ссылки (два ярлыка), одна запускает новое приложение, другая — старое.
B>Пользователь будет в шоке.

Да ладно ) Ну ок, другой вариант, ссылка на старое приложение будет прямо в моем приложении, как при изменении сайтов делают (гугл, например).

K>>[Loaded java.lang.Object from C:\Program Files\Java\jre7\lib\rt.jar]
B>Это уже "добро пожаловать в Java форум". Лучше таки установить логгер, который и system.out в свои логи редиректит.
Дело похоже не в логе... Но спасибо за совет, пойду действительно напишу...

Здравствуйте, Blazkowicz, Вы писали:

K>>Да, как раз логи настраиваю.
K>>Никак не пойму как c executable jar направить весь вывод в файл.
K>>Получается если сделать так:
K>>java -verbose -jar MyJar.jar > output.txt
K>>но все, что я вижу — это сотня строк с Loaded some.jar типа:
K>>[Loaded java.lang.Object from C:\Program Files\Java\jre7\lib\rt.jar]
B>Это уже "добро пожаловать в Java форум". Лучше таки установить логгер, который и system.out в свои логи редиректит.

Не могли бы Вы поучавствовать вобсуждении этого вопроса?
http://rsdn.ru/forum/java/5241230.flat#5241230

Автор: Keith
Дата: 24.07.13

Здравствуйте, Keith, Вы писали:

K>Есть ли смысл открывать пользователю письмо? Мне кажется, что лучше это делать без участия пользователя.

Что-что? Без предупреждения и подтверждения пользователя сниферить состояние его рабочей станции? Этого себе даже Корпорация Майкрософт не позволяет.

Здравствуйте, akasoft, Вы писали:

K>>Есть ли смысл открывать пользователю письмо? Мне кажется, что лучше это делать без участия пользователя.

A>Что-что? Без предупреждения и подтверждения пользователя сниферить состояние его рабочей станции? Этого себе даже Корпорация Майкрософт не позволяет.

Всегда можно "попросить" (заставить) пользователя поставить галку )

Здравствуйте, akasoft, Вы писали:

A>Что-что? Без предупреждения и подтверждения пользователя сниферить состояние его рабочей станции? Этого себе даже Корпорация Майкрософт не позволяет.
Сейчас этим занимаются все кому не лень. Например, если, проект собственность одной компании и пользователи её работники, то тут вообще нет никаких нарушений.
Но замечание правильно в том смысле что Privacy Policy для каждого проекта могут быть разные.

Здравствуйте, Keith, Вы писали:

K> Всегда можно "попросить" (заставить) пользователя поставить галку )

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

Молчком собирать информацию и отсылать неправильно. Ведь можно спровоцировать ситуацию, и подменить адрес отправки. И это уже уязвимость в ПО, заложенная при проектировании. А зачем тебе лишние проблемы?

Здравствуйте, akasoft, Вы писали:

A>Какая галка? Тебе в данных исключения поедет приватная информация о бизнес-объекте (ты же хочешь разобраться с природой ошибки и убрать её) через незащищённые каналы (почта),
Если предприятие имеет настолько сильные ограничения безопастности, что support просто отправляется в локальную почту и за пределы предприятия не выходит. При необходимости доступа третим лицам, кто-то может просто апрувить отдельную информаци.
Это всё решается организацией процесса.

A>это его личное дело, что он там за программы запускает.
Если пользователь — работник предприятия и выполняет работу предприятия использую ПО и Hardware предприятия, то это не его личное дело.

A>Молчком собирать информацию и отсылать неправильно.
Сильно категоричное суждение. Для публичного сервиса — не правильно и даже не законно. Для Enterprise приложения — вполне нормально.

A>Ведь можно спровоцировать ситуацию, и подменить адрес отправки.
Это сугубо ворпос админской безопасности. Если преступник может подминить конфигурацию сервера, то он может натворить и более серьезные вещи.

A>И это уже уязвимость в ПО, заложенная при проектировании. А зачем тебе лишние проблемы?
Не вижу уязвимости. Зависит очень сильно от предметной области.

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

Здравствуйте, akasoft, Вы писали:

K>> Всегда можно "попросить" (заставить) пользователя поставить галку )

A>Какая галка? Тебе в данных исключения поедет приватная информация о бизнес-объекте (ты же хочешь разобраться с природой ошибки и убрать её) через незащищённые каналы (почта), плюс к этому ты захочешь информацию об окружении, вызвавшем ошибку, а это уже почти что персональная информация о пользователе, это его личное дело, что он там за программы запускает.

A>Молчком собирать информацию и отсылать неправильно. Ведь можно спровоцировать ситуацию, и подменить адрес отправки. И это уже уязвимость в ПО, заложенная при проектировании. А зачем тебе лишние проблемы?

Не думал об этом с этой стороны ) Сам всегда отправляю отчеты с ошибками...
Можно пересылать инфу по почте в шифрованом виде.
А при инсталляции просить поставить пользователя галку о том, что он согласен передавать мне системную информацию и может даже персональные данные.

Здравствуйте, Blazkowicz, Вы писали:

B>Если пользователь — работник предприятия и выполняет работу предприятия использую ПО и Hardware предприятия, то это не его личное дело.

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

B>Сильно категоричное суждение. Для публичного сервиса — не правильно и даже не законно. Для Enterprise приложения — вполне нормально.

Таково моё мнение, основанное на моём опыте. Я считаю, что работники тоже люди.

B>Это сугубо ворпос админской безопасности. Если преступник может подминить конфигурацию сервера, то он может натворить и более серьезные вещи.

Если (мы тут сильно уходим в сторону допущениями, но ты же ушёл) уязвимость заложена в ПО, и админу про неё не рассказали, но возможны последствия. Админ не выискивает уязвимости, он знаток правил и игры по ним. Только вот правила надо доводить до админа, а умолчки в ПО этому не способствуют.

B>А в жизни и не такое встречается. В штатах видел проект, который номера реальных кредитных карт в лог пишет.

Ну! А потом удивляемся ужасу всяких "взломов", типа последней фигни про тексты СМС в поисковиках.

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

Здравствуйте, akasoft, Вы писали:

B>>Если пользователь — работник предприятия и выполняет работу предприятия использую ПО и Hardware предприятия, то это не его личное дело.
A>Боюсь, обсуждение того, что на работника предприятия не распространяется действие Конституции, ТК и пр. выходит за рамки этого форума.
Притянуто за уши. Речь не идёт о приватной переписке пользователя. Речь идёт о данных компании. Которые не могут являтся личными данными пользователя. Вас послушать, так любой админ, который зашел к юзеру по RDP нарушает конституцию.

Здравствуйте, Keith, Вы писали:

K>Вопросы:
K>1. На сколько рабочий 1 вариант решения?

Рабочий.

K>1. На сколько состоятелен 2 вариант решения?

Состоятелен.

Плюс первого варианта — у тебя есть сервис, это позволит тебе делать синхронизацию в фоне, без какого либо участия пользователя. Главное чтобы ноут работал и был инет. Это же и минус — кроссплатформенно ты сервис не сделаешь, придется под каждую конкретную ОС писать свой сервис-хост.
Минус второго варианта — интегрирование браузеров в собственный процесс — штука непростая, а с учетом кроссплатформенности совсем непростая. Плюс — ты можешь дополнить приложение сервисами, которые в обычном браузере недоступны, и не лимитирован ограничениями доступа.

Здравствуйте, AndrewVK, Вы писали:

K>>Вопросы:
K>>1. На сколько рабочий 1 вариант решения?
AVK>Рабочий.

K>>1. На сколько состоятелен 2 вариант решения?
AVK>Состоятелен.

Попробовав второй вариант, столкнулся с кучей интересных проблем: собрать правильный jar — это само по себе не просто, а уж собрать правильный, подписаный, с правильным манифестом и jnlp оказалось сильно сложнее, чем я думал. Особенно осложняло жизнь то, что если собирать не правильно, то можно просто ничего не увидеть в ответ — просто ничего не происходит, даже стектрейс не отображается, хотя включен в настройках java в control panel для всех процессов (а дело лишь в том, что указан codebase в jnlp, который не совпадает с текущим).
Но все же осилил.
Основная проблема в итоге — запуск веб-сервера (Jetty) происходит долго, около 18 секунд.
Каждый раз при запуске приложения заставлять пользователя ждать 18 секунд — это слишком, даже если сделать гипнотизирующий splash-screen.
В принципе, можно пробовать настроить Jetty, чтобы стартовал быстрее, но это мало вероятно, тем более, что приложение сейчас и так минимальное, что будет, если появится куча мапингов Hibernate'а, которые будут при запуске собираться...

Теперь буду делать первый вариант.
Jar с веб-сервером заверну в сервис (это, вроде, можно сделать с помощью Apache Procrun)
Скорее всего, придется прикрутить сторонний инсталлятор (не знаю как еще это сделать), чтобы устанавливать сервис и иконку на десктоп с ссылкой в дефолтный браузер.
Из инсталлеров пока присмотриваюсь к izpack.
Из минусов — не так просто будет обновить приложение — придется передавать пользователю ссылку на exe'шник с инсталлятором новой версии, который надо руками скачивать, запускать и прокликивать
wizard, в процессе которого старый сервис должен быть остановлен, а новый запущен, что займет не меньше 18 секунд.
Боюсь, что это придется делать админу, а это уже приличные расходы времени на администрирование.

AVK>Плюс первого варианта — у тебя есть сервис, это позволит тебе делать синхронизацию в фоне, без какого либо участия пользователя. Главное чтобы ноут работал и был инет. Это же и минус — кроссплатформенно ты сервис не сделаешь, придется под каждую конкретную ОС писать свой сервис-хост.

Ну что делать, придется пробовать теперь этот вариант.

AVK>Минус второго варианта — интегрирование браузеров в собственный процесс — штука непростая, а с учетом кроссплатформенности совсем непростая.

В принципе, мне кажется, что кросс-платформенный браузер приделать удалось — использовал Web View из JavaFX, правда кроме винды нигде не проверял, но не вижу причин почему он может не работать на других платформах.

Здравствуйте, Keith, Вы писали:

K>Попробовав второй вариант, столкнулся с кучей интересных проблем: собрать правильный jar — это само по себе не просто, а уж собрать правильный, подписаный, с правильным манифестом и jnlp оказалось сильно сложнее, чем я думал. Особенно осложняло жизнь то, что если собирать не правильно, то можно просто ничего не увидеть в ответ — просто ничего не происходит, даже стектрейс не отображается, хотя включен в настройках java в control panel для всех процессов (а дело лишь в том, что указан codebase в jnlp, который не совпадает с текущим).
Добро пожаловать в Java opensource. Тут нужно уметь читать и понимать реализацию тех API, которые используешь. В противном случае, если с opensource работать как с черным ящиком, можно потерять недели на мелки непонятки.

K>Основная проблема в итоге — запуск веб-сервера (Jetty) происходит долго, около 18 секунд.
Подозреваю что это из-за деплоя war модуля. Надо посмотреть best practice на эту тему. Может через хендлеры стоит делать? К тому же на либы надо смотреть. Например если использовать сканикрование аннотаций ORM и IoC, то это тоже сожрет кучу времени.

K>Каждый раз при запуске приложения заставлять пользователя ждать 18 секунд — это слишком, даже если сделать гипнотизирующий splash-screen.
Это решаемо. Нужно только выбрать легковестные библиотеки. Дело в том что у серверов время запуска не принято оптимизировать. Так же стоит рассмотреть вариант с разворачиваем war в отдельную директорию при инсталяции, и деплоить уже war-директорию, а не war файл. Возможно эти 18 секунд и уходят на то чтобы jetty распаковал war.

K>В принципе, можно пробовать настроить Jetty, чтобы стартовал быстрее, но это мало вероятно, тем более, что приложение сейчас и так минимальное, что будет, если появится куча мапингов Hibernate'а, которые будут при запуске собираться...
Это не маловероятно. Всё решается. Деплоймент можно уложить в 30 секунд. У моих коллег так сделано.
Или вот в презентации автор этим хвастался:
http://www.youtube.com/watch?v=TSAlj04_tkA

K>Скорее всего, придется прикрутить сторонний инсталлятор (не знаю как еще это сделать), чтобы устанавливать сервис и иконку на десктоп с ссылкой в дефолтный браузер.
K>Из инсталлеров пока присмотриваюсь к izpack.
izpack, по-моему, требует наличия Java. Я бы посмотрел в стороу NSIS.

K>Из минусов — не так просто будет обновить приложение — придется передавать пользователю ссылку на exe'шник с инсталлятором новой версии, который надо руками скачивать, запускать и прокликивать
K>wizard, в процессе которого старый сервис должен быть остановлен, а новый запущен, что займет не меньше 18 секунд.
Обновление в любом случае не будет очень быстрым. Но чтобы всё было как надо, его придётся писать самому.

K>Боюсь, что это придется делать админу, а это уже приличные расходы времени на администрирование.
Зачем. Посмотри как сейчас обновляются Flash, браузеры и т.п. Вполне лояльно к юзеру.

K>В принципе, мне кажется, что кросс-платформенный браузер приделать удалось — использовал Web View из JavaFX, правда кроме винды нигде не проверял, но не вижу причин почему он может не работать на других платформах.
JavaFX даже на iOS и Android работает. Только Oracle не будет выпускать его на этих платформах. Но если кросс-платформенность нужна, то есть смысл протестировать. Мало ли.

Здравствуйте, Blazkowicz, Вы писали:

B>Здравствуйте, Keith, Вы писали:

K>>Попробовав второй вариант, столкнулся с кучей интересных проблем: собрать правильный jar — это само по себе не просто, а уж собрать правильный, подписаный, с правильным манифестом и jnlp оказалось сильно сложнее, чем я думал. Особенно осложняло жизнь то, что если собирать не правильно, то можно просто ничего не увидеть в ответ — просто ничего не происходит, даже стектрейс не отображается, хотя включен в настройках java в control panel для всех процессов (а дело лишь в том, что указан codebase в jnlp, который не совпадает с текущим).
B>Добро пожаловать в Java opensource.

Спасибо, тут мило — если и не соберешь прототип, то хотя бы получишь level up в администрировании )
Это нормально? Я просто после .net'а слегка в шоке, хотя в целом мне нравится.

B>Тут нужно уметь читать и понимать реализацию тех API, которые используешь. В противном случае, если с opensource работать как с черным ящиком, можно потерять недели на мелки непонятки.

Вообще, это полезно, конечно, но и юзер френдности не помешало бы... "блеск и нищета" точнее не скажешь )
Но прошу без холивара — я согласен на счет большого кол-ва библиотек.

K>>Основная проблема в итоге — запуск веб-сервера (Jetty) происходит долго, около 18 секунд.
B>Подозреваю что это из-за деплоя war модуля. Надо посмотреть best practice на эту тему. Может через хендлеры стоит делать?

Через хэндлеры — это свои метды-обработчики веб-запросов писать? Вместо нормального фреймворка вроде grails, в котором только домен менять да верстку натягивать?
Нет уж, проще написать свой фреймворк на JavaFX + Html ) Хотя так извращаться у меня времени нет )

B>К тому же на либы надо смотреть. Например если использовать сканикрование аннотаций ORM и IoC, то это тоже сожрет кучу времени.

Grails, который на Spring + Hibernate.

K>>Каждый раз при запуске приложения заставлять пользователя ждать 18 секунд — это слишком, даже если сделать гипнотизирующий splash-screen.
B>Это решаемо. Нужно только выбрать легковестные библиотеки. Дело в том что у серверов время запуска не принято оптимизировать. Так же стоит рассмотреть вариант с разворачиваем war в отдельную директорию при инсталяции, и деплоить уже war-директорию, а не war файл. Возможно эти 18 секунд и уходят на то чтобы jetty распаковал war.

Нет, всего лишь 16 секунд против 18.

2013-07-29 02:37:48.601:INFO:oejs.Server:jetty-7.6.0.v20120127
2013-07-29 02:37:51.045:INFO:oejw.StandardDescriptorProcessor:NO JSP Support for /, did not find org.apache.jasper.servlet.JspServlet
2013-07-29 02:37:52.290:INFO:/:Initializing Spring root WebApplicationContext
2013-07-29 02:38:03.856:INFO:oejsh.ContextHandler:started o.e.j.w.WebAppContext{/,file:/C:/Users/Work/AppData/Local/Temp/jetty-0.0.0.0-8082-PhysicianJournal.Site-0.1.war-_-any-/webapp/},c:\Users\Work\AppData\Local\Temp\jetty-0.0.0.0-8082-PhysicianJournal.Site-0.1.war-_-any-\webapp\
2013-07-29 02:38:03.951:INFO:/:Initializing Spring FrameworkServlet 'grails'
2013-07-29 02:38:04.010:INFO:oejs.AbstractConnector:Started SelectChannelConnector@0.0.0.0:8082

Spring root WebApplicationContext = 11,5 секунд.
От него не избавиться, т.к. сайт на Grails и пока это решение не меняется.

K>>В принципе, можно пробовать настроить Jetty, чтобы стартовал быстрее, но это мало вероятно, тем более, что приложение сейчас и так минимальное, что будет, если появится куча мапингов Hibernate'а, которые будут при запуске собираться...
B>Это не маловероятно. Всё решается. Деплоймент можно уложить в 30 секунд. У моих коллег так сделано.

Одно дело, когда 30 секунд деплоится на сервер через continuous integration, другое дело, когда пользователь включает приложение и ждет 30 секунд пока сервер запуститься и отобразит наконец какой-то интерфейс.

K>>Скорее всего, придется прикрутить сторонний инсталлятор (не знаю как еще это сделать), чтобы устанавливать сервис и иконку на десктоп с ссылкой в дефолтный браузер.
K>>Из инсталлеров пока присмотриваюсь к izpack.
B>izpack, по-моему, требует наличия Java. Я бы посмотрел в стороу NSIS.

Да, действительно требует. Спасибо за отсылку к NSIS — тихий режим обновления вроде есть...

K>>Из минусов — не так просто будет обновить приложение — придется передавать пользователю ссылку на exe'шник с инсталлятором новой версии, который надо руками скачивать, запускать и прокликивать
K>>wizard, в процессе которого старый сервис должен быть остановлен, а новый запущен, что займет не меньше 18 секунд.
B>Обновление в любом случае не будет очень быстрым. Но чтобы всё было как надо, его придётся писать самому.

Что именно придется писать самому? Скрипт для инсталлятора или свой мини-инсталлятор?

K>>Боюсь, что это придется делать админу, а это уже приличные расходы времени на администрирование.
B>Зачем. Посмотри как сейчас обновляются Flash, браузеры и т.п. Вполне лояльно к юзеру.

Flash не помню как обновляется и это плюс )
Chrome обновляются отлично, но я не знаю как в нем устроен механизм обновлений.
Firefox убил бы за длительные проверки при запуске.
Хочется чтобы приложение обновлялось полностью незаметно для пользователя и максимально стабильно — если при обновлении что-то не заработает, то хотя бы откатывалось к предыдущей версии.
Как это лучше сделать?

K>>В принципе, мне кажется, что кросс-платформенный браузер приделать удалось — использовал Web View из JavaFX, правда кроме винды нигде не проверял, но не вижу причин почему он может не работать на других платформах.
B>JavaFX даже на iOS и Android работает. Только Oracle не будет выпускать его на этих платформах. Но если кросс-платформенность нужна, то есть смысл протестировать. Мало ли.

Вообще, пока не нужна и достаточно винды, а в перспективе что угодно может быть.

Здравствуйте, Keith, Вы писали:

K> Это нормально? Я просто после .net'а слегка в шоке, хотя в целом мне нравится.
Смысл в том, что если хочешь использовать только документации и книги, как в .NET, то нужно оставаться в рамках JEE. И всех желаний оно точно не покроет. А чтобы нормально использовать opensource надо уметь читать исходники помимо манула, это самый быстрый способ понять как добится желаемого. А мануалы они далеко не у всех полные.

K> Вообще, это полезно, конечно, но и юзер френдности не помешало бы... "блеск и нищета" точнее не скажешь )
K> Но прошу без холивара — я согласен на счет большого кол-ва библиотек.
Первое с чего офигивает .NET-чик при знакоместве с Java это с именованием классов, методов и т.п. Уже не раз об этом писал. Если тебе в .NET нужен метод, придумываешь как бы ты его назвал и легко находишь. В Java не так. Нужно выучить основные пакеты, что бы знать основные классы чтобы в JavaDoc искать. Хорошо, что сейчас материала в инете уже масса и гуглом проще искать. А вот 10 лет назад было не так.

K> Через хэндлеры — это свои метды-обработчики веб-запросов писать? Вместо нормального фреймворка вроде grails, в котором только домен менять да верстку натягивать?
K> Нет уж, проще написать свой фреймворк на JavaFX + Html ) Хотя так извращаться у меня времени нет )
Нет. Конечно же использовать фреймверки. Только их нужно привязать к хэндлерам, а не к web.xml.

K> Grails, который на Spring + Hibernate.
Ну, тут всё упрется в сканирование аннотаций, как я уже написал. Варианта два. Либо как-то скормить контейнерам конкретные классы, чтобы всё не сканировалось. Либо использовать XML и там и там без аннотаций.

K> Нет, всего лишь 16 секунд против 18.
Мда. Тогда, наверное Win Service будет хорошим вариантом. Единственная проблема что он память будет жрать, пока юзер его не остановит.

K> Что именно придется писать самому? Скрипт для инсталлятора или свой мини-инсталлятор?
"Обновлятор". Кстати, тут есть вторая проблема. А что если нужно обновить версию Java?

K>Хочется чтобы приложение обновлялось полностью незаметно для пользователя и максимально стабильно — если при обновлении что-то не заработает, то хотя бы откатывалось к предыдущей версии.
K>Как это лучше сделать?
Скачать и забэкапить всё в фоновом режиме, не отрывая юзера от работы. А потом быстро-быстро заменить файлы и переключить юзера на новую версию.

Здравствуйте, Blazkowicz, Вы писали:

K>> Это нормально? Я просто после .net'а слегка в шоке, хотя в целом мне нравится.
B>Смысл в том, что если хочешь использовать только документации и книги, как в .NET, то нужно оставаться в рамках JEE. И всех желаний оно точно не покроет. А чтобы нормально использовать opensource надо уметь читать исходники помимо манула, это самый быстрый способ понять как добится желаемого. А мануалы они далеко не у всех полные.
B>Первое с чего офигивает .NET-чик при знакоместве с Java это с именованием классов, методов и т.п. Уже не раз об этом писал. Если тебе в .NET нужен метод, придумываешь как бы ты его назвал и легко находишь. В Java не так. Нужно выучить основные пакеты, что бы знать основные классы чтобы в JavaDoc искать. Хорошо, что сейчас материала в инете уже масса и гуглом проще искать. А вот 10 лет назад было не так.

Конкретно этих проблем не заметил — мануалов пока хватало, да они не такие полные, но для старта достаточные.
Именования методов тоже особых проблем не вызывает — вроде все более-менее сносно называется.
Нехватает краткой справки к подсвечиваемым ide методам — хочется видеть не только типы переменных, но и имена переменных и их единицы измерения,
чтобы было не Thread.sleep(long), а Thread.sleep(long timeInMilliseconds)
Больше всего напрягает 4-е инструмента для сборки, не считая ide: maven, ant, ivy, gradle.
Без ориентации в первых двух вообще мало что можно сделать, хотя зачем их столько — для меня загадка.
Не, я понимаю, исторически сложилось, но это ощутимо усложняет жизнь.

K>> Через хэндлеры — это свои метды-обработчики веб-запросов писать? Вместо нормального фреймворка вроде grails, в котором только домен менять да верстку натягивать?
K>> Нет уж, проще написать свой фреймворк на JavaFX + Html ) Хотя так извращаться у меня времени нет )
B>Нет. Конечно же использовать фреймверки. Только их нужно привязать к хэндлерам, а не к web.xml.

Ясно, спасибо, покопаю в эту сторону...

K>> Нет, всего лишь 16 секунд против 18.
B>Мда. Тогда, наверное Win Service будет хорошим вариантом. Единственная проблема что он память будет жрать, пока юзер его не остановит.

Если память течь не будет, то это не страшно.

K>> Что именно придется писать самому? Скрипт для инсталлятора или свой мини-инсталлятор?
B>"Обновлятор". Кстати, тут есть вторая проблема. А что если нужно обновить версию Java?

Про это я даже не думал.

K>>Хочется чтобы приложение обновлялось полностью незаметно для пользователя и максимально стабильно — если при обновлении что-то не заработает, то хотя бы откатывалось к предыдущей версии.
K>>Как это лучше сделать?
B>Скачать и забэкапить всё в фоновом режиме, не отрывая юзера от работы. А потом быстро-быстро заменить файлы и переключить юзера на новую версию.

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