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 <dspi...@apache.org> 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 >
