incubator-clerezza-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reto Bachmann-Gmür <r...@apache.org>
Subject Re: Update a bundle containing a WebRenderingService causes a refresh of almost all bundles
Date Wed, 23 May 2012 09:23:39 GMT
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 <dspicar@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 <reto@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 <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