felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <he...@ungoverned.org>
Subject Re: Leveraging OBR's generic dependency mechanism
Date Wed, 21 Feb 2007 07:17:16 GMT
Rick Litton wrote:
> This is a very interesting concept which I'm currently investigating.  I
> had followed the discussions on OBR particularly this thread where Felix
> Meschberger mentioned about the notion of a "set bundle".  You see we
> have a similar requirement but my interest focuses on the process for
> updating a set of installed bundles.  In our case, we need to manage the
> lifecycle of some plugins (aka bundles) since they contain or control
> resources (files) that have to be deployed in a certain order.  Looking
> at the code, the Resolver's deploy() method finds all the updatable
> local resources (installed bundles), using the LocalRepositoryImpl to
> populate a "start list". You also said somewhere later that it would not
> be difficult to map the actual resource (jar file) to the bundle which I
> tend to agree.   
> Now assuming as you suggested that OBR can determine or discover the
> "set bundle" or start list plus its dependencies through the mechanism
> described above, I need to "intercept" OBR's execution after an update
> bundle is installed and resolved (but not started) and proceed with a
> "management agent" that would call the bundle's start() method at some
> point.  What would be your recommendation for going about this task?
> How do I make use of the "capability/requirement relationship" if in
> fact OBR produces the "start list" automatically?

Custom capabilities/requirements are only needed if the set of bundles 
you want to install do not exhibit any of the normal OSGi dependencies 
on each other (e.g., import-package, require-bundle, fragments). In the 
case where they do not have these normal dependencies, you can easily 
define a dependency that ties them together in some way.

You can create an arbitrary capability, then add it to the bundles that 
you want included in your bundle set, then define a "set bundle" in the 
OBR repo that has requirements for each of the bundles to be installed. 
Thus, when you deploy the "set bundle" via OBR, it will automatically 
pull in all of the bundles it requires via the custom 
capability/requirement. It will, of course, also pull in any other 
bundles referenced through standard OSGi dependencies.

As for how to intercept. Well, if we assume that we modify OBR to 
somehow provide access to the mapping of installed bundles from a 
deploy() operation, then the simple solution is to call deploy() with 
the start flag set to false. Thus, your management agent tells OBR to 
deploy (but not start) the "set bundle", which will return to the 
management agent a mapping of the installed bundles. Your management 
agent is then free to start the bundles in the returned set in any order 
it wants.

However, I agree with Peter, try to eliminate the order issues...it is 
not that difficult to make your initialization wait for the necessary 
conditions, is it?

-> richard

> Rick Litton
> -----Original Message-----
> From: Richard S. Hall [mailto:heavy@ungoverned.org] 
> Sent: Tuesday, February 13, 2007 3:48 AM
> To: felix-dev@incubator.apache.org
> Subject: Re: OBR Resolver.deploy() and framework start level
> Felix,
> Couldn't you still express the bundle list of a Set Bundle as some sort
> capability/requirement relationship of the Set Bundle that OBR could
> automatically resolve? The rest of the processing could be the same by
> the management agent, but you would leverage OBR's generic dependency
> mechanism to describe your bundle list.
> Or is there some reason you need to be able (or want) to install the Set
> Bundle independently of its bundle list?
> The only thing that doesn't seem to cleanly fit is the ability for the
> Set Bundle to contain other bundles, but this case could still probably
> be handled by the management agent in a similar fashion as you currently
> do, I imagine.
> -> richard
> -----Original Message-----
> From:  "Felix Meschberger" <Felix.Meschberger@day.com>
> Subj:  Re: OBR Resolver.deploy() and framework start level
> Date:  Tue 13. Feb 2007 2:36
> Size:  2K
> To:  felix-dev@incubator.apache.org
> On 2/12/07, Steven E. Harris <seh@panix.com> wrote:
>> Felix Meschberger <Felix.Meschberger@day.com> 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?
> The "Set Bundle" is - conceptually - not the same as the Require-Bundle
> thing. Require-Bundle to me is more like another way of expressing real
> code
> dependency (which IMHO is better done through Import-Package...). The
> bundle
> list of a "Set Bundle" is more like installation instructions targeted
> at a
> management agent (bundle).
> Unlike Require-Bundle not only the symbolic names and versions of the
> bundle
> to install but also the start level and whether the installed bundles
> are to
> be started/stopped when the "Set Bundle" is started/stopped may be
> specified
> and whether the bundles to install are contained as entries in the "Set
> Bundle" itself is declared in the "Set Bundle". This goes beyond the
> functionality of Require-Bundle.
> Does the "set bundle" start all its related bundles when it itself is
>> told to start, and stop all the others when it stops?
> Yes, and  the bundles contained in the "Set Bundle" are uninstalled when
> the
> "Set Bundle" is uninstalled. This, however, may be controlled with a
> flag in
> the "Set Bundle" to prevent this "locking into the Set Bundle
> lifecycle".
> 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?
> Yes, as the "Set Bundle" is a normal bundle. And yes, the depdencies are
> not
> known to OBR, as these are not declared in the "Set Bundle". Instead,
> the
> management agent recognizes the installation of the "Set Bundle" and
> handles
> the next steps accordingly, including getting the bundles referred to by
> the
> "Set Bundle" and their dependencies from the OBR. It is more like a
> two-step
> process.
> BTW: We call these "Set Bundles" "Assembly Bundles" or "Assembly" for
> short
> - lacking a better name :-) [ On the other hand "Bundle Set" does not
> sound
> too bad ]
> Regards
> Felix

View raw message