OSGi从根本上与JSR-223脚本语言发现不兼容吗？ [英] Is OSGi fundamentally incompatible with JSR-223 Scripting Language Discovery?
问题描述
我最近编写了一个小型专业脚本语言，并使用Maven导出符合OSGi的捆绑包，该捆绑包还将服务描述符导出到 META-INF / services / javax.script.ScriptEngineFactory 服务注册文件。
I've recently written a small specialist scripting language and used the Maven to export an OSGi compliant bundle that also exports a service descriptor into the "META-INF/services/javax.script.ScriptEngineFactory" service registry file.
问题是虽然OSGi导入和导出包很好，但服务注册表似乎与OSGi不兼容（因为OSGi将其捆绑包保留在通用类路径之外，并为模块使用单独的类加载器。）
The problem is that although the OSGi import and export packages are fine, the service registry appears to be incompatible with OSGi (as OSGi keeps its bundles off the general classpath and uses separate classloaders for modules).
我的问题是，我认为OSGi与服务发现机制不兼容是正确的，如果没有，我可以添加什么到我的包元数据，以便 ScriptEngineManager.getEngineFactories（）将在OSGi环境中列出我的脚本引擎？
My question is, am I correct in thinking that OSGi is incompatible with the Service Discovery mechanism, and if not, what can I add to my bundle metadata so that ScriptEngineManager.getEngineFactories() will list my script engine in an OSGi environment?
推荐答案
Apache Sling 确实在OSGi环境中使用此机制来管理它的JSR-233兼容脚本引擎，主要是通过它的ScriptEngineManagerFactory类[1]。另请参阅[2]以获取示例自定义脚本引擎。
Apache Sling does use this mechanism in an OSGi environment to manage its JSR-233 compatible script engines, mostly via its ScriptEngineManagerFactory class [1]. See also [2] for an example custom script engine.
如果JSR-233兼容，则将脚本引擎添加到Sling应该可以正常工作。最简单的测试方法可能是使用你的语言而不是那里使用的服务器端javascript语言，遵循15分钟内的Sling教程[3]。
Adding your script engine to Sling should work if it's JSR-233 compatible. The simplest way to test that is probably to follow the "Sling in 15 minutes" tutorial [3] using your language instead of the server-side javascript language that's used there.
[2] http://svn.apache.org/repos/asf/sling/trunk/bundles/scripting/javascript
[3] http://sling.apache.org/site/discover-sling-in-15-minutes。 html
这篇关于OSGi从根本上与JSR-223脚本语言发现不兼容吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
