OSGi принципиально несовместим с JSR-223 Scripting Language Discovery?

Недавно я написал небольшой специализированный язык сценариев и использовал Maven для экспорта пакета, совместимого с OSGi, который также экспортирует дескриптор службы в файл реестра службы «META-INF/services/javax.script.ScriptEngineFactory».

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

Мой вопрос заключается в том, правильно ли я считаю, что OSGi несовместим с механизмом обнаружения служб, и если нет, то что я могу добавить в метаданные своего пакета, чтобы ScriptEngineManager.getEngineFactories() отображал мой скриптовый движок в среде OSGi?


java jsr223 osgi
person Chris    schedule 02.07.2011    source источник
comment
Другое несоответствие JSR-223 и OSGi заключается в том, что во время выполнения сценарии обычно хотят импортировать классы. Однако OSGi предпочитает, чтобы пакеты определяли импорт во время сборки, объявляя их в файле JAR META-INF/MANIFEST.MF пакета. Директива DynamicImports-Package с подстановочным знаком может обойти эту проблему за счет упрощения управления версиями JAR в OSGi.   -  person buzz3791    schedule 22.06.2012

Ответы (3)


arrow_upward
7
arrow_downward

Apache Sling использует этот механизм в среде OSGi для управления обработчиками сценариев, совместимыми с JSR-233, в основном через класс ScriptEngineManagerFactory [1]. См. также [2] пример пользовательского скриптового движка.

Добавление вашего скриптового движка в Sling должно работать, если он совместим с JSR-233. Самый простой способ проверить это, вероятно, состоит в том, чтобы следовать руководству «Sling in 15 minute» [3], используя ваш язык вместо используемого там языка javascript на стороне сервера.

[1] http://svn.apache.org/repos/asf/sling/trunk/bundles/scripting/core/src/main/java/org/apache/sling/scripting/core/impl/ScriptEngineManagerFactory.java

[2] http://svn.apache.org/repos/asf/sling/trunk/bundles/scripting/javascript

[3] http://sling.apache.org/site/discover-sling-in-15-minutes.html

person Bertrand Delacretaz    schedule 03.07.2011
comment
Спасибо за ссылку. Думаю, я могу отослать пользователей к вашему ответу, если они захотят интегрировать мой скриптовый язык в среду OSGi. - person Chris; 04.07.2011
comment
Я знаю, что это очень старый пост, но кажется, что последняя ссылка не содержит тех же примеров, что и раньше. Я изо всех сил пытаюсь ссылаться на службу в моем сервлете - person Thomas; 04.05.2016

arrow_upward
5
arrow_downward

Мэтт Ф. написал в блоге об альтернативном решении [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/

[2] http://svn.apache.org/repos/asf/felix/trunk/mishell/src/main/java/org/apache/felix/mishell/OSGiScriptEngineManager.java

[3] http://svn.apache.org/repos/asf/felix/trunk/mishell/src/main/java/org/apache/felix/mishell/OSGiScriptEngineFactory.java

[4] http://svn.apache.org/repos/asf/felix/trunk/mishell/src/main/java/org/apache/felix/mishell/OSGiScriptEngine.java

[5] https://osgi.org/javadoc/osgi.core/7.0.0/org/osgi/util/tracker/ServiceTracker.html

person buzz3791    schedule 25.05.2012

arrow_upward
0
arrow_downward

Просто отметим, что существует стандартное общее решение для использования этих типов служб в среде OSGi, поскольку ScriptEngineFactory — не единственный такой случай. Это часть спецификации OSGi Enterprise. и эталонную реализацию можно найти здесь: http://aries.apache.org/modules/spi-fly.html

Тривиально воссоздать функциональность классов Apache Spring с помощью этого механизма, и imo этот метод намного чище и разумнее, но я понимаю желание избежать, так сказать, повторной реализации колеса.

person Elias Vasylenko    schedule 28.10.2016