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 Tue, 22 May 2012 13:41:07 GMT
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