让scala编译器在OSGi运行时内工作

Question

我正在使用Scala模板引擎(Scalate)在OSGi环境中运行时编译模板(Scala 2.9.1).模板无法预编译,因为它们是动态构建的.

为了使其工作,Scala编译器需要在OSGi环境中运行.但是,由于Scala编译器无法将类加载器作为输入,因此这不是开箱即用的.

根据我的研究,似乎有两种通用的解决方案:

1)一个scala编译器插件(有一个从这里开始,但自2009年以来没有被触及,2009年scala列表上的消息表明它还没有准备好用于生产.

2)在bundle上下文之上创建一个虚拟文件系统,然后由Scala编译器使用.显然,Apache sling家伙已经在旧版本的Scala上成功使用了这种方法.

有没有人让Scalate,Scala 2.9.1和OSGi一起动态编译模板？

Answer 1

我的团队现在已经在 OSGi 中为 Scalate 进行了 Scala 编译和执行。

一般来说，ScalaCompiler 设置应该提供一组与相关 OSGi 包相对应的 AbstractFile 对象。正如 @michid 所引用的，Guggla支持这一点。但是，虽然 Guggla 确实提供了 AbstractFile 层，但它尚未提供任何有关如何在 OSGi 环境中创建 AbstractFile 实例的示例或代码。执行后者的示例代码可以在 Sling 项目（Guggla 本身的起源）以及Scalate项目中找到（请参阅ScalaCompiler，但请注意下面我们对其进行的更改）。

我们从 ServiceMix 项目中选择了 OSGi 化的 scala 包（编译器和库）。请参阅scala-compiler 包上的问题 SMX-1048（带补丁） 。

我们最初的目的是让它在 Scalate 中工作，所以这个答案的其余部分是特定于该项目的。

Scalate 代码已经拥有在 OSGi 环境中工作所需的大部分逻辑，包括虚拟 AbstractFile 层以及设置编译器类路径。然而，我们需要修补 Scalate ( https://github.com/scalate/scalate/pull/16 ) 才能使其正常工作：

1) ScalaCompiler 类的 OsgiCompiler 重写未正确启用，因此未将包检测为编译器的类路径输入，并且

2) 模板执行（运行时）类加载器被设置为 scalate-core 包的类加载器，导致运行时出现 CNFE。

上面的拉取请求将 OSGi 环境中的 Scalate 配置为运行时默认的线程上下文类加载器。这似乎是获取调用者类加载器引用的最简单方法，而调用者不必显式注入它（例如，osgi:service导出模板服务的 Spring-DM 声明可以使用context-class-loader="service-provider"该属性自动设置它。这也使得运行Scalate OSGi 的时行为与已使用 TCCL 的现有编译时行为相对应。

templateEngine.classLoader = ...因此，Scalate 的调用者应该将 TCCL 设置为其自己的类加载器，或者在执行模板之前将所需的类加载器显式注入模板引擎。

2012 年 8 月 31 日更新：Scalate master 现在包含本文中提到的所有补丁。

2013 年 4 月 10 日更新：Scalate 1.6.1 通过 Scala 编译器进行运行时模板编译，与 OSGi 兼容。Scala 2.10 及更高版本也是已发布的有效 OSGi 捆绑包。