Hi Daniel I've noticed the nranch is not compiling because of missing submiodule of scala-scripting. Should I copy the missing folder over from trunk?
Cheers, Reto On Wed, May 2, 2012 at 1:48 PM, Daniel Spicar <[email protected]> wrote: > Hi clerezza-devs, > > I would like to ask for a review of the code for this issue. It is located > in issues/CLEREZZA-617. It is not very easy to understand this problem. I > think there is a good log of what has been going on in the JIRA issue > comments [1]. When you install the code from the issue there will also be > additional platform documentation available that explains the new options. > > Thanks, > Daniel > > [1] https://issues.apache.org/jira/browse/CLEREZZA-617 > > On 18 January 2012 18:51, Daniel Spicar <[email protected]> wrote: > > > I committed some code to issue/CLEREZZA-617 that can solve this issue. > > However the solution is not ideal. > > > > A recap: The problem is generally speaking, that currently, we get > > dependencies from the scripting-engine bundle on other bundles that are > > imported in SSP templates. That happens especially when using > > WebRenderingService (a way to create OSGi services that can be bound and > > used in SSPs). The dependency that is created causes script-engine to > > restart when the webrendering service is changed. This in turn causes all > > other bundles that depend on script-engine to restart as well, even > though > > most of these restarts are unnecessary. One symptom of this happening is, > > that the scala console restarts and is broken afterwards. But also it can > > cause significant downtime in production systems with many registered > SSPs. > > > > The solution so far: > > > > 1. I created a new method on ScalaServerPagesService to register SSPs > > with. The new method takes a classloader as an argument. The idea is > that a > > bundle registering its SSP also supplies its classloader which will then > be > > used to load the compiled SSP and thus only creating dependencies from > the > > registering bundle on whatever its SSP imports. > > > >> > > 2. in order for a bundle that registers an SSP with its own classloader > to > > be able to resolve other packages in the OSGi environment, it needs to be > > compiled with dynamic imports enabled or its runtime package dependencies > > declared manually. The easiest way is to declare dynamic imports, e.g a > > maven bundle plugin instruction to do so is: > > ... > > <build> > > <plugins> > > <plugin> > > <groupId>org.apache.felix</groupId> > > <artifactId>maven-bundle-plugin</artifactId> > > <configuration> > > <instructions> > > <DynamicImport-Package>*</DynamicImport-Package> > > </instructions> > > </configuration> > > </plugin> > > </plugins> > > > > The issues with this solution: > > > > about 1: The class loader can theoretically be detected automatically. > But > > the only approach I found is a platform dependent hack, see [1]. The > > current solution avoids this dependency. > > The current solution does not mess with backwards compatibility but in > > order to make use of the new interface quite some background knowledge is > > needed (It's not easy to know what the use of it is). > > > > about 2: I asked on the felix mailing list if there is a programmatic > > solution. It seems there is none (sorry can't give you a link to the > > mailing listarchive because of the blackout day). This dynamic import > > declaration is the responsibility of somebody registering an SSP. But is > it > > not necessarily obvious to a user that he needs to do that. Of course > > documentation can help. But the core issue is hard enough to understand. > > > > In summary: the issue can be avoided but it requires the user to be aware > > of the problem. An automatic solution does not seem to be possible with > the > > approach I took. However we have people that want a solution and this is > > one. Given that I improve documentation about this issue I wonder if the > > the solution is acceptable to be committed with the described > limitations. > > Alternatively I would be open to other approaches. > > > > > > [1] > > > http://download.eclipse.org/jetty/stable-7/xref/org/eclipse/jetty/osgi/boot/utils/internal/DefaultBundleClassLoaderHelper.html > > >
