Mailing-List: contact dev-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@felix.apache.org
Received-SPF: pass (athena.apache.org: domain of fmeschbe@gmail.com designates
 209.85.220.210 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:content-type:content-transfer-encoding;
        b=JrjEt9p41ewpPkKnlpXZPlgHUs4xo+qL7BdZSdJWxE1bvYMlLMNk3MVrfFVQqz0KK0
         8T74t7Jo73qkFhjk3T2FKQfhGIRg6EfsYlLnomUKdkVySaxKMAj8/ZKjrArKgZFClP3z
         FwsdnUmmTz3z3hOX7ThpeUbtysu+95eonGWDA=
Message-ID: <4BBC809D.3000803@gmail.com>
Date: Wed, 07 Apr 2010 14:54:53 +0200
From: Felix Meschberger <fmeschbe@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
 rv:1.9.1.8pre) Gecko/20100120 Shredder/3.0.2pre
MIME-Version: 1.0
To: dev@felix.apache.org
Subject: Re: [jira] Commented: (FELIX-2246) Lazy initialization of plugins
References: <927298449.41611270644093522.JavaMail.jira@brutus.apache.org>
In-Reply-To: <927298449.41611270644093522.JavaMail.jira@brutus.apache.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Hi,

On 07.04.2010 14:41, Valentin Valchev (JIRA) wrote:
> lazy wiring? If i have a bundle A exporting packages:
> a
> a.b
> 
> And Bundle B importing
> a.b
> 
> Will the framework try to resolve only a.b dependency or the whole bundle? (All package dependencies)

No, it will really only resolve a.b (if you do Import-Package).

The question of when resolution takes place is controlled by two
aspects: When the Bundle classloader is created and how the imports are
defined.

The Bundle classloader is created when the bundle is resolved. At this
time all imports defined by the Import-Package header are resolved.

Imports defined by the DynamicImport-Package header are only resolved on
demand when they are really needed - on-demand or lazily.

So, if you have a plugin, which defines the o.a.f.webconsole package as
a dynamic import you might not want to have this import resolved until
when the plugin is really instantiated.

By moving the SimpleWebConsoleFactory class in its own package we help
with two issues:

  * We can embed the class in the plugin bundle, without creating a
    split-package situation.
  * We can still lazily wire to the o.a.f.webconsole package on-demand
    when the actual plugin is really instantiated.

Does this answer the question ? Or did I misunderstand the question ?

Regards
Felix

> 
> 
> 
> 
>> Lazy initialization of plugins
>> ------------------------------
>>
>>                 Key: FELIX-2246
>>                 URL: https://issues.apache.org/jira/browse/FELIX-2246
>>             Project: Felix
>>          Issue Type: Improvement
>>          Components: Web Console
>>    Affects Versions: webconsole-3.0.0
>>            Reporter: Valentin Valchev
>>            Assignee: Felix Meschberger
>>         Attachments: FELIX-2246.patch, lazy-webconsole-plugins.jude, lazy-webconsole-plugins.png, lazyloading.patch, SimpleWebConsoleFactory.java, SimpleWebConsoleFactory.java
>>
>>
>> Here at ProSyst we use a small trick to delay initialization of our services:
>> When the service is quite big, and loads many resources (incl. too many classes), we register not a service, but a ServiceFactory instead. With that factory we delay the instantiation of the service, when it is actually needed and obtained by other bundle.
>> Yes, this makes the code a little bit more complex, but it greatly improves the start-up time and the overall memory usage.
>> This can be applied to webconsole plugins too. My idea is that Web Console should only track Service Reference without actually obtaining the service itself [not getService()].
>> When the user makes request the WebConsole calls the factory to create instance. Instance is created and returned to the Web Console, which uses it to generate content for the request.
>> This way a plugin is actually not initialized until it is really used. Only small portion of classes, from the bundle are initialized.
>> Unfortunately the ServiceTracker, when notified for added service obtains the real service object. So it might be better to use directly ServiceListener for the plugins.
>