Getting the scala compiler to work inside an OSGi runtime

Question

I am using a Scala template engine (Scalate) to compile templates at runtime within an OSGi environment (Scala 2.9.1). The templates cannot be pre-compiled because they are built dynamically.

In order for this to work, the Scala compiler needs to run within the OSGi environment. However, since the Scala compiler cannot take a classloader as input, this does not work out of the box.

From my research, there appears to be two general solution approaches:

1) A scala compiler plugin (there is one started here but it has not been touched since 2009, and messages on the scala list in 2009 stated it was not ready for production use.

2) Creating a virtual file system on top of the bundle context which could then be used by the Scala compiler. Apparently the Apache sling guys have successfully used this approach on an older version of Scala.

Has anyone gotten Scalate, Scala 2.9.1, and OSGi to work together to dynamically compile templates?

Answer 1

My team now has Scala compilation and execution working for Scalate within OSGi.

In general, the ScalaCompiler settings should be provided with a set of AbstractFile objects that correspond to the relevant OSGi bundles. This is supported by Guggla as referenced by @michid. But while Guggla does provide the AbstractFile layer, it does not yet provide any examples or code for how to create the AbstractFile instances in an OSGi environment. Example code to do the latter can be found in the Sling project (the origin of Guggla itself) as well as in the Scalate project (see ScalaCompiler but note our changes to it below).

We chose the OSGi-ified scala bundles (compiler and library) from the ServiceMix project. See issue SMX-1048 (with patch) on the scala-compiler bundle.

Our original intent was to get this working in Scalate, and so the rest of this answer is specific to that project.

The Scalate code already had most of the logic necessary to work within an OSGi environment, including the virtual AbstractFile layer as well as setting the compiler classpath. However we needed to patch Scalate (https://github.com/scalate/scalate/pull/16) to get it working:

1) The OsgiCompiler override of the ScalaCompiler class was not being enabled properly, and so bundle's were not being detected as classpath inputs to the compiler, and

2) The template execution (run-time) classloader was being set to the classloader of the scalate-core bundle, resulting in CNFE's at runtime.

The pull request above configures Scalate in an OSGi environment to default to the thread-context classloader at runtime. That seems to be the easiest way to get a reference to the caller's classloader without the caller having to explicitly inject it (for example, a Spring-DM osgi:service declaration exporting a template service can use the context-class-loader="service-provider" attribute to set this automatically. This also makes the run-time behavior of Scalate OSGi correspond with the existing compile-time behavior which already used the TCCL.

Therefore a caller to Scalate should set the TCCL to it's own classloader or explicitly inject the desired classloader to the template engine e.g. templateEngine.classLoader = ... before executing the template.

Update 31-Aug-2012: Scalate master now contains all of the patches mentioned in this post.

Update 10-Apr-2013: Scalate 1.6.1, with runtime template compilation via the Scala compiler, is OSGi compatible. Also Scala 2.10 and above are valid OSGi bundles as released.

Answer 2

I think you need to set the buddy policy. The following should help.

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

In your bundle you can say you need to use the same class loader as another bundle.