Hacer que el compilador Scala funcione dentro de un tiempo de ejecución OSGi

Question

Estoy usando un motor de plantillas Scala (Scalate) para compilar plantillas en tiempo de ejecución dentro de un entorno OSGi (Scala 2.9.1). Las plantillas no se pueden compilar previamente porque están compiladas dinámicamente.

Para que esto funcione, el compilador Scala necesita ejecutarse dentro del entorno OSGi. Sin embargo, dado que el compilador de Scala no puede tomar un cargador de clases como entrada, esto no funciona de la caja.

De mi investigación, parece que hay dos solución general se aproxima a:.

1) Un plugin Scala compilador (there is one started here pero no se ha tocado desde el año 2009, y messages on the scala list in 2009 declarado que no estaba listo para su uso en producción

2) Creación de un sistema de archivos virtual sobre el contexto del paquete que luego podría ser utilizado por el compilador de Scala. Al parecer, los chicos de Sling Apache tienen successfully utilizan este enfoque en una versión anterior de Scala.

¿Alguien ha conseguido que Scalate, Scala 2.9.1 y OSGi trabajen juntos para compilar dinámicamente plantillas?

Answer 1

Mi equipo ahora tiene la compilación y la ejecución de Scala trabajando para Scalate dentro de OSGi.

En general, la configuración de ScalaCompiler se debe proporcionar con un conjunto de objetos AbstractFile que corresponden a los paquetes OSGi relevantes. Esto es compatible con Guggla según lo referenciado por @michid. Pero aunque Guggla proporciona la capa AbstractFile, todavía no proporciona ningún ejemplo o código sobre cómo crear las instancias de AbstractFile en un entorno OSGi. El código de ejemplo para hacer esto último se puede encontrar en el proyecto Sling (el origen de Guggla mismo) así como en el proyecto Scalate (vea ScalaCompiler pero tenga en cuenta nuestros cambios a continuación).

Elegimos los paquetes scala OSGi-ified (compiler y) del proyecto ServiceMix. Consulte issue SMX-1048 (with patch) en el paquete scala-compiler.

Nuestra intención original era hacer que esto funcionara en Scalate, por lo que el resto de esta respuesta es específica para ese proyecto.

El código Scalate ya tenía la mayor parte de la lógica necesaria para trabajar dentro de un entorno OSGi, incluida la capa de AbstractFile virtual, así como la configuración de la vía de acceso del compilador. Sin embargo teníamos que arreglar Scalate (https://github.com/scalate/scalate/pull/16) para que funcione:

1) La anulación OsgiCompiler de la clase ScalaCompiler no se está activando correctamente, y así agrupar de que no se habían detectado como entradas de ruta de clases para el compilador, y

2) El cargador de clases de ejecución de plantillas (tiempo de ejecución) se estaba configurando en el cargador de clases del paquete scalate-core, lo que dio como resultado CNFE en tiempo de ejecución.

La solicitud de extracción anterior configura Escalar en un entorno OSGi de forma predeterminada en el cargador de clases de contexto de hilos en tiempo de ejecución. Esa parece ser la forma más fácil de obtener una referencia al cargador de clases del llamante sin que el llamador tenga que inyectarla explícitamente (por ejemplo, una declaración Spring-DM osgi:service exportando un servicio de plantilla puede usar el atributo context-class-loader="service-provider" para establecer esto automáticamente. Esto también hace el comportamiento en tiempo de ejecución de Scalate OSGi se corresponde con el comportamiento de tiempo de compilación existente que ya utilizó el TCCL

Por lo tanto, un llamante a Scalate debe establecer el TCCL en su propio cargador de clases o inyectar explícitamente el cargador de clases deseado al motor de plantillas, por ejemplo templateEngine.classLoader = ... antes de ejecutar la plantilla

Actualización 31-Ago-2012: Scalate master ahora contiene todos los parches mencionados en esta publicación.

Actualización 10-Abr-2013: Scalate 1.6.1, con compilación de plantilla de tiempo de ejecución mediante el compilador de Scala, es compatible con OSGi. Además, Scala 2.10 y versiones posteriores son paquetes OSGi válidos según lo publicado.

Answer 2

Creo que debe establecer la política de amigos. Lo siguiente debería ayudar.

http://wiki.eclipse.org/index.php/Context_Class_Loader_Enhancements#Buddy_Policy

http://www.eclipsezone.com/eclipse/forums/t90282.html

http://help.eclipse.org/indigo/topic/org.eclipse.platform.doc.isv/reference/misc/bundle_manifest.html

En su paquete se puede decir que es necesario utilizar el mismo cargador de clases como otro paquete.