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 Leveraging OBR's generic dependency mechanism
Date Tue, 20 Feb 2007 20:46:24 GMT
Richard S. Hall wrote:

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

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?         


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



Mime
View raw message