incubator-clerezza-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Spicar <>
Subject Re: Update a bundle containing a WebRenderingService causes a refresh of almost all bundles
Date Wed, 02 May 2012 11:48:40 GMT
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.



On 18 January 2012 18:51, Daniel Spicar <> 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]

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message