т.е. альтернативного(по отношению к osgi) стандарта у сана нет, есть просто небольшой jdk refactoring, на который не стоит заводить jsr.
а вот после него(рефакторинга) уже можно поговорить о том, какой стандарт для модуляризации имеет смысл поддерживать. clear ?
На мой взгляд, реальных, "готовых к употреблению" возможностей действительно две, но несколько иные:
1. Упомянутый вами OSGi
2. Библиотека Java Plug-in Framework — нестандартная, но простая в использовании и легковесная альтернатива OSGi.
Всё остальное будет скорее всего либо заброшенными, не доведёнными до ума проектом, либо будет нуждаться в "доработке топором и напильником" (как в случае с JBoss).
//Дмитрий Ольшанский
Здравствуйте, Дмитрий Писаренко, Вы писали:
ДП>Здравствуйте!
ДП>Я хочу сделать одну программу, и изначально разбить её на несколько модулей так, чтобы можно было
ДП>а) включать/отключать некоторые модули во время выполнения (run-time) для того, чтобы сэкономить ресурсы,
ДП>б) заменять модуль версии X на модуль версии Y во время выполнения, не трогая (не компилируя, ДП>не останавливая) другие модули, если они не связаны с заменяемым модулем,
ДП>в) добавлять функционал во время выполнения, добавляя новые модули (опять-таки, не трогая уже установленные).
ДП>Контейнер, который будет обеспечивать эти 3 функции, должен соответствовать следующим критериям:
ДП>1) Легковесность — контейнер не должен требовать слишком много ресурсов (пустой контейнер без ДП>дополнительных функций должен весить не более 10 МБ).
ДП>2) Универсальность — важно, чтобы можно было устанавливать любые модули, от окошка на базе Swing, ДП>модуля для связи с базой данных до веб-сервера.
ДП>3) Желательно, но не обязательно: В конфигурации модуля можно прописать, что он (модуль) будет работать ДП>только, если установлен другой модуль. Если при инсталляции во время выполнения требуемый модуль отстутствует в ДП>контейнере, то контейнер сообщает об этом пользователю и не запускает инсталлируемый модуль.
ДП>4) Обязательно: Контейнер должен быть с открытым исходником, разрешающим применение в коммерческих приложениях.
ДП>Я нашёл 2 принципиальные возможности сделать такой контейнер:
ДП>1) Каркас на базе OSGi, например, Apache Felix, Equinox или Knopflerfish
ДП>2) Микро-ядро JBoss — взять JBoss и выдрать из него всё, кроме механизмов работы с модулями.
ДП>Вопрос: Какие ещё варианты есть и какие из них кажутся Вам оптимальными?
ДП>Заранее благодарен
ДП>Дмитрий Писаренко
Здравствуйте, Дмитрий Писаренко, Вы писали:
ДП>Здравствуйте!
ДП>Всем спасибо за ответы!
ДП>Я немного ознакомился с OSGi и возникли такие вопросы:
ДП>1) Какие есть существенные отличия между Equinox и Apache Felix?
Если пользоваться исключительно стандартными сервисами, то по сути никаких. А так — у Equinox есть достаточно немалое количество расширений, которыми иногда удобно воспользоваться.
При использовании OSGI, пожалуй, наибольшее количество неприятностей связано с ClassLoader-ом. Использование OSGI делает сложным работу, например, с ORM-ами без доработки напильниками (ORM не видит пользовательских классов). С одной стороны, можно расширять classpath hibernate-а при помощи fragment bundles, но в этом случае количество фрагментов катастрофически растет. Для борьбы с этим в eclipse сделали свои расширения: http://wiki.eclipse.org/Context_Class_Loader_Enhancements
Проблема такого рода специфична не только относительно к ORM, но и для всех библиотек, так или иначе использующих reflection при работе с пользовательскими классами. Танцы с бубном вокруг GWT
Пользоваться ими, или нет — решать каждому, но все-таки они добавляют удобства.
ДП>2) Поддерживает ли Apache Felix фрагменты?
Я хочу сделать одну программу, и изначально разбить её на несколько модулей так, чтобы можно было
а) включать/отключать некоторые модули во время выполнения (run-time) для того, чтобы сэкономить ресурсы,
б) заменять модуль версии X на модуль версии Y во время выполнения, не трогая (не компилируя,
не останавливая) другие модули, если они не связаны с заменяемым модулем,
в) добавлять функционал во время выполнения, добавляя новые модули (опять-таки, не трогая уже установленные).
Контейнер, который будет обеспечивать эти 3 функции, должен соответствовать следующим критериям:
1) Легковесность — контейнер не должен требовать слишком много ресурсов (пустой контейнер без
дополнительных функций должен весить не более 10 МБ).
2) Универсальность — важно, чтобы можно было устанавливать любые модули, от окошка на базе Swing,
модуля для связи с базой данных до веб-сервера.
3) Желательно, но не обязательно: В конфигурации модуля можно прописать, что он (модуль) будет работать
только, если установлен другой модуль. Если при инсталляции во время выполнения требуемый модуль отстутствует в
контейнере, то контейнер сообщает об этом пользователю и не запускает инсталлируемый модуль.
4) Обязательно: Контейнер должен быть с открытым исходником, разрешающим применение в коммерческих приложениях.
Я нашёл 2 принципиальные возможности сделать такой контейнер:
Здравствуйте, Nicht, Вы писали:
N>OSGi по любому. Скоро он станет стандартом дефакто.
Как там продвигается война с альтернативным Сановским стандартом?
Здравствуйте, Blazkowicz, Вы писали:
B>Здравствуйте, Nicht, Вы писали:
N>>OSGi по любому. Скоро он станет стандартом дефакто. B>Как там продвигается война с альтернативным Сановским стандартом?
Сильно не слежу. Но были слухи что они от него откажутся в пользу OSGi. Судя по странице JSR-277 они с 2006 года там залипли. Так что войны то никакой и нет.
на который не стоит заводить jsr.
