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
