¿OSGi es fundamentalmente incompatible con JSR-223 Scripting Language Discovery?

Question

Recientemente escribí un pequeño lenguaje de scripting especializado y utilicé el Maven para exportar un paquete compatible con OSGi que también exporta un descriptor de servicio en el archivo de registro de servicio "META-INF/services/javax.script.ScriptEngineFactory".

El problema es que aunque los paquetes de importación y exportación OSGi son correctos, el registro de servicio parece ser incompatible con OSGi (ya que OSGi mantiene sus paquetes fuera del classpath general y utiliza classloaders para módulos).

Mi pregunta es, ¿estoy en lo cierto al pensar que OSGi es incompatible con el mecanismo de Service Discovery? Si no, ¿qué puedo agregar a los metadatos de mi paquete para que ScriptEngineManager.getEngineFactories() muestre el motor de script en un entorno OSGi?

Answer 1

Apache Sling utiliza este mecanismo en un entorno OSGi para gestionar sus motores de scripts compatibles con JSR-233, principalmente a través de su clase ScriptEngineManagerFactory [1]. Ver también [2] para un ejemplo de motor de script personalizado.

Agregar el motor de script a Sling debería funcionar si es compatible con JSR-233. La forma más sencilla de probar eso es probablemente seguir el tutorial "Sling in 15 minutes" [3] utilizando su idioma en lugar del lenguaje javascript del lado del servidor que se usa allí.

[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. escribió sobre una solución alternativa [1]

Al proporcionar scripting en una Aplicación Java, los motores de scripting conforme a JSR 223 (p. Ej., Groovy, JRuby, Scala, ...) pueden incorporarse fácilmente usando algo ng lo largo de las líneas de

ScriptEngineManager scriptEngineManager = new ScriptEngineManager(); 
ScriptEngine scriptEngine = scriptEngineManager.getByName("groovy"); 

Sin embargo, en una aplicación basada en OSGi, el ScriptEngineManager falla para descubrir motores de secuencias ubicadas en lotes instalados, debido a la forma en que se descubre motores disponibles en la ruta de clase. Afortunadamente, el proyecto Apache Felix ya ha resuelto este problema, hay

• OSGiScriptEngineManager [2]
• OSGiScriptEngineFactory [3]
• OSGiScriptEngine [4]

que proporcionan un OSGi- forma compatible para descubrir y cargar motores de scripting instalados como paquetes OSGi.

ScriptEngineManager scriptEngineManager = new OSGiScriptEngineManager(bundleContext); 
ScriptEngine scriptEngine = scriptEngineManager.getByName("groovy"); 

[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

Answer 3

Sólo a sonar en que hay una norma general sol para consumir estos tipos de servicios en un entorno OSGi, ya que ScriptEngineFactory no es el único caso. Es parte de las especificaciones de OSGi Enterprise. y la implementación de referencia se puede encontrar aquí: http://aries.apache.org/modules/spi-fly.html

Es trivial para recrear la funcionalidad de las clases de Apache Spring a través de este mecanismo, y este método es mucho más limpio y más sensible, pero entiendo el deseo de evitar volver a implementar la rueda, por así decirlo.