On 03/12/2012 12:52 PM, Guillaume Yziquel wrote: > Le Monday 12 Mar 2012 à 09:14:50 (-0400), Raman Gupta a écrit : >> On 03/12/2012 08:48 AM, Guillaume Yziquel wrote: >> >> My team has gotten Scalate 1.6.0-SNAPSHOT working on Scala 2.9.1 on >> Karaf. See this stackoverflow posting for details and links to the >> Scalate patches we created (though our Github pull requests have >> essentially been ignored by the Scalate team): >> >> http://stackoverflow.com/questions/8935796/getting-the-scala-compiler-to-work-inside-an-osgi-runtime/9048302#9048302 > > Yes. Your post has been very useful in the past to get into the topic of > osgified Scala compiler bundles. > > I currently prefer creating OSGi bundles on the fly rather than purely > compiling Scala code into ad-hoc instances. The main reason is that when > I generate bundles, I do know where they fit in the OSGi hierarchy. If I > generate instances via Guggla or the Scalate scripting engine, I wonder > where these instances fit in the OSGi hierarchy, and specifically I do > not know how safe it is to access other bundles from the compiled code. > > You perhaps have valuable insight on this topic. Please feel free to > share it.
Yes, I think the approach of generating bundles makes a lot of sense for running dynamically compiled code via a tool like Slang. The only insight I can provide is the approach we took to avoid needing an OSGi dynamic import for the generated code. Since our requirements are related to templates only, we didn't generate new OSGi bundles for every template, but we still wanted to be able to run services provided by other bundles without knowing upfront what those services would be. To solve this, other bundles expose an OSGi service implementing a "TemplateCollaborator" interface with a generic "invoke" method (another method on the interface is a String uniquely identifying the underlying function to allow the template to call the correct collaborator). In our Scalate patch, we configured Scalate to use the TCCL when in an OSGi environment, and so we set the TCCL to the bundle that loads the templates so that classloading is relative to that bundle and not the Scalate bundle. The end result is that the dynamically compiled templates have access to any TemplateCollaborator without needing to dynamically import the underlying classes (and so collaborators and templates can be added/changed at runtime without changing the template bundle code). -- Raman Principal VIVO Systems
