felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Litton" <Rick.Lit...@ktd-kyocera.com>
Subject RE: Leveraging OBR's generic dependency mechanism
Date Wed, 21 Feb 2007 19:05:19 GMT
Richard S. Hall wrote:

> Rick Litton wrote:
>> This is a very interesting concept which I'm currently investigating.
>> had followed the discussions on OBR particularly this thread where
>> 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
>> lifecycle of some plugins (aka bundles) since they contain or control
>> resources (files) that have to be deployed in a certain order.
>> 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
>> 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
>> described above, I need to "intercept" OBR's execution after an
>> bundle is installed and resolved (but not started) and proceed with a
>> "management agent" that would call the bundle's start() method at
>> 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
> 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
> you want included in your bundle set, then define a "set bundle" in
> OBR repo that has requirements for each of the bundles to be
> 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.

Yes, I'm positive that this will work.  However, my problem at the
moment is that I have no desire to look into each bundle manifest file
that may contain anywhere from 5 to 20+ imported packages and try to map
them accordingly in order to create the "set bundle". ;(  On the other
hand, we already have a framework in place that ensures each bundle or
plugin is started correctly and in the right sequence.  So I could say
that the notion of a set bundle perhaps may not be necessary to
implement an automated upgrade process in our case.

I also noticed that OBR tries to start dependencies first before
starting the "target" bundle. So my guess is that OBR does some form of
"ordering" internally.  If this is true then may be I can use this
"ordering" capability for the "discover and deploy" sequence and then
rely on our own framework to execute the "start" sequence.  Yet I still
have the problem of automatically discovering changes to deal with. But
that's probably a different topic altogether.        

> 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
> it wants.

Exactly.  Modifying the ResolverImpl code may still be necessary so that
I can have a handle to the "start list" but disallow the actual call to
the bundle start method.  A more elegant solution (perhaps) is to use a
service listener that does the job as a handler but I'm not sure at the

> 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?

I think that would be extremely difficult at the moment (refer to my
response to Peter) which would perhaps require a top-to-bottom change in
how we have pursued the project.  One of our goals at the very beginning
was to enable teams to flourish independently.  Bundles provide the
building blocks and our in-house framework provides the infrastructure
that enables them to work together and that shapes them into a cohesive
product.  In my mind, this is one of the biggest advantages of plugin
development.  And thanks to OSGi, all is well. ;)      

> -> richard

I really appreciate your comments.

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
> 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
> 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
> be handled by the management agent in a similar fashion as you
> 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
>> it not having been implemented in Felix until recently?
> The "Set Bundle" is - conceptually - not the same as the
> thing. Require-Bundle to me is more like another way of expressing
> 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
> 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
> 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
> 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
> 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