incubator-clerezza-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reto Bachmann-Gmür ...@farewellutopia.com>
Subject Re: Update a bundle containing a WebRenderingService causes a refresh of almost all bundles
Date Tue, 22 May 2012 13:31:29 GMT
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 <dspicar@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 <dspicar@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
> >
>

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