You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@clerezza.apache.org by Daniel Spicar <ds...@apache.org> on 2012/05/02 13:48:40 UTC
Re: Update a bundle containing a WebRenderingService causes a refresh
of almost all bundles
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 <ds...@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
>
Re: Update a bundle containing a WebRenderingService causes a refresh
of almost all bundles
Posted by Reto Bachmann-Gmür <me...@farewellutopia.com>.
On Wed, May 23, 2012 at 10:44 AM, Daniel Spicar <ds...@apache.org> wrote:
> Hmm weird, I am seeing scala-scripting in SVN... am I misunderstanding you?
>
https://svn.apache.org/repos/asf/incubator/clerezza/issues/CLEREZZA-617/scala-scripting/is
missing the tests submodule referenced in the pom.
Cheers,
Reto
>
> > 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
> >
>
Re: Update a bundle containing a WebRenderingService causes a refresh
of almost all bundles
Posted by Daniel Spicar <ds...@apache.org>.
Hmm weird, I am seeing scala-scripting in SVN... am I misunderstanding you?
> 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
>
Re: Update a bundle containing a WebRenderingService causes a refresh
of almost all bundles
Posted by Daniel Spicar <da...@trialox.org>.
btw I added the tests submodule to the issue
Re: Update a bundle containing a WebRenderingService causes a refresh
of almost all bundles
Posted by Reto Bachmann-Gmür <re...@apache.org>.
Hi Daniel
I was trying to see how deep the impact of the change is. Chaning the ssp
package seems less problematic than chnages in scala-scripting.
Without yet having thought or looked at things thoroughly passing the
classloader of the bundle seems a good solutions. That the bundle imports
have to be added manually is a consequence of the ssp not beeing ssen by
the java compiler and the maven-bundle plugin. Alternative approaches
include manually scanning the bundles to make the classes available and
using a custom classloader rather than dynamic import (but this seems an
ugly attempt of circumventing OSGi) or to have ssp built during the
build-cycle (which is not to say they are not rebuilt when changed,).
Recently I've been working on fastening static files in source-bundles.
With what I'll commit soon changes in static files will be available at
once without needing the automatic rebuild of the bundle. Unfortunately I
couldn't think of an easy way to build things on a web-request as this
currently happens for ssp. (A not so easy way would be to generate proxies
for all classes which on each method call check the original source code
for changes before delegating to the actual implementation).
An unorthodox idea for ZZ-617 (not thought through yet): instead of
dynamically import directly in scala-scripting we could dynamically bind a
classloader-service which is provided by another bundle. This service could
temporarily disappear without any of the scala-scripting clients noticing.
If the service is temporarily unavailable the scripting engine should wait
a second too see if becomes available (again) and otherwise throw an
exception. Scala-Scripting would have no dependency on the bundle providing
the classloader (the service could be of type Classloader with some service
properties). The bundle providing the classloader has the good old
dynamic-import. Might this work?
Cheers,
Reto
On Wed, May 23, 2012 at 10:39 AM, Daniel Spicar <ds...@apache.org> wrote:
> Hi reto,
>
> thanks for taking the time and having a look at it and pointing out these
> things.
>
> It's a while ago since I worked on it and I didn't realize the code is not
> yet fully cleaned up yet. However I am mostly interested if there are any
> conceptual problems with the solution. As I tried to lay out, the code
> allows to register SSPs in a different way (specifically with a bundle
> classloader). However it also requires the user to declare not very obvious
> manual or dynamic OSGI package imports when building his project in order
> for this to work correctly. Therefore I fear the solution will be there for
> 'experts' that know about it only, although I tried to document it.
>
> So my questions are mainly:
> - Do we want to solve the problem in this way? (Do you have an idea about a
> better solution?)
> - Given we go for (conceptually) this solution, do you see how to improve
> the implementation?
>
> I'm also glad when you point out the small unfinished things in the code
> for when I revisit it.
>
> Daniel
>
> On 22 May 2012 15:41, Reto Bachmann-Gmür <re...@apache.org> wrote:
>
> > Something else:
> >
> > In script-enines we have
> >
> > <!-- TODO: this dependency is problematic-->
> > <dependency>
> > <groupId>org.apache.felix</groupId>
> > <artifactId>org.apache.felix.framework</artifactId>
> > <version>3.2.0</version>
> > </dependency>
> >
> > But this doesn't seem to be actually used, there is only a commented out
> > felix specific part in TrackingCompiler.
> >
> > Cheers,
> > Reto
> >
> > On Tue, May 22, 2012 at 3:31 PM, Reto Bachmann-Gmür
> > <me...@farewellutopia.com>wrote:
> >
> > > 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 <ds...@apache.org>
> > 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 <ds...@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
> > >> >
> > >>
> > >
> > >
> >
>
Re: Update a bundle containing a WebRenderingService causes a refresh
of almost all bundles
Posted by Daniel Spicar <ds...@apache.org>.
Hi reto,
thanks for taking the time and having a look at it and pointing out these
things.
It's a while ago since I worked on it and I didn't realize the code is not
yet fully cleaned up yet. However I am mostly interested if there are any
conceptual problems with the solution. As I tried to lay out, the code
allows to register SSPs in a different way (specifically with a bundle
classloader). However it also requires the user to declare not very obvious
manual or dynamic OSGI package imports when building his project in order
for this to work correctly. Therefore I fear the solution will be there for
'experts' that know about it only, although I tried to document it.
So my questions are mainly:
- Do we want to solve the problem in this way? (Do you have an idea about a
better solution?)
- Given we go for (conceptually) this solution, do you see how to improve
the implementation?
I'm also glad when you point out the small unfinished things in the code
for when I revisit it.
Daniel
On 22 May 2012 15:41, Reto Bachmann-Gmür <re...@apache.org> wrote:
> Something else:
>
> In script-enines we have
>
> <!-- TODO: this dependency is problematic-->
> <dependency>
> <groupId>org.apache.felix</groupId>
> <artifactId>org.apache.felix.framework</artifactId>
> <version>3.2.0</version>
> </dependency>
>
> But this doesn't seem to be actually used, there is only a commented out
> felix specific part in TrackingCompiler.
>
> Cheers,
> Reto
>
> On Tue, May 22, 2012 at 3:31 PM, Reto Bachmann-Gmür
> <me...@farewellutopia.com>wrote:
>
> > 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 <ds...@apache.org>
> 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 <ds...@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
> >> >
> >>
> >
> >
>
Re: Update a bundle containing a WebRenderingService causes a refresh
of almost all bundles
Posted by Reto Bachmann-Gmür <re...@apache.org>.
Something else:
In script-enines we have
<!-- TODO: this dependency is problematic-->
<dependency>
<groupId>org.apache.felix</groupId>
<artifactId>org.apache.felix.framework</artifactId>
<version>3.2.0</version>
</dependency>
But this doesn't seem to be actually used, there is only a commented out
felix specific part in TrackingCompiler.
Cheers,
Reto
On Tue, May 22, 2012 at 3:31 PM, Reto Bachmann-Gmür
<me...@farewellutopia.com>wrote:
> 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 <ds...@apache.org> 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 <ds...@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
>> >
>>
>
>
Re: Update a bundle containing a WebRenderingService causes a refresh
of almost all bundles
Posted by Reto Bachmann-Gmür <me...@farewellutopia.com>.
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 <ds...@apache.org> 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 <ds...@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
> >
>