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: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
