Развертывание Библиотек

[lmike]

Хотя конкретно буду говорить про jar, но топик затрагивает (так или иначе) общую схему разработки
Существует набор клиентов Нотуса (в каждой организации) и на данный момент, спектр от 7.х до 9.х
Перспектива у 7.х отсутствует, но миграция не моментальное явление, отсюда вопрос - как развертывать либы?

Для 7.х можно гондыбать БД с либами и отслеживать их версии на локальной машине

Для старших версий нотусни - как-то не красиво, а отсюда второй вопрос - как сделать красиво?

вродиб как есть

Ссылка скрыта от гостей

но прямого механизма там не увидел, да и хорошобы увязать это с системами сборки (

Ссылка скрыта от гостей

ну и финальный вопрос - кто-то думал на эту тему?

 

[lmike]

Ссылка скрыта от гостей

вполне себе концепция, но несколько не с той стороны

 

[lmike]

нашёл базу, но опять - метод модификации локального пути

Ссылка скрыта от гостей

 

[savl]

lmike
Давай по пунктам разберем:
1. Чтобы jar нормально заработал его лучше положить в папку на сервере. (...\Notes\jvm\lib\ext\)
2. Все такие jar надо прописать в ini с путями к ним (JavaUserClassesExt=commonsnet
commonsnet=...\Notes\jvm\lib\ext\commons-net-2.0.jar)
3. Перезагрузить сервер
Если SET CONFIG в консоли позволяет добавлять файлы в ini и не надо перезагружать сервер, то уже хорошо, проще.
Я с java в ln мало встречался, поэтому не знаю многого, но если необходимо указывать пути к jar'ам - по другому не сделать.
Следовательно, какое бы решение не выбрал, лучшее на мой взгляд как в базе по ссылке.

 

[garrick]

lmike
Давай по пунктам разберем:
1. Чтобы jar нормально заработал его лучше положить в папку на сервере. (...\Notes\jvm\lib\ext\)
2. Все такие jar надо прописать в ini с путями к ним (JavaUserClassesExt=commonsnet
commonsnet=...\Notes\jvm\lib\ext\commons-net-2.0.jar)
3. Перезагрузить сервер
Если SET CONFIG в консоли позволяет добавлять файлы в ini и не надо перезагружать сервер, то уже хорошо, проще.
Я с java в ln мало встречался, поэтому не знаю многого, но если необходимо указывать пути к jar'ам - по другому не сделать.
Следовательно, какое бы решение не выбрал, лучшее на мой взгляд как в базе по ссылке.

1. Если это быдет выполняться на сервере. А если же локально, то надо и на локального клиента тоже.
2. Что лежит в JVM/LIB/EXT никуда прописывать не надо, оно работает и так. А если же какой-то JAR положить в другое место, вот тогда необходимо указать это через параметр JavaUserClassesExt в NOTES.INI.
3. Перезагрузить сервер или клиента надо в любом случае. SET CONFIG в консоли не поможет.

Других вариантов распространения Java библиотек (JAR), кроме как положить в виде аттачмента в агента или библиотеку, что так же имеет свои минусы, я не знаю, да и, по-моему, IBM ничего более не предусмотрели... ну или, по крайней мере, никому не рассказали.

P.S. А вы в курсе, что в Run-Time можно использовать классы из файлов, которые лежат в Notes\ndext, SWT в часности, хотя они (пути к ним) нигде не прописаны?

 

[lmike]

P.S. А вы в курсе, что в Run-Time можно использовать классы из файлов, которые лежат в Notes\ndext, SWT в часности, хотя они (пути к ним) нигде не прописаны?

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

Добавлено: 2 savl

2. Что лежит в JVM/LIB/EXT никуда прописывать не надо, оно работает и так

замена jar (удаление/замена версии с сохранением идентификации, в имени файла) может повлечь переписывание всей строки, что неудобно
и в общем - управление версиями будет проще в варианте JavaUserClassesExt
опятьже - не всегда удобно копаться внутри нотес каталога

 

[garrick]

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

Я имел ввиду, что они доступны в runt-time вашим Java агентам или библиотекам и при этом никуда их посовывать, копировать и прописывать не надо. Тут есть только небольшие хитрости с компиляцией вашего Java кода. Нужно в Eclipse указать ссылку на библиотеку, которая сразу же пропадёт как только вы её закроете, т.к. Domino Designer почему-то не умеет их сохранять. Но работу в дальнейшем это никак не влияет.

Добавлено: 2 savl замена jar (удаление/замена версии с сохранением идентификации, в имени файла) может повлечь переписывание всей строки, что неудобно

Не понял о какой вы строке? Всё что лежит в каталоге JVM/LIB/EXT никуда прописывать не надо, оно автоматически грузится со стартом JVM, имена файлов в этом случае вообще не имеют значение, только имена классов внутри них.

и в общем - управление версиями будет проще в варианте JavaUserClassesExt

А вот тут уже имена файлов важны.

 

[lmike]

вся эта тема возникла из желания привлечь штатный механизм (к-л)
updateSite - один из них
возможно Ext... предоставляет доп. методы, но я о них не знаю

Добавлено:

Не понял о какой вы строке? Всё что лежит в каталоге JVM/LIB/EXT никуда прописывать не надо, оно автоматически грузится со стартом JVM, имена файлов в этом случае вообще не имеют значение, только имена классов внутри них.

я об управлении версиями, просто некорректно написал (о др. думал oo: )

 

[garrick]

Насколько я понимаю с UpdateSite вы можете распространять только сервис паки и плагины, которых, кстати, в семёрке нет.

 

[lmike]

Насколько я понимаю с UpdateSite вы можете распространять только сервис паки и плагины, которых, кстати, в семёрке нет.

о том и речь, но с плагином появятся и либы!

 

[lmike]

которые лежат в Notes\ndext

если речь о том что там уже лежит - то разницы никакой

 

[garrick]

о том и речь, но с плагином появятся и либы!

Вы не сможете использовать эти либы в вашей базе Lotus Notes.

 

[garrick]

если речь о том что там уже лежит - то разницы никакой

Речь о том, что вы может положить туда всё что поместится.

 

[lmike]

Речь о том, что вы может положить туда всё что поместится.

поясню..., я хочу положить jar, он сразу его подхватит, без перезагрузки нотусни?
я хочу заменить jar - он будет залочен до перезагрузки?
если все как и с lib/ext - то смысла не вижу

Добавлено:

Вы не сможете использовать эти либы в вашей базе Lotus Notes.

или смогу - в том и вопрос

 

[garrick]

поясню..., я хочу положить jar, он сразу его подхватит, без перезагрузки нотусни?
я хочу заменить jar - он будет залочен до перезагрузки?
если все как и с lib/ext - то смысла не вижу

Не понял. Это про что?
Если про lib/ext, то без перезагрузки не подхватит, будет залочен.
Если про ndext, то речь о том, что там есть некоторые библиотеки, например SWT, у каждого клиента своя версия. Допустим я хочу использовать SWT в своей базе, и с помощью небольшого хака я могу хадействовать эту "нативную" SWT из комплекта клиента, а не вешать на свою базу свою версию библиотеки. Следует также помнить что эта библиотека платформозависима, т.е. для Windows, Linux, MacOS - разные версии, а у клиента уже есть правильная версия. Это просто "интересная" информация - вдруг пригодится, ничего своего я бы туда класть не советовал, т.к. не до конца понятно что и как Лотус сам с этим делает.

Добавлено: или смогу - в том и вопрос

Точно нет.

Использовать "заранее не подключенный" JAR из произвольного места наверное можно было бы с помощью Spring, но вряд ли удастся малой кровью подружить его с Лотусом.


Добавлено: Если у вас такая проблема с распространением библиотек, кладите их в лотусовые библиотеки в виде аттачментов. Правда для агентов по расписанию, да ещё часто запускаемых, я бы не советовал.

 

[lmike]

понятно, спасибо...

Добавлено:

Если у вас такая проблема с распространением библиотек, кладите их в лотусовые библиотеки в виде аттачментов. Правда для агентов по расписанию, да ещё часто запускаемых, я бы не советовал.

это не вариант

 

[turumbay]

Для старших версий нотусни - как-то не красиво, а отсюда второй вопрос - как сделать красиво?

У меня сейчас примерно так

Серверная часть целиком на OSGI бандлах( aka plugins). LS на сервере не используется вообще.
Инструменты: maven,

Ссылка скрыта от гостей

, среда разработки - Idea, контроль версий - git, web framework -

Ссылка скрыта от гостей

, шедулер -

Ссылка скрыта от гостей

, логирование - pax logging, язык разработки - scala.

Разработка и тестирование ведется на локальной машине. ОС значения не имеет ( есть правда небольшие заморочки с настройкой окружения под MacOS ). Выкатывание на сервер - через update site или ручное обновление ( tell http osgi update ...)
Сборка update site ведеца в отдельном eclipse проекте, хотя есть планы попробовать

Ссылка скрыта от гостей

С клиентом все сложнее.
Вообще, ИМХО, разработка под нотусового клиента - тупиковое направление. Однако, как и у большинству жителей форума, отказаться от клиента полностью невозможно, из-за наличия большого количества legacy приложений.
Ситуация с легаси следующая - из "тяжелых" библиотек используется только jasper-report ( ~7 Mb с зависимостями ). Он выложен в lib/ext на клиенте. Обновления не производятся, много лет используется древняя версия 3.6.1. Остальной java-код живет в шаблонах баз, обновляется штатными средствами. Все "экзотические" задачи вынесены на сервер. Весь legacy код вынесен в отдельный проект, сборка выполняется мавеном, обновление в шаблонах баз - ручное. Чтобы не дублировать серверную и клиентские части - общий функционал живет в отдельном подпроекте. Т.о. проблема обновления jar-ов на клиенте лично у меня - отсутствует.

Паралельно идет переписывание legacy под тонкого клиента, в течение следующего года планируется полный отказ от нотусового клиента.
Как вариант - рассматривался переход на standard клиента и использование клиентского OSGI ( читай - плагины ). Это решает массу проблем традиционной разработки под клиента, позволяя использовать тот же стек технологий, что и при разработке серверной части. Однако плюсы перехода на web перевесили: в итоге получается быстрее и дешевле( нужны обычные фронтенд разработчики без знания специфики domino )

P.S. Есть небольшой туториал по использованию OSGI в домино

[Edited] Посмотрел lib/ext. Кроме джаспера еще лежит не очень свежая scala-library. Как и джаспер, накатывается в lib/ext при установке клиента(точнее - при первом обращении к любой базе проекта). Тоже не обновляется. Собсна наличие этой штуки позволяет весь остальной код пихать прямо в базу, т.к. стандарной библиотеки scala хватает (в данном конкретном проекте) для решения большинства клиентских задач.

 

[lmike]

OSGI

подход - заманчиво - нра одназначна, надо заняться освоением.
Т.к. есть БД с МСО файлами - нужны будут либы POI (ну и

Ссылка скрыта от гостей

, до кучи), а мутной перспективе - FOP, дабы РТ нотусовое задействовать параллельно
Т.о. планируя апдейт региональных компов на 9-ку задумался над централизацией и управлением либами
концепция плагинов замечательно уписывается и в UpdateSite, что +
спасибо

 

[garrick]

У меня сейчас примерно так

Серверная часть целиком на OSGI бандлах( aka plugins). LS на сервере не используется вообще....

Следующий шаг - заменить Domino на Tomcat или Jetty.
Станет ещё легче.

 

[turumbay]

Следующий шаг - заменить Domino на Tomcat или Jetty.
Станет ещё легче.

Дык пробовали... Не станет.