felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <he...@ungoverned.org>
Subject Re: Start order when using WeavingHook
Date Tue, 30 Aug 2011 13:36:50 GMT
On 8/30/11 8:15 AM, Holger Hoffstätte wrote:
> On 30.08.2011 12:51, Ivanhoe Abrahams wrote:
>> I noticed that it really depends on the start order of the bundles whether
>> my simple class gets woven or not.
> This is because you haven't really declared any kind of logical dependency
> between the bundles; if your client bundle can work without weaver, the
> framework will happily start it - and why wouldn't it?
> Using a start order is a manual way to "fix" this, but due to its global
> nature (global meaning it only makes sense when considered across all
> bundles, which therefore must be known up front!) start order in general
> is fragile and not recommended.
>> I was wondering what the best way would be to ensure that my bundle
>> containing my weavinghook gets started first?
>> Is assigning a startlevel the only way that I can achieve this?
> I think going forward from 4.3+ we will increasingly see use of
> requirements&  capabilities matching, esp. when the new OBR spec is
> released and implemented ("real soon now" :). This will enable much more
> flexible modeling of dependencies between interacting entities than static
> ordering.

While I agree with you in spirit, generic caps/reqs won't really help 
when it comes to preventing one bundle from starting before another, 
since they address resolve-time dependencies, not activation-time 
dependencies. The weaver must be active before it can weave any classes. 
The difficulty here is that classes can be loaded before either bundle 
starts once both are resolved.

In the general sense, even start levels don't guarantee that a class is 
not loaded out of the bundle to be woven before the weaver weaves it 
(unless you know that no bundles in the lower levels will ever load a 
class out of the bundles to be woven). The only thing that you can do to 
guarantee this is have the weaver bundle check if the bundle is already 
resolved before the weaver is active and if so, refresh it.

Weaving hooks should be thought of as extensions to the framework and 
not as normal bundles in most cases. They should be deployed and 
activated at framework start so they are there before anything else. If 
you put weavers in start level one and know that there activating these 
bundles do not result in any class loads from bundles in higher start 
levels, then you should be ok.

-> richard

> -h
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org

To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org

View raw message