Здравствуйте, 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 секунд, ну и процесс ручного управления распаковкой, копированием и пр. довольно хрупок и в случае падения может понадобиться руками чинить.