felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Meschberger <fmesc...@gmail.com>
Subject Re: [jira] Commented: (FELIX-2246) Lazy initialization of plugins
Date Wed, 07 Apr 2010 18:05:30 GMT

On 07.04.2010 15:55, Valentin Valchev wrote:
> On 07.4.2010 г. 15:54, Felix Meschberger wrote:
>> 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
> Well, I've never thought of the option that we can embed the class in a
> plugin bundle .... ;) I usually think how to reuse the stuff.

Yes, generally, reuse should be done using shared classes. But there are
some exceptions to this general rule, where reuse is better done by
embeding the class.

> IMHO The other option is better. It's nice and easy trick but it should
> be documented  - in the javadoc or the wiki pages. Sometimes developers
> are lazy or too overloaded and don't have enough time to think. But if
> it is written somewhere in noticeable place, this optimization will be
> applied almost all the time.

Yes, I completely agree.


> Regards,
> Valentin

View raw message