The key issues seems that the bundles must be installed in a certain
order. In dynamic systems like an OSGi platform that is an invariant
that is extremely hard to control. So hard that imho one should not
try to design mechanisms that guarantee these orderings. This is the
same issue for initialization. I remember in the old days when we
tried to order the initialization routines. In the end, lazy
initialization is the most robust.
Is it not possible to change the problem so that ordering is not an
issue?
Then I again, I am very interested in uses of OBR.
Kind regards,
Peter Kriens
RL> Richard S. Hall wrote:
>> Couldn't you still express the bundle list of a Set Bundle as some
RL> sort
>> capability/requirement relationship of the Set Bundle that OBR could
>> automatically resolve? The rest of the processing could be the same by
RL> the
>> management agent, but you would leverage OBR's generic dependency
>> mechanism to describe your bundle list.
RL> This is a very interesting concept which I'm currently investigating. I
RL> had followed the discussions on OBR particularly this thread where Felix
RL> Meschberger mentioned about the notion of a "set bundle". You see we
RL> have a similar requirement but my interest focuses on the process for
RL> updating a set of installed bundles. In our case, we need to manage the
RL> lifecycle of some plugins (aka bundles) since they contain or control
RL> resources (files) that have to be deployed in a certain order. Looking
RL> at the code, the Resolver's deploy() method finds all the updatable
RL> local resources (installed bundles), using the LocalRepositoryImpl to
RL> populate a "start list". You also said somewhere later that it would not
RL> be difficult to map the actual resource (jar file) to the bundle which I
RL> tend to agree.
RL> Now assuming as you suggested that OBR can determine or discover the
RL> "set bundle" or start list plus its dependencies through the mechanism
RL> described above, I need to "intercept" OBR's execution after an update
RL> bundle is installed and resolved (but not started) and proceed with a
RL> "management agent" that would call the bundle's start() method at some
RL> point. What would be your recommendation for going about this task?
RL> How do I make use of the "capability/requirement relationship" if in
RL> fact OBR produces the "start list" automatically?
RL> Rick Litton
RL> -----Original Message-----
RL> From: Richard S. Hall [mailto:[EMAIL PROTECTED]
RL> Sent: Tuesday, February 13, 2007 3:48 AM
RL> To: felix-dev@incubator.apache.org
RL> Subject: Re: OBR Resolver.deploy() and framework start level
RL> Felix,
RL> Couldn't you still express the bundle list of a Set Bundle as some sort
RL> capability/requirement relationship of the Set Bundle that OBR could
RL> automatically resolve? The rest of the processing could be the same by
RL> the management agent, but you would leverage OBR's generic dependency
RL> mechanism to describe your bundle list.
RL> Or is there some reason you need to be able (or want) to install the Set
RL> Bundle independently of its bundle list?
RL> The only thing that doesn't seem to cleanly fit is the ability for the
RL> Set Bundle to contain other bundles, but this case could still probably
RL> be handled by the management agent in a similar fashion as you currently
RL> do, I imagine.
->> richard
RL> -----Original Message-----
RL> From: "Felix Meschberger" <[EMAIL PROTECTED]>
RL> Subj: Re: OBR Resolver.deploy() and framework start level
RL> Date: Tue 13. Feb 2007 2:36
RL> Size: 2K
RL> To: felix-dev@incubator.apache.org
RL> On 2/12/07, Steven E. Harris <[EMAIL PROTECTED]> wrote:
>>
>> Felix Meschberger <[EMAIL PROTECTED]> writes:
>>
>> > Actually, the bundle set descriptor is a bundle itself, which has a
>> > special manifest header naming other bundles (or resources in OBR
>> > speak) to be managed. The reference is by bundle symbolic name and a
>> > version range.
>>
>> This is interesting. The "set bundle" refers to the other bundles not
>> in the abstract (by exported packages), but as concrete references to
>> symbolic name and version. It sounds kind of like the Require-Bundle
>> header. Is there a reason why you don't use Require-Bundle, other than
>> it not having been implemented in Felix until recently?
RL> The "Set Bundle" is - conceptually - not the same as the Require-Bundle
RL> thing. Require-Bundle to me is more like another way of expressing real
RL> code
RL> dependency (which IMHO is better done through Import-Package...). The
RL> bundle
RL> list of a "Set Bundle" is more like installation instructions targeted
RL> at a
RL> management agent (bundle).
RL> Unlike Require-Bundle not only the symbolic names and versions of the
RL> bundle
RL> to install but also the start level and whether the installed bundles
RL> are to
RL> be started/stopped when the "Set Bundle" is started/stopped may be
RL> specified
RL> and whether the bundles to install are contained as entries in the "Set
RL> Bundle" itself is declared in the "Set Bundle". This goes beyond the
RL> functionality of Require-Bundle.
RL> Does the "set bundle" start all its related bundles when it itself is
>> told to start, and stop all the others when it stops?
RL> Yes, and the bundles contained in the "Set Bundle" are uninstalled when
RL> the
RL> "Set Bundle" is uninstalled. This, however, may be controlled with a
RL> flag in
RL> the "Set Bundle" to prevent this "locking into the Set Bundle
RL> lifecycle".
RL> Do you deploy this "set bundle" through OBR? If so, it sounds like the
>> "set bundle's" bundle associations aren't known to OSGi (being
>> specified by this special header you mention above), so how do the
>> associated bundles get discovered through OBR? Or does the "set
>> bundle" itself use OBR to deploy all its associated bundles?
RL> Yes, as the "Set Bundle" is a normal bundle. And yes, the depdencies are
RL> not
RL> known to OBR, as these are not declared in the "Set Bundle". Instead,
RL> the
RL> management agent recognizes the installation of the "Set Bundle" and
RL> handles
RL> the next steps accordingly, including getting the bundles referred to by
RL> the
RL> "Set Bundle" and their dependencies from the OBR. It is more like a
RL> two-step
RL> process.
RL> BTW: We call these "Set Bundles" "Assembly Bundles" or "Assembly" for
RL> short
RL> - lacking a better name :-) [ On the other hand "Bundle Set" does not
RL> sound
RL> too bad ]
RL> Regards
RL> Felix
--
Peter Kriens Tel +33467542167
9C, Avenue St. Drézéry AOL,Yahoo: pkriens
34160 Beaulieu, France ICQ 255570717
Skype pkriens Fax +1 8153772599
