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。

如果脚本引擎与JSR-233兼容，那么将脚本引擎添加到Sling应该是可行的。测试的最简单方法可能是使用您的语言，而不是使用那里使用的服务器端javascript语言，按照“15分钟内的吊索”教程3进行测试。

1

2

3

Answer 2

Matt F.在博客上介绍了另一种解决方案1

在Java应用程序中提供脚本时，遵循JSR223的脚本引擎(例如Groovy、JRuby、Scala...)可以很容易地使用类似于

ScriptEngineManager scriptEngineManager =新建ScriptEngineManager()；ScriptEngine scriptEngine = scriptEngineManager.getByName("groovy")；

然而，在基于OSGi的应用程序中，由于ScriptEngineManager发现类路径上可用的引擎的方式，它无法发现位于已安装包中的脚本引擎。幸运的是，Apache Felix项目已经解决了这个问题，有

• OSGiScriptEngineManager 2
• OSGiScriptEngineFactory 3
• OSGiScriptEngine 4

它提供了一种兼容OSGi的方式来发现和加载作为OSGi包安装的脚本引擎。

ScriptEngineManager scriptEngineManager =新OSGiScriptEngineManager(bundleContext)；ScriptEngine scriptEngine = scriptEngineManager.getByName("groovy")；

既然我们已经有了几年的脚本和OSGi经验，其中一个挑战就是简化对OSGi服务的脚本访问。使用ServiceTracker API5似乎是唯一的方法；但是对于简单的脚本来说，这是一项很高的工作。我们一直致力于为脚本提供一种方式来表达他们想要的OSGi服务，并代表脚本自动化ServiceTracker调用，但它是脆弱的。期待OSGi规范在未来提供更好的支持。

1

2

3

4

5

Answer 3

顺便说一句，在OSGi环境中使用这些类型的服务有一个标准的通用解决方案，因为ScriptEngineFactory并不是唯一这样的情况。它是OSGi企业规范的一部分。参考实现可以在这里找到：http://aries.apache.org/modules/spi-fly.html

通过这种机制重新创建Apache Spring类的功能是微不足道的，而且在我看来，这种方法要干净得多，也更明智，但我确实理解避免重复实现轮子的愿望。