OSGi从根本上与JSR-223脚本语言发现不兼容吗？

Question

我最近编写了一个小型专业脚本语言，并使用Maven导出符合OSGi的捆绑包，该捆绑包还将服务描述符导出到“META-INF/services/javax.script.ScriptEngineFactory”服务注册表文件中。

问题是虽然OSGi导入和导出包很好，但服务注册表似乎与OSGi不兼容（因为OSGi将其捆绑包保留在通用类路径之外，并为模块使用单独的类加载器）。

我的问题是，我认为OSGi与服务发现机制不兼容是正确的，如果没有，我可以添加到我的包元数据中，以便ScriptEngineManager.getEngineFactories()在OSGi环境中列出我的脚本引擎？

Answer 1

Apache Sling确实在OSGi环境中使用这种机制来管理它的JSR-233兼容脚本引擎，主要是通过它的ScriptEngineManagerFactory类[1]。另请参见[2]以获取示例自定义脚本引擎。

如果JSR-233兼容，则将脚本引擎添加到Sling应该可以正常工作。最简单的测试方法可能是使用您的语言而不是在那里使用的服务器端JavaScript语言，遵循“15分钟内的Sling”教程[3]。

[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

Answer 2

Matt F.写了一篇关于替代解决方案的博客[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服务的脚本访问。使用ServiceTracker api [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

Answer 3

只是因为在OSGi环境中有一个标准的通用解决方案来消费这些类型的服务，因为ScriptEngineFactory不是唯一的这种情况。它是OSGi Enterprise规范的一部分。并且可以在此处找到参考实现：http://aries.apache.org/modules/spi-fly.html

通过这种机制重新创建Apache Spring类的功能是微不足道的，而且这种方法更清晰，更明智，但我确实理解避免重新实现轮的愿望。