Является ли OSGi принципиально несовместимым с JSR-223 Scripting Language Discovery?
Недавно я написал небольшой специализированный язык сценариев и использовал Maven для экспорта OSGi-совместимого пакета, который также экспортирует дескриптор службы в "META-INF/services/javax.script.ScriptEngineFactorymsgstr "файл реестра службы.
Проблема заключается в том, что, хотя пакеты импорта и экспорта OSGi в порядке, реестр служб выглядит несовместимым с OSGi (поскольку OSGi не связывает свои пакеты с общим путем к классам и использует отдельные загрузчики классов для модулей).
У меня вопрос, правильно ли я считаю, что OSGi несовместим с механизмом обнаружения служб, и если нет, что я могу добавить в метаданные своего пакета, чтобы ScriptEngineManager.getEngineFactories() перечислит мой скрипт-движок в среде OSGi?
3 ответа
Apache Sling действительно использует этот механизм в среде OSGi для управления своими JSR-233-совместимыми механизмами сценариев, в основном через класс ScriptEngineManagerFactory [1]. Смотрите также [2] для примера собственного скриптового движка.
Добавление вашего скриптового движка в Sling должно работать, если оно совместимо с JSR-233. Самый простой способ проверить это, вероятно, следовать учебнику "Слинг за 15 минут" [3], используя ваш язык вместо серверного языка JavaScript, который там используется.
[2] http://svn.apache.org/repos/asf/sling/trunk/bundles/scripting/javascript
[3] http://sling.apache.org/site/discover-sling-in-15-minutes.html
Мэтт Ф. написал об альтернативном решении [1]
При предоставлении сценариев в приложении Java механизмы сценариев, соответствующие JSR 223 (например, Groovy, JRuby, Scala, ...), могут быть легко встроены с использованием чего-то вроде
ScriptEngineManager scriptEngineManager = new ScriptEngineManager(); ScriptEngine scriptEngine = scriptEngineManager.getByName("groovy");Однако в приложении на основе OSGi ScriptEngineManager не удается обнаружить механизмы сценариев, расположенные в установленных пакетах, из-за способа обнаружения механизмов, доступных в пути к классам. К счастью, проект Apache Felix уже решил эту проблему, есть
- OSGiScriptEngineManager [2]
- OSGiScriptEngineFactory [3]
- OSGiScriptEngine [4]
которые предоставляют OSGi-совместимый способ обнаружения и загрузки скриптовых движков, установленных в виде OSGi-пакетов.
ScriptEngineManager scriptEngineManager = new OSGiScriptEngineManager(bundleContext); ScriptEngine scriptEngine = scriptEngineManager.getByName("groovy");
Теперь, когда у нас есть несколько лет опыта работы со сценариями и OSGi, одной из задач является упрощение доступа сценариев к службам OSGi. Использование API ServiceTracker [5] представляется единственным подходом; но это усилие для простых сценариев. Мы разработали средства для сценариев, чтобы выразить, какие сервисы OSGi они хотят, и автоматизировать вызовы ServiceTracker от имени сценариев, но это хрупко. Ждем спецификации OSGi, предлагающей лучшую поддержку в будущем.
[1] http://devnotesblog.wordpress.com/2011/09/07/scripting-using-jsr-223-in-an-osgi-environment/
[5] https://osgi.org/javadoc/osgi.core/7.0.0/org/osgi/util/tracker/ServiceTracker.html
Просто поймите, что существует стандартное общее решение для использования этих типов сервисов в среде OSGi, так как ScriptEngineFactory - не единственный такой случай. Это часть спецификации OSGi Enterprise. и справочную реализацию можно найти здесь: http://aries.apache.org/modules/spi-fly.html
Через этот механизм тривиально воссоздать функциональность классов Apache Spring, и в этом случае этот метод гораздо чище и разумнее, но я понимаю желание избежать, так сказать, повторной реализации колеса.