You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Rick Litton <Ri...@ktd-kyocera.com> on 2007/02/20 21:46:24 UTC
Leveraging OBR's generic dependency mechanism
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" <Fe...@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 <se...@panix.com> wrote:
>
> Felix Meschberger <Fe...@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
RE: Leveraging OBR's generic dependency mechanism
Posted by Rick Litton <Ri...@ktd-kyocera.com>.
Peter Kriens wrote:
> The key issues seems that the bundles must be installed in a certain
> order. ...
> Is it not possible to change the problem so that ordering is not an
> issue?
Our project is participated in by several teams located in various development centers and it has evolved to such an extent that it would not be practical to change the problem space at the moment. We actually had adapted to the use of a "plugin.xml" with a "requires" tag to control dependencies as well as the use of such things as a plugin manager that processes an xml file containing initialization info. All these work quite well at the moment but you really can't depend on the use of these capabilities for an effective and easy-to-maintain upgrade process that pulls in all the necessary changes with as little work as possible (at least at my end - ;)). So I'm aiming at creating a more automated process possibly with OBR.
Rick Litton
-----Original Message-----
From: Peter Kriens [mailto:Peter.Kriens@aQute.biz]
Sent: Tuesday, February 20, 2007 11:01 PM
To: Rick Litton
Cc: felix-dev@incubator.apache.org
Subject: Re: Leveraging OBR's generic dependency mechanism
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:heavy@ungoverned.org]
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" <Fe...@day.com>
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 <se...@panix.com> wrote:
>>
>> Felix Meschberger <Fe...@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?
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
Re: Leveraging OBR's generic dependency mechanism
Posted by Peter Kriens <Pe...@aQute.biz>.
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:heavy@ungoverned.org]
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" <Fe...@day.com>
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 <se...@panix.com> wrote:
>>
>> Felix Meschberger <Fe...@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?
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
RE: Leveraging OBR's generic dependency mechanism
Posted by Rick Litton <Ri...@ktd-kyocera.com>.
That's cool, Richard. I'm at the EclipseCon conference and will definitely start on this right away after discussing a few things with Felix and whoever else is interested in contributing. Regards,
Rick
-----Original Message-----
From: Richard S. Hall [mailto:heavy@ungoverned.org]
Sent: Mon 3/5/2007 7:33 AM
To: felix-dev@incubator.apache.org
Subject: Re: Leveraging OBR's generic dependency mechanism
Rick Litton wrote:
> Hi all,
>
> Just to add to my response below, I was actually thinking along the
> lines of implementing JSR 124 (J2EE Client Provisioning) based on
> OBR. I know that provisioning is becoming a hot topic particularly
> within the Eclipse community where there are discussions on enhancing
> the Upgrade Manager feature. I'm not sure if there is interest among
> the Felix community though...
I am definitely interested in improving this area for Felix...adding
this type of support in another layer on top of OBR sounds like a good
idea to me.
-> richard
>
> Thanks!
>
> Rick Litton
>
> ----- Original Message ----- From: "Rick Litton" <rl...@sbcglobal.net>
> To: <fe...@incubator.apache.org>
> Sent: Saturday, March 03, 2007 3:04 AM
> Subject: Re: Leveraging OBR's generic dependency mechanism
>
>
>> Hi Felix,
>>
>> I certainly would like to contribute (not take over) to this feature
>> if that's ok. Perhaps we can define some more use cases so that
>> Assembly could accommodate other requirements. What do you think?
>>
>> Rick
>>
>> ----- Original Message ----- From: "Felix Meschberger"
>> <Fe...@day.com>
>> To: <fe...@incubator.apache.org>
>> Sent: Saturday, March 03, 2007 1:39 AM
>> Subject: Re: Leveraging OBR's generic dependency mechanism
>>
>>
>>> Hi Rick,
>>>
>>> Ok, thanks for the information.
>>>
>>> BTW: As noted earlier I attached the Assembly support stuff to JIRA
>>> http://issues.apache.org/jira/browse/FELIX-217. Is there any
>>> interest to
>>> take this over as a contribution to the Felix project ? Otherwise, I
>>> would
>>> close the issue again. Thanks for any feedback.
>>>
>>> Regards
>>> Felix
>>>
>>> On 3/2/07, Rick Litton <Ri...@ktd-kyocera.com> wrote:
>>>>
>>>> Felix Meschberger wrote:
>>>>
>>>> > Just being curious, what exactly did you patch in InstallerImpl (and
>>>> > ResolverImpl) ?
>>>>
>>>> Hi Felix,
>>>>
>>>> Actually, I created a class called LocalResolverImpl which extends
>>>> from
>>>> ResolverImpl. It was meant to deal with the categorization of bundles
>>>> into "updatable bundles" and "installable bundles" and to search for a
>>>> "capable resource" by matching capabilities and requirements. This
>>>> created the potential for intercepting the update process at a certain
>>>> point sometime later. The InstallerImpl was actually built from the
>>>> ground up although it pretty much also does the install operation.
>>>> Similar to your class, it delegates the actual work of deploying the
>>>> updated or new bundle to the resolver and manages the startlevel of
>>>> these bundles.
>>>>
>>>> Regards.
>>>>
>>>> Rick Litton
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: fmeschbe@gmail.com [mailto:fmeschbe@gmail.com] On Behalf Of
>>>> Felix
>>>> Meschberger
>>>> Sent: Friday, March 02, 2007 12:52 AM
>>>> To: felix-dev@incubator.apache.org
>>>> Subject: Re: Leveraging OBR's generic dependency mechanism
>>>>
>>>> Hi Rick,
>>>>
>>>> Thanks for the update.
>>>>
>>>> Just being curious, what exactly did you patch in InstallerImpl (and
>>>> ResolverImpl) ?
>>>>
>>>> Regards
>>>> Felix
>>>>
>>>> On 3/2/07, rl16783@sbcglobal.net <rl...@sbcglobal.net> wrote:
>>>> >
>>>> > FW: Leveraging OBR's generic dependency mechanismHi Felix,
>>>> >
>>>> > Felix Meschberger wrote on 2/22/2007:
>>>> >
>>>> > >Hi,
>>>> >
>>>> > >> Apparently, there is only a single queueHandler
>>>> > >> thread which handles the events. I must be missing something.
>>>> >
>>>> > > The thread is started at the end of the AssemblyManager.start
>>>> method,
>>>> > > which
>>>> > > first gathers existing bundles to jump start the Assembly Manager
>>>> with
>>>> > > simulated events for them. The AssemblyManager.start method itself
>>>> is
>>>> > > called
>>>> > > from AssemblyActivator (the BundleActivator) start method...
>>>> >
>>>> > >> My question is how does the installer handle direct and
>>>> > >> indirect dependencies if those dependencies are also required
>>>> to be
>>>> > >> updated?
>>>> >
>>>> > > Ok. This depends. If the dependencies are included with the
>>>> assembly,
>>>> > > there
>>>> > > lifecycle is controlled through the Assembly Bundle. If the
>>>> dependencies
>>>> > > are
>>>> > > not included in the assembly, and an OBR is used to install the
>>>> bundles,
>>>> > > the
>>>> > > dependencies will be resolved by the OBR and just started by the
>>>> > > AssemblyManager (these are the requiredResources of the Resolver).
>>>> They
>>>> > > are
>>>> > > not further managed by the AssemblyManager, they are just there.
>>>> >
>>>> > > If the dependencies not managed by the AssemblyManage happen to
>>>> require
>>>> > an
>>>> > > update due to updated requirements of managed bundles, these
>>>> updates
>>>> may
>>>> > > take place as a "side effect" of OBR bundle resolution.
>>>> >
>>>> > > So for complete management, it might be a good idea to include all
>>>> > > dependencies as far as possible in the Assembly. Again: This is a
>>>> > > management
>>>> > > task based on a management decision outside of the framework
>>>> and not
>>>> a
>>>> > > technically required task !
>>>> >
>>>> > > Regards
>>>> > > Felix
>>>> >
>>>> > I should have responded much earlier, but instead I would just
>>>> like to
>>>> > provide you with a quick update. Apparently, our automated update
>>>> process
>>>> > using OBR seems to be working. Thanks to your examples and by
>>>> following
>>>> > Richard's original suggestion consisting of 4 steps, I was able to
>>>> build
>>>> > a
>>>> > customized version of InstallerImpl and ResolverImpl. The whole
>>>> process
>>>> > is
>>>> > triggered when a local repository is detected. The approach I have
>>>> taken
>>>> > was to identify updatable bundles (those that have an older version)
>>>> from
>>>> > the installable bundles (those that are entirely new) up front. By
>>>> > matching
>>>> > capabilities and requirements, I was then able to build a list of
>>>> > resources
>>>> > that could be installed, lining them up in a stack, to ensure
>>>> that the
>>>> > required dependencies pulled in were installed first. So far the
>>>> update
>>>> > seems to work provided that there were no cyclical dependencies
>>>> which
>>>> in
>>>> > our
>>>> > case, we took the effort to avoid. Of course, this doesn't sound so
>>>> ideal
>>>> > but it's currently the situation which I know will improve over time
>>>> as
>>>> > the
>>>> > benefits of a service architecture are fully realized.
>>>> >
>>>> > One issue I encountered was with the LocalRepositoryImpl. I may
>>>> have
>>>> it
>>>> > wrong but apparently its m_local variable points to the .felix cache
>>>> > instead
>>>> > of the actual "physical" repository. To resolve this issue, I
>>>> had to
>>>> > create
>>>> > a "map" of the repository so that resources can be discovered and
>>>> > eventually
>>>> > the actual bundles are installed. I also found that the getURL
>>>> method
>>>> of
>>>> > the resource returns null but that was overcome with this
>>>> workaround.
>>>> > Although some more work remains to be completed, overall the
>>>> direction
>>>> > looks
>>>> > okay.
>>>> >
>>>> > And to those who will be at EclipseCon next week, I hope to meet up
>>>> with
>>>> > you
>>>> > at the conference!
>>>> >
>>>> > Best regards.
>>>> > Rick
>>>> >
>>>> >
>>>> >
>>>>
>>>
>>
>>
>>
>
>
Re: Leveraging OBR's generic dependency mechanism
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Rick Litton wrote:
> Hi all,
>
> Just to add to my response below, I was actually thinking along the
> lines of implementing JSR 124 (J2EE Client Provisioning) based on
> OBR. I know that provisioning is becoming a hot topic particularly
> within the Eclipse community where there are discussions on enhancing
> the Upgrade Manager feature. I'm not sure if there is interest among
> the Felix community though...
I am definitely interested in improving this area for Felix...adding
this type of support in another layer on top of OBR sounds like a good
idea to me.
-> richard
>
> Thanks!
>
> Rick Litton
>
> ----- Original Message ----- From: "Rick Litton" <rl...@sbcglobal.net>
> To: <fe...@incubator.apache.org>
> Sent: Saturday, March 03, 2007 3:04 AM
> Subject: Re: Leveraging OBR's generic dependency mechanism
>
>
>> Hi Felix,
>>
>> I certainly would like to contribute (not take over) to this feature
>> if that's ok. Perhaps we can define some more use cases so that
>> Assembly could accommodate other requirements. What do you think?
>>
>> Rick
>>
>> ----- Original Message ----- From: "Felix Meschberger"
>> <Fe...@day.com>
>> To: <fe...@incubator.apache.org>
>> Sent: Saturday, March 03, 2007 1:39 AM
>> Subject: Re: Leveraging OBR's generic dependency mechanism
>>
>>
>>> Hi Rick,
>>>
>>> Ok, thanks for the information.
>>>
>>> BTW: As noted earlier I attached the Assembly support stuff to JIRA
>>> http://issues.apache.org/jira/browse/FELIX-217. Is there any
>>> interest to
>>> take this over as a contribution to the Felix project ? Otherwise, I
>>> would
>>> close the issue again. Thanks for any feedback.
>>>
>>> Regards
>>> Felix
>>>
>>> On 3/2/07, Rick Litton <Ri...@ktd-kyocera.com> wrote:
>>>>
>>>> Felix Meschberger wrote:
>>>>
>>>> > Just being curious, what exactly did you patch in InstallerImpl (and
>>>> > ResolverImpl) ?
>>>>
>>>> Hi Felix,
>>>>
>>>> Actually, I created a class called LocalResolverImpl which extends
>>>> from
>>>> ResolverImpl. It was meant to deal with the categorization of bundles
>>>> into "updatable bundles" and "installable bundles" and to search for a
>>>> "capable resource" by matching capabilities and requirements. This
>>>> created the potential for intercepting the update process at a certain
>>>> point sometime later. The InstallerImpl was actually built from the
>>>> ground up although it pretty much also does the install operation.
>>>> Similar to your class, it delegates the actual work of deploying the
>>>> updated or new bundle to the resolver and manages the startlevel of
>>>> these bundles.
>>>>
>>>> Regards.
>>>>
>>>> Rick Litton
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: fmeschbe@gmail.com [mailto:fmeschbe@gmail.com] On Behalf Of
>>>> Felix
>>>> Meschberger
>>>> Sent: Friday, March 02, 2007 12:52 AM
>>>> To: felix-dev@incubator.apache.org
>>>> Subject: Re: Leveraging OBR's generic dependency mechanism
>>>>
>>>> Hi Rick,
>>>>
>>>> Thanks for the update.
>>>>
>>>> Just being curious, what exactly did you patch in InstallerImpl (and
>>>> ResolverImpl) ?
>>>>
>>>> Regards
>>>> Felix
>>>>
>>>> On 3/2/07, rl16783@sbcglobal.net <rl...@sbcglobal.net> wrote:
>>>> >
>>>> > FW: Leveraging OBR's generic dependency mechanismHi Felix,
>>>> >
>>>> > Felix Meschberger wrote on 2/22/2007:
>>>> >
>>>> > >Hi,
>>>> >
>>>> > >> Apparently, there is only a single queueHandler
>>>> > >> thread which handles the events. I must be missing something.
>>>> >
>>>> > > The thread is started at the end of the AssemblyManager.start
>>>> method,
>>>> > > which
>>>> > > first gathers existing bundles to jump start the Assembly Manager
>>>> with
>>>> > > simulated events for them. The AssemblyManager.start method itself
>>>> is
>>>> > > called
>>>> > > from AssemblyActivator (the BundleActivator) start method...
>>>> >
>>>> > >> My question is how does the installer handle direct and
>>>> > >> indirect dependencies if those dependencies are also required
>>>> to be
>>>> > >> updated?
>>>> >
>>>> > > Ok. This depends. If the dependencies are included with the
>>>> assembly,
>>>> > > there
>>>> > > lifecycle is controlled through the Assembly Bundle. If the
>>>> dependencies
>>>> > > are
>>>> > > not included in the assembly, and an OBR is used to install the
>>>> bundles,
>>>> > > the
>>>> > > dependencies will be resolved by the OBR and just started by the
>>>> > > AssemblyManager (these are the requiredResources of the Resolver).
>>>> They
>>>> > > are
>>>> > > not further managed by the AssemblyManager, they are just there.
>>>> >
>>>> > > If the dependencies not managed by the AssemblyManage happen to
>>>> require
>>>> > an
>>>> > > update due to updated requirements of managed bundles, these
>>>> updates
>>>> may
>>>> > > take place as a "side effect" of OBR bundle resolution.
>>>> >
>>>> > > So for complete management, it might be a good idea to include all
>>>> > > dependencies as far as possible in the Assembly. Again: This is a
>>>> > > management
>>>> > > task based on a management decision outside of the framework
>>>> and not
>>>> a
>>>> > > technically required task !
>>>> >
>>>> > > Regards
>>>> > > Felix
>>>> >
>>>> > I should have responded much earlier, but instead I would just
>>>> like to
>>>> > provide you with a quick update. Apparently, our automated update
>>>> process
>>>> > using OBR seems to be working. Thanks to your examples and by
>>>> following
>>>> > Richard's original suggestion consisting of 4 steps, I was able to
>>>> build
>>>> > a
>>>> > customized version of InstallerImpl and ResolverImpl. The whole
>>>> process
>>>> > is
>>>> > triggered when a local repository is detected. The approach I have
>>>> taken
>>>> > was to identify updatable bundles (those that have an older version)
>>>> from
>>>> > the installable bundles (those that are entirely new) up front. By
>>>> > matching
>>>> > capabilities and requirements, I was then able to build a list of
>>>> > resources
>>>> > that could be installed, lining them up in a stack, to ensure
>>>> that the
>>>> > required dependencies pulled in were installed first. So far the
>>>> update
>>>> > seems to work provided that there were no cyclical dependencies
>>>> which
>>>> in
>>>> > our
>>>> > case, we took the effort to avoid. Of course, this doesn't sound so
>>>> ideal
>>>> > but it's currently the situation which I know will improve over time
>>>> as
>>>> > the
>>>> > benefits of a service architecture are fully realized.
>>>> >
>>>> > One issue I encountered was with the LocalRepositoryImpl. I may
>>>> have
>>>> it
>>>> > wrong but apparently its m_local variable points to the .felix cache
>>>> > instead
>>>> > of the actual "physical" repository. To resolve this issue, I
>>>> had to
>>>> > create
>>>> > a "map" of the repository so that resources can be discovered and
>>>> > eventually
>>>> > the actual bundles are installed. I also found that the getURL
>>>> method
>>>> of
>>>> > the resource returns null but that was overcome with this
>>>> workaround.
>>>> > Although some more work remains to be completed, overall the
>>>> direction
>>>> > looks
>>>> > okay.
>>>> >
>>>> > And to those who will be at EclipseCon next week, I hope to meet up
>>>> with
>>>> > you
>>>> > at the conference!
>>>> >
>>>> > Best regards.
>>>> > Rick
>>>> >
>>>> >
>>>> >
>>>>
>>>
>>
>>
>>
>
>
Re: Leveraging OBR's generic dependency mechanism
Posted by Rick Litton <rl...@sbcglobal.net>.
Hi all,
Just to add to my response below, I was actually thinking along the lines of
implementing JSR 124 (J2EE Client Provisioning) based on OBR. I know that
provisioning is becoming a hot topic particularly within the Eclipse
community where there are discussions on enhancing the Upgrade Manager
feature. I'm not sure if there is interest among the Felix community
though...
Thanks!
Rick Litton
----- Original Message -----
From: "Rick Litton" <rl...@sbcglobal.net>
To: <fe...@incubator.apache.org>
Sent: Saturday, March 03, 2007 3:04 AM
Subject: Re: Leveraging OBR's generic dependency mechanism
> Hi Felix,
>
> I certainly would like to contribute (not take over) to this feature if
> that's ok. Perhaps we can define some more use cases so that Assembly
> could accommodate other requirements. What do you think?
>
> Rick
>
> ----- Original Message -----
> From: "Felix Meschberger" <Fe...@day.com>
> To: <fe...@incubator.apache.org>
> Sent: Saturday, March 03, 2007 1:39 AM
> Subject: Re: Leveraging OBR's generic dependency mechanism
>
>
>> Hi Rick,
>>
>> Ok, thanks for the information.
>>
>> BTW: As noted earlier I attached the Assembly support stuff to JIRA
>> http://issues.apache.org/jira/browse/FELIX-217. Is there any interest to
>> take this over as a contribution to the Felix project ? Otherwise, I
>> would
>> close the issue again. Thanks for any feedback.
>>
>> Regards
>> Felix
>>
>> On 3/2/07, Rick Litton <Ri...@ktd-kyocera.com> wrote:
>>>
>>> Felix Meschberger wrote:
>>>
>>> > Just being curious, what exactly did you patch in InstallerImpl (and
>>> > ResolverImpl) ?
>>>
>>> Hi Felix,
>>>
>>> Actually, I created a class called LocalResolverImpl which extends from
>>> ResolverImpl. It was meant to deal with the categorization of bundles
>>> into "updatable bundles" and "installable bundles" and to search for a
>>> "capable resource" by matching capabilities and requirements. This
>>> created the potential for intercepting the update process at a certain
>>> point sometime later. The InstallerImpl was actually built from the
>>> ground up although it pretty much also does the install operation.
>>> Similar to your class, it delegates the actual work of deploying the
>>> updated or new bundle to the resolver and manages the startlevel of
>>> these bundles.
>>>
>>> Regards.
>>>
>>> Rick Litton
>>>
>>>
>>> -----Original Message-----
>>> From: fmeschbe@gmail.com [mailto:fmeschbe@gmail.com] On Behalf Of Felix
>>> Meschberger
>>> Sent: Friday, March 02, 2007 12:52 AM
>>> To: felix-dev@incubator.apache.org
>>> Subject: Re: Leveraging OBR's generic dependency mechanism
>>>
>>> Hi Rick,
>>>
>>> Thanks for the update.
>>>
>>> Just being curious, what exactly did you patch in InstallerImpl (and
>>> ResolverImpl) ?
>>>
>>> Regards
>>> Felix
>>>
>>> On 3/2/07, rl16783@sbcglobal.net <rl...@sbcglobal.net> wrote:
>>> >
>>> > FW: Leveraging OBR's generic dependency mechanismHi Felix,
>>> >
>>> > Felix Meschberger wrote on 2/22/2007:
>>> >
>>> > >Hi,
>>> >
>>> > >> Apparently, there is only a single queueHandler
>>> > >> thread which handles the events. I must be missing something.
>>> >
>>> > > The thread is started at the end of the AssemblyManager.start
>>> method,
>>> > > which
>>> > > first gathers existing bundles to jump start the Assembly Manager
>>> with
>>> > > simulated events for them. The AssemblyManager.start method itself
>>> is
>>> > > called
>>> > > from AssemblyActivator (the BundleActivator) start method...
>>> >
>>> > >> My question is how does the installer handle direct and
>>> > >> indirect dependencies if those dependencies are also required to be
>>> > >> updated?
>>> >
>>> > > Ok. This depends. If the dependencies are included with the
>>> assembly,
>>> > > there
>>> > > lifecycle is controlled through the Assembly Bundle. If the
>>> dependencies
>>> > > are
>>> > > not included in the assembly, and an OBR is used to install the
>>> bundles,
>>> > > the
>>> > > dependencies will be resolved by the OBR and just started by the
>>> > > AssemblyManager (these are the requiredResources of the Resolver).
>>> They
>>> > > are
>>> > > not further managed by the AssemblyManager, they are just there.
>>> >
>>> > > If the dependencies not managed by the AssemblyManage happen to
>>> require
>>> > an
>>> > > update due to updated requirements of managed bundles, these updates
>>> may
>>> > > take place as a "side effect" of OBR bundle resolution.
>>> >
>>> > > So for complete management, it might be a good idea to include all
>>> > > dependencies as far as possible in the Assembly. Again: This is a
>>> > > management
>>> > > task based on a management decision outside of the framework and not
>>> a
>>> > > technically required task !
>>> >
>>> > > Regards
>>> > > Felix
>>> >
>>> > I should have responded much earlier, but instead I would just like to
>>> > provide you with a quick update. Apparently, our automated update
>>> process
>>> > using OBR seems to be working. Thanks to your examples and by
>>> following
>>> > Richard's original suggestion consisting of 4 steps, I was able to
>>> build
>>> > a
>>> > customized version of InstallerImpl and ResolverImpl. The whole
>>> process
>>> > is
>>> > triggered when a local repository is detected. The approach I have
>>> taken
>>> > was to identify updatable bundles (those that have an older version)
>>> from
>>> > the installable bundles (those that are entirely new) up front. By
>>> > matching
>>> > capabilities and requirements, I was then able to build a list of
>>> > resources
>>> > that could be installed, lining them up in a stack, to ensure that the
>>> > required dependencies pulled in were installed first. So far the
>>> update
>>> > seems to work provided that there were no cyclical dependencies which
>>> in
>>> > our
>>> > case, we took the effort to avoid. Of course, this doesn't sound so
>>> ideal
>>> > but it's currently the situation which I know will improve over time
>>> as
>>> > the
>>> > benefits of a service architecture are fully realized.
>>> >
>>> > One issue I encountered was with the LocalRepositoryImpl. I may have
>>> it
>>> > wrong but apparently its m_local variable points to the .felix cache
>>> > instead
>>> > of the actual "physical" repository. To resolve this issue, I had to
>>> > create
>>> > a "map" of the repository so that resources can be discovered and
>>> > eventually
>>> > the actual bundles are installed. I also found that the getURL method
>>> of
>>> > the resource returns null but that was overcome with this workaround.
>>> > Although some more work remains to be completed, overall the direction
>>> > looks
>>> > okay.
>>> >
>>> > And to those who will be at EclipseCon next week, I hope to meet up
>>> with
>>> > you
>>> > at the conference!
>>> >
>>> > Best regards.
>>> > Rick
>>> >
>>> >
>>> >
>>>
>>
>
>
>
Re: Leveraging OBR's generic dependency mechanism
Posted by Rick Litton <rl...@sbcglobal.net>.
Hi Felix,
I certainly would like to contribute (not take over) to this feature if
that's ok. Perhaps we can define some more use cases so that Assembly could
accommodate other requirements. What do you think?
Rick
----- Original Message -----
From: "Felix Meschberger" <Fe...@day.com>
To: <fe...@incubator.apache.org>
Sent: Saturday, March 03, 2007 1:39 AM
Subject: Re: Leveraging OBR's generic dependency mechanism
> Hi Rick,
>
> Ok, thanks for the information.
>
> BTW: As noted earlier I attached the Assembly support stuff to JIRA
> http://issues.apache.org/jira/browse/FELIX-217. Is there any interest to
> take this over as a contribution to the Felix project ? Otherwise, I would
> close the issue again. Thanks for any feedback.
>
> Regards
> Felix
>
> On 3/2/07, Rick Litton <Ri...@ktd-kyocera.com> wrote:
>>
>> Felix Meschberger wrote:
>>
>> > Just being curious, what exactly did you patch in InstallerImpl (and
>> > ResolverImpl) ?
>>
>> Hi Felix,
>>
>> Actually, I created a class called LocalResolverImpl which extends from
>> ResolverImpl. It was meant to deal with the categorization of bundles
>> into "updatable bundles" and "installable bundles" and to search for a
>> "capable resource" by matching capabilities and requirements. This
>> created the potential for intercepting the update process at a certain
>> point sometime later. The InstallerImpl was actually built from the
>> ground up although it pretty much also does the install operation.
>> Similar to your class, it delegates the actual work of deploying the
>> updated or new bundle to the resolver and manages the startlevel of
>> these bundles.
>>
>> Regards.
>>
>> Rick Litton
>>
>>
>> -----Original Message-----
>> From: fmeschbe@gmail.com [mailto:fmeschbe@gmail.com] On Behalf Of Felix
>> Meschberger
>> Sent: Friday, March 02, 2007 12:52 AM
>> To: felix-dev@incubator.apache.org
>> Subject: Re: Leveraging OBR's generic dependency mechanism
>>
>> Hi Rick,
>>
>> Thanks for the update.
>>
>> Just being curious, what exactly did you patch in InstallerImpl (and
>> ResolverImpl) ?
>>
>> Regards
>> Felix
>>
>> On 3/2/07, rl16783@sbcglobal.net <rl...@sbcglobal.net> wrote:
>> >
>> > FW: Leveraging OBR's generic dependency mechanismHi Felix,
>> >
>> > Felix Meschberger wrote on 2/22/2007:
>> >
>> > >Hi,
>> >
>> > >> Apparently, there is only a single queueHandler
>> > >> thread which handles the events. I must be missing something.
>> >
>> > > The thread is started at the end of the AssemblyManager.start
>> method,
>> > > which
>> > > first gathers existing bundles to jump start the Assembly Manager
>> with
>> > > simulated events for them. The AssemblyManager.start method itself
>> is
>> > > called
>> > > from AssemblyActivator (the BundleActivator) start method...
>> >
>> > >> My question is how does the installer handle direct and
>> > >> indirect dependencies if those dependencies are also required to be
>> > >> updated?
>> >
>> > > Ok. This depends. If the dependencies are included with the
>> assembly,
>> > > there
>> > > lifecycle is controlled through the Assembly Bundle. If the
>> dependencies
>> > > are
>> > > not included in the assembly, and an OBR is used to install the
>> bundles,
>> > > the
>> > > dependencies will be resolved by the OBR and just started by the
>> > > AssemblyManager (these are the requiredResources of the Resolver).
>> They
>> > > are
>> > > not further managed by the AssemblyManager, they are just there.
>> >
>> > > If the dependencies not managed by the AssemblyManage happen to
>> require
>> > an
>> > > update due to updated requirements of managed bundles, these updates
>> may
>> > > take place as a "side effect" of OBR bundle resolution.
>> >
>> > > So for complete management, it might be a good idea to include all
>> > > dependencies as far as possible in the Assembly. Again: This is a
>> > > management
>> > > task based on a management decision outside of the framework and not
>> a
>> > > technically required task !
>> >
>> > > Regards
>> > > Felix
>> >
>> > I should have responded much earlier, but instead I would just like to
>> > provide you with a quick update. Apparently, our automated update
>> process
>> > using OBR seems to be working. Thanks to your examples and by
>> following
>> > Richard's original suggestion consisting of 4 steps, I was able to
>> build
>> > a
>> > customized version of InstallerImpl and ResolverImpl. The whole
>> process
>> > is
>> > triggered when a local repository is detected. The approach I have
>> taken
>> > was to identify updatable bundles (those that have an older version)
>> from
>> > the installable bundles (those that are entirely new) up front. By
>> > matching
>> > capabilities and requirements, I was then able to build a list of
>> > resources
>> > that could be installed, lining them up in a stack, to ensure that the
>> > required dependencies pulled in were installed first. So far the
>> update
>> > seems to work provided that there were no cyclical dependencies which
>> in
>> > our
>> > case, we took the effort to avoid. Of course, this doesn't sound so
>> ideal
>> > but it's currently the situation which I know will improve over time
>> as
>> > the
>> > benefits of a service architecture are fully realized.
>> >
>> > One issue I encountered was with the LocalRepositoryImpl. I may have
>> it
>> > wrong but apparently its m_local variable points to the .felix cache
>> > instead
>> > of the actual "physical" repository. To resolve this issue, I had to
>> > create
>> > a "map" of the repository so that resources can be discovered and
>> > eventually
>> > the actual bundles are installed. I also found that the getURL method
>> of
>> > the resource returns null but that was overcome with this workaround.
>> > Although some more work remains to be completed, overall the direction
>> > looks
>> > okay.
>> >
>> > And to those who will be at EclipseCon next week, I hope to meet up
>> with
>> > you
>> > at the conference!
>> >
>> > Best regards.
>> > Rick
>> >
>> >
>> >
>>
>
Re: Leveraging OBR's generic dependency mechanism
Posted by Felix Meschberger <Fe...@day.com>.
Hi Rick,
Ok, thanks for the information.
BTW: As noted earlier I attached the Assembly support stuff to JIRA
http://issues.apache.org/jira/browse/FELIX-217. Is there any interest to
take this over as a contribution to the Felix project ? Otherwise, I would
close the issue again. Thanks for any feedback.
Regards
Felix
On 3/2/07, Rick Litton <Ri...@ktd-kyocera.com> wrote:
>
> Felix Meschberger wrote:
>
> > Just being curious, what exactly did you patch in InstallerImpl (and
> > ResolverImpl) ?
>
> Hi Felix,
>
> Actually, I created a class called LocalResolverImpl which extends from
> ResolverImpl. It was meant to deal with the categorization of bundles
> into "updatable bundles" and "installable bundles" and to search for a
> "capable resource" by matching capabilities and requirements. This
> created the potential for intercepting the update process at a certain
> point sometime later. The InstallerImpl was actually built from the
> ground up although it pretty much also does the install operation.
> Similar to your class, it delegates the actual work of deploying the
> updated or new bundle to the resolver and manages the startlevel of
> these bundles.
>
> Regards.
>
> Rick Litton
>
>
> -----Original Message-----
> From: fmeschbe@gmail.com [mailto:fmeschbe@gmail.com] On Behalf Of Felix
> Meschberger
> Sent: Friday, March 02, 2007 12:52 AM
> To: felix-dev@incubator.apache.org
> Subject: Re: Leveraging OBR's generic dependency mechanism
>
> Hi Rick,
>
> Thanks for the update.
>
> Just being curious, what exactly did you patch in InstallerImpl (and
> ResolverImpl) ?
>
> Regards
> Felix
>
> On 3/2/07, rl16783@sbcglobal.net <rl...@sbcglobal.net> wrote:
> >
> > FW: Leveraging OBR's generic dependency mechanismHi Felix,
> >
> > Felix Meschberger wrote on 2/22/2007:
> >
> > >Hi,
> >
> > >> Apparently, there is only a single queueHandler
> > >> thread which handles the events. I must be missing something.
> >
> > > The thread is started at the end of the AssemblyManager.start
> method,
> > > which
> > > first gathers existing bundles to jump start the Assembly Manager
> with
> > > simulated events for them. The AssemblyManager.start method itself
> is
> > > called
> > > from AssemblyActivator (the BundleActivator) start method...
> >
> > >> My question is how does the installer handle direct and
> > >> indirect dependencies if those dependencies are also required to be
> > >> updated?
> >
> > > Ok. This depends. If the dependencies are included with the
> assembly,
> > > there
> > > lifecycle is controlled through the Assembly Bundle. If the
> dependencies
> > > are
> > > not included in the assembly, and an OBR is used to install the
> bundles,
> > > the
> > > dependencies will be resolved by the OBR and just started by the
> > > AssemblyManager (these are the requiredResources of the Resolver).
> They
> > > are
> > > not further managed by the AssemblyManager, they are just there.
> >
> > > If the dependencies not managed by the AssemblyManage happen to
> require
> > an
> > > update due to updated requirements of managed bundles, these updates
> may
> > > take place as a "side effect" of OBR bundle resolution.
> >
> > > So for complete management, it might be a good idea to include all
> > > dependencies as far as possible in the Assembly. Again: This is a
> > > management
> > > task based on a management decision outside of the framework and not
> a
> > > technically required task !
> >
> > > Regards
> > > Felix
> >
> > I should have responded much earlier, but instead I would just like to
> > provide you with a quick update. Apparently, our automated update
> process
> > using OBR seems to be working. Thanks to your examples and by
> following
> > Richard's original suggestion consisting of 4 steps, I was able to
> build
> > a
> > customized version of InstallerImpl and ResolverImpl. The whole
> process
> > is
> > triggered when a local repository is detected. The approach I have
> taken
> > was to identify updatable bundles (those that have an older version)
> from
> > the installable bundles (those that are entirely new) up front. By
> > matching
> > capabilities and requirements, I was then able to build a list of
> > resources
> > that could be installed, lining them up in a stack, to ensure that the
> > required dependencies pulled in were installed first. So far the
> update
> > seems to work provided that there were no cyclical dependencies which
> in
> > our
> > case, we took the effort to avoid. Of course, this doesn't sound so
> ideal
> > but it's currently the situation which I know will improve over time
> as
> > the
> > benefits of a service architecture are fully realized.
> >
> > One issue I encountered was with the LocalRepositoryImpl. I may have
> it
> > wrong but apparently its m_local variable points to the .felix cache
> > instead
> > of the actual "physical" repository. To resolve this issue, I had to
> > create
> > a "map" of the repository so that resources can be discovered and
> > eventually
> > the actual bundles are installed. I also found that the getURL method
> of
> > the resource returns null but that was overcome with this workaround.
> > Although some more work remains to be completed, overall the direction
> > looks
> > okay.
> >
> > And to those who will be at EclipseCon next week, I hope to meet up
> with
> > you
> > at the conference!
> >
> > Best regards.
> > Rick
> >
> >
> >
>
RE: Leveraging OBR's generic dependency mechanism
Posted by Rick Litton <Ri...@ktd-kyocera.com>.
Felix Meschberger wrote:
> Just being curious, what exactly did you patch in InstallerImpl (and
> ResolverImpl) ?
Hi Felix,
Actually, I created a class called LocalResolverImpl which extends from
ResolverImpl. It was meant to deal with the categorization of bundles
into "updatable bundles" and "installable bundles" and to search for a
"capable resource" by matching capabilities and requirements. This
created the potential for intercepting the update process at a certain
point sometime later. The InstallerImpl was actually built from the
ground up although it pretty much also does the install operation.
Similar to your class, it delegates the actual work of deploying the
updated or new bundle to the resolver and manages the startlevel of
these bundles.
Regards.
Rick Litton
-----Original Message-----
From: fmeschbe@gmail.com [mailto:fmeschbe@gmail.com] On Behalf Of Felix
Meschberger
Sent: Friday, March 02, 2007 12:52 AM
To: felix-dev@incubator.apache.org
Subject: Re: Leveraging OBR's generic dependency mechanism
Hi Rick,
Thanks for the update.
Just being curious, what exactly did you patch in InstallerImpl (and
ResolverImpl) ?
Regards
Felix
On 3/2/07, rl16783@sbcglobal.net <rl...@sbcglobal.net> wrote:
>
> FW: Leveraging OBR's generic dependency mechanismHi Felix,
>
> Felix Meschberger wrote on 2/22/2007:
>
> >Hi,
>
> >> Apparently, there is only a single queueHandler
> >> thread which handles the events. I must be missing something.
>
> > The thread is started at the end of the AssemblyManager.start
method,
> > which
> > first gathers existing bundles to jump start the Assembly Manager
with
> > simulated events for them. The AssemblyManager.start method itself
is
> > called
> > from AssemblyActivator (the BundleActivator) start method...
>
> >> My question is how does the installer handle direct and
> >> indirect dependencies if those dependencies are also required to be
> >> updated?
>
> > Ok. This depends. If the dependencies are included with the
assembly,
> > there
> > lifecycle is controlled through the Assembly Bundle. If the
dependencies
> > are
> > not included in the assembly, and an OBR is used to install the
bundles,
> > the
> > dependencies will be resolved by the OBR and just started by the
> > AssemblyManager (these are the requiredResources of the Resolver).
They
> > are
> > not further managed by the AssemblyManager, they are just there.
>
> > If the dependencies not managed by the AssemblyManage happen to
require
> an
> > update due to updated requirements of managed bundles, these updates
may
> > take place as a "side effect" of OBR bundle resolution.
>
> > So for complete management, it might be a good idea to include all
> > dependencies as far as possible in the Assembly. Again: This is a
> > management
> > task based on a management decision outside of the framework and not
a
> > technically required task !
>
> > Regards
> > Felix
>
> I should have responded much earlier, but instead I would just like to
> provide you with a quick update. Apparently, our automated update
process
> using OBR seems to be working. Thanks to your examples and by
following
> Richard's original suggestion consisting of 4 steps, I was able to
build
> a
> customized version of InstallerImpl and ResolverImpl. The whole
process
> is
> triggered when a local repository is detected. The approach I have
taken
> was to identify updatable bundles (those that have an older version)
from
> the installable bundles (those that are entirely new) up front. By
> matching
> capabilities and requirements, I was then able to build a list of
> resources
> that could be installed, lining them up in a stack, to ensure that the
> required dependencies pulled in were installed first. So far the
update
> seems to work provided that there were no cyclical dependencies which
in
> our
> case, we took the effort to avoid. Of course, this doesn't sound so
ideal
> but it's currently the situation which I know will improve over time
as
> the
> benefits of a service architecture are fully realized.
>
> One issue I encountered was with the LocalRepositoryImpl. I may have
it
> wrong but apparently its m_local variable points to the .felix cache
> instead
> of the actual "physical" repository. To resolve this issue, I had to
> create
> a "map" of the repository so that resources can be discovered and
> eventually
> the actual bundles are installed. I also found that the getURL method
of
> the resource returns null but that was overcome with this workaround.
> Although some more work remains to be completed, overall the direction
> looks
> okay.
>
> And to those who will be at EclipseCon next week, I hope to meet up
with
> you
> at the conference!
>
> Best regards.
> Rick
>
>
>
Re: Leveraging OBR's generic dependency mechanism
Posted by Felix Meschberger <Fe...@day.com>.
Hi Rick,
Thanks for the update.
Just being curious, what exactly did you patch in InstallerImpl (and
ResolverImpl) ?
Regards
Felix
On 3/2/07, rl16783@sbcglobal.net <rl...@sbcglobal.net> wrote:
>
> FW: Leveraging OBR's generic dependency mechanismHi Felix,
>
> Felix Meschberger wrote on 2/22/2007:
>
> >Hi,
>
> >> Apparently, there is only a single queueHandler
> >> thread which handles the events. I must be missing something.
>
> > The thread is started at the end of the AssemblyManager.start method,
> > which
> > first gathers existing bundles to jump start the Assembly Manager with
> > simulated events for them. The AssemblyManager.start method itself is
> > called
> > from AssemblyActivator (the BundleActivator) start method...
>
> >> My question is how does the installer handle direct and
> >> indirect dependencies if those dependencies are also required to be
> >> updated?
>
> > Ok. This depends. If the dependencies are included with the assembly,
> > there
> > lifecycle is controlled through the Assembly Bundle. If the dependencies
> > are
> > not included in the assembly, and an OBR is used to install the bundles,
> > the
> > dependencies will be resolved by the OBR and just started by the
> > AssemblyManager (these are the requiredResources of the Resolver). They
> > are
> > not further managed by the AssemblyManager, they are just there.
>
> > If the dependencies not managed by the AssemblyManage happen to require
> an
> > update due to updated requirements of managed bundles, these updates may
> > take place as a "side effect" of OBR bundle resolution.
>
> > So for complete management, it might be a good idea to include all
> > dependencies as far as possible in the Assembly. Again: This is a
> > management
> > task based on a management decision outside of the framework and not a
> > technically required task !
>
> > Regards
> > Felix
>
> I should have responded much earlier, but instead I would just like to
> provide you with a quick update. Apparently, our automated update process
> using OBR seems to be working. Thanks to your examples and by following
> Richard's original suggestion consisting of 4 steps, I was able to build
> a
> customized version of InstallerImpl and ResolverImpl. The whole process
> is
> triggered when a local repository is detected. The approach I have taken
> was to identify updatable bundles (those that have an older version) from
> the installable bundles (those that are entirely new) up front. By
> matching
> capabilities and requirements, I was then able to build a list of
> resources
> that could be installed, lining them up in a stack, to ensure that the
> required dependencies pulled in were installed first. So far the update
> seems to work provided that there were no cyclical dependencies which in
> our
> case, we took the effort to avoid. Of course, this doesn't sound so ideal
> but it's currently the situation which I know will improve over time as
> the
> benefits of a service architecture are fully realized.
>
> One issue I encountered was with the LocalRepositoryImpl. I may have it
> wrong but apparently its m_local variable points to the .felix cache
> instead
> of the actual "physical" repository. To resolve this issue, I had to
> create
> a "map" of the repository so that resources can be discovered and
> eventually
> the actual bundles are installed. I also found that the getURL method of
> the resource returns null but that was overcome with this workaround.
> Although some more work remains to be completed, overall the direction
> looks
> okay.
>
> And to those who will be at EclipseCon next week, I hope to meet up with
> you
> at the conference!
>
> Best regards.
> Rick
>
>
>
RE: Leveraging OBR's generic dependency mechanism
Posted by Rick Litton <Ri...@ktd-kyocera.com>.
Exactly! Thanks for the confirmation. At least I'm on the right track.
;)
Rick Litton
-----Original Message-----
From: Richard S. Hall [mailto:heavy@ungoverned.org]
Sent: Friday, March 02, 2007 12:05 PM
To: felix-dev@incubator.apache.org
Subject: Re: Leveraging OBR's generic dependency mechanism
Rick Litton wrote:
> Richard S. Hall wrote:
>
>
>> I am not sure what you mean by "m_local" points to .felix cache
>>
> instead
>
>> of "physical" repository...
>>
>
> Essentially, what's happening is that the version of the resource
> fetched using LocalRepositoryImpl.getResources() was the current (old)
> version of the bundle which I was trying to update. So I assumed that
> this class acts as a wrapper of the bundle cache. This seems to be a
> logical assumption since the class constructor is
> LocalRepositoryImpl(BundleContext context) and its initialize() method
> basically adds cached bundles to the m_localResourceList list.
>
Well, the only thing LocalRepositoryImpl does is make all installed
bundles look like a OBR repository of resources. This is done by
converting the manifest of each installed bundle into Resource objects.
That's all. It really has nothing to do with the bundle cache. I guess,
if I understand correctly, that this is what you have discovered. :-)
-> richard
> Rick Litton
>
>
> -----Original Message-----
> From: Richard S. Hall [mailto:heavy@ungoverned.org]
> Sent: Friday, March 02, 2007 6:08 AM
> To: felix-dev@incubator.apache.org
> Subject: Re: Leveraging OBR's generic dependency mechanism
>
> rl16783@sbcglobal.net wrote:
>
>> FW: Leveraging OBR's generic dependency mechanismHi Felix,
>>
>> One issue I encountered was with the LocalRepositoryImpl. I may have
>> it wrong but apparently its m_local variable points to the .felix
>> cache instead of the actual "physical" repository. To resolve this
>> issue, I had to create a "map" of the repository so that resources
can
>>
>
>
>> be discovered and eventually the actual bundles are installed.
>>
>
> I am not sure what you mean by "m_local" points to .felix cache
instead
> of "physical" repository...
>
> -> richard
>
>
>> I also found that the getURL method of the resource returns null but
>> that was overcome with this workaround. Although some more work
>> remains to be completed, overall the direction looks okay.
>>
>> And to those who will be at EclipseCon next week, I hope to meet up
>> with you at the conference!
>>
>> Best regards.
>> Rick
>>
>>
>>
Re: Leveraging OBR's generic dependency mechanism
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Rick Litton wrote:
> Richard S. Hall wrote:
>
>
>> I am not sure what you mean by "m_local" points to .felix cache
>>
> instead
>
>> of "physical" repository...
>>
>
> Essentially, what's happening is that the version of the resource
> fetched using LocalRepositoryImpl.getResources() was the current (old)
> version of the bundle which I was trying to update. So I assumed that
> this class acts as a wrapper of the bundle cache. This seems to be a
> logical assumption since the class constructor is
> LocalRepositoryImpl(BundleContext context) and its initialize() method
> basically adds cached bundles to the m_localResourceList list.
>
Well, the only thing LocalRepositoryImpl does is make all installed
bundles look like a OBR repository of resources. This is done by
converting the manifest of each installed bundle into Resource objects.
That's all. It really has nothing to do with the bundle cache. I guess,
if I understand correctly, that this is what you have discovered. :-)
-> richard
> Rick Litton
>
>
> -----Original Message-----
> From: Richard S. Hall [mailto:heavy@ungoverned.org]
> Sent: Friday, March 02, 2007 6:08 AM
> To: felix-dev@incubator.apache.org
> Subject: Re: Leveraging OBR's generic dependency mechanism
>
> rl16783@sbcglobal.net wrote:
>
>> FW: Leveraging OBR's generic dependency mechanismHi Felix,
>>
>> One issue I encountered was with the LocalRepositoryImpl. I may have
>> it wrong but apparently its m_local variable points to the .felix
>> cache instead of the actual "physical" repository. To resolve this
>> issue, I had to create a "map" of the repository so that resources can
>>
>
>
>> be discovered and eventually the actual bundles are installed.
>>
>
> I am not sure what you mean by "m_local" points to .felix cache instead
> of "physical" repository...
>
> -> richard
>
>
>> I also found that the getURL method of the resource returns null but
>> that was overcome with this workaround. Although some more work
>> remains to be completed, overall the direction looks okay.
>>
>> And to those who will be at EclipseCon next week, I hope to meet up
>> with you at the conference!
>>
>> Best regards.
>> Rick
>>
>>
>>
RE: Leveraging OBR's generic dependency mechanism
Posted by Rick Litton <Ri...@ktd-kyocera.com>.
Richard S. Hall wrote:
> I am not sure what you mean by "m_local" points to .felix cache
instead
> of "physical" repository...
Essentially, what's happening is that the version of the resource
fetched using LocalRepositoryImpl.getResources() was the current (old)
version of the bundle which I was trying to update. So I assumed that
this class acts as a wrapper of the bundle cache. This seems to be a
logical assumption since the class constructor is
LocalRepositoryImpl(BundleContext context) and its initialize() method
basically adds cached bundles to the m_localResourceList list.
Rick Litton
-----Original Message-----
From: Richard S. Hall [mailto:heavy@ungoverned.org]
Sent: Friday, March 02, 2007 6:08 AM
To: felix-dev@incubator.apache.org
Subject: Re: Leveraging OBR's generic dependency mechanism
rl16783@sbcglobal.net wrote:
> FW: Leveraging OBR's generic dependency mechanismHi Felix,
>
> One issue I encountered was with the LocalRepositoryImpl. I may have
> it wrong but apparently its m_local variable points to the .felix
> cache instead of the actual "physical" repository. To resolve this
> issue, I had to create a "map" of the repository so that resources can
> be discovered and eventually the actual bundles are installed.
I am not sure what you mean by "m_local" points to .felix cache instead
of "physical" repository...
-> richard
> I also found that the getURL method of the resource returns null but
> that was overcome with this workaround. Although some more work
> remains to be completed, overall the direction looks okay.
>
> And to those who will be at EclipseCon next week, I hope to meet up
> with you at the conference!
>
> Best regards.
> Rick
>
>
Re: Leveraging OBR's generic dependency mechanism
Posted by "Richard S. Hall" <he...@ungoverned.org>.
rl16783@sbcglobal.net wrote:
> FW: Leveraging OBR's generic dependency mechanismHi Felix,
>
> One issue I encountered was with the LocalRepositoryImpl. I may have
> it wrong but apparently its m_local variable points to the .felix
> cache instead of the actual "physical" repository. To resolve this
> issue, I had to create a "map" of the repository so that resources can
> be discovered and eventually the actual bundles are installed.
I am not sure what you mean by "m_local" points to .felix cache instead
of "physical" repository...
-> richard
> I also found that the getURL method of the resource returns null but
> that was overcome with this workaround. Although some more work
> remains to be completed, overall the direction looks okay.
>
> And to those who will be at EclipseCon next week, I hope to meet up
> with you at the conference!
>
> Best regards.
> Rick
>
>
Re: Leveraging OBR's generic dependency mechanism
Posted by rl...@sbcglobal.net.
FW: Leveraging OBR's generic dependency mechanismHi Felix,
Felix Meschberger wrote on 2/22/2007:
>Hi,
>> Apparently, there is only a single queueHandler
>> thread which handles the events. I must be missing something.
> The thread is started at the end of the AssemblyManager.start method,
> which
> first gathers existing bundles to jump start the Assembly Manager with
> simulated events for them. The AssemblyManager.start method itself is
> called
> from AssemblyActivator (the BundleActivator) start method...
>> My question is how does the installer handle direct and
>> indirect dependencies if those dependencies are also required to be
>> updated?
> Ok. This depends. If the dependencies are included with the assembly,
> there
> lifecycle is controlled through the Assembly Bundle. If the dependencies
> are
> not included in the assembly, and an OBR is used to install the bundles,
> the
> dependencies will be resolved by the OBR and just started by the
> AssemblyManager (these are the requiredResources of the Resolver). They
> are
> not further managed by the AssemblyManager, they are just there.
> If the dependencies not managed by the AssemblyManage happen to require an
> update due to updated requirements of managed bundles, these updates may
> take place as a "side effect" of OBR bundle resolution.
> So for complete management, it might be a good idea to include all
> dependencies as far as possible in the Assembly. Again: This is a
> management
> task based on a management decision outside of the framework and not a
> technically required task !
> Regards
> Felix
I should have responded much earlier, but instead I would just like to
provide you with a quick update. Apparently, our automated update process
using OBR seems to be working. Thanks to your examples and by following
Richard's original suggestion consisting of 4 steps, I was able to build a
customized version of InstallerImpl and ResolverImpl. The whole process is
triggered when a local repository is detected. The approach I have taken
was to identify updatable bundles (those that have an older version) from
the installable bundles (those that are entirely new) up front. By matching
capabilities and requirements, I was then able to build a list of resources
that could be installed, lining them up in a stack, to ensure that the
required dependencies pulled in were installed first. So far the update
seems to work provided that there were no cyclical dependencies which in our
case, we took the effort to avoid. Of course, this doesn't sound so ideal
but it's currently the situation which I know will improve over time as the
benefits of a service architecture are fully realized.
One issue I encountered was with the LocalRepositoryImpl. I may have it
wrong but apparently its m_local variable points to the .felix cache instead
of the actual "physical" repository. To resolve this issue, I had to create
a "map" of the repository so that resources can be discovered and eventually
the actual bundles are installed. I also found that the getURL method of
the resource returns null but that was overcome with this workaround.
Although some more work remains to be completed, overall the direction looks
okay.
And to those who will be at EclipseCon next week, I hope to meet up with you
at the conference!
Best regards.
Rick
Re: Leveraging OBR's generic dependency mechanism
Posted by Felix Meschberger <Fe...@day.com>.
Hi,
Apparently, there is only a single queueHandler
> thread which handles the events. I must be missing something.
The thread is started at the end of the AssemblyManager.start method, which
first gathers existing bundles to jump start the Assembly Manager with
simulated events for them. The AssemblyManager.start method itself is called
from AssemblyActivator (the BundleActivator) start method...
My question is how does the installer handle direct and
> indirect dependencies if those dependencies are also required to be
> updated?
Ok. This depends. If the dependencies are included with the assembly, there
lifecycle is controlled through the Assembly Bundle. If the dependencies are
not included in the assembly, and an OBR is used to install the bundles, the
dependencies will be resolved by the OBR and just started by the
AssemblyManager (these are the requiredResources of the Resolver). They are
not further managed by the AssemblyManager, they are just there.
If the dependencies not managed by the AssemblyManage happen to require an
update due to updated requirements of managed bundles, these updates may
take place as a "side effect" of OBR bundle resolution.
So for complete management, it might be a good idea to include all
dependencies as far as possible in the Assembly. Again: This is a management
task based on a management decision outside of the framework and not a
technically required task !
Regards
Felix
RE: Leveraging OBR's generic dependency mechanism
Posted by Rick Litton <Ri...@ktd-kyocera.com>.
Felix Meschberger wrote:
> Hi RIck,
>> Did you envision running the
>> AssemblyManager constantly or is it "activated" as a one-time process
>> and stopped after the process has accomplished its mission and
repeated
>> only when necessary?
> The background thread is started and stopped by the bundle activator.
> Normally, it just sits and waits for events coming in. The reason for
> using a separate thread is, that (1) I do not want to block the
> Framework Event Queue and (2) installation and deinstallation actions
may > be launched, which
> might cause issues like deadlocks if ran synchronously.
> And yes, the actual installation by the Installer retrieved from the
> InstallerService runs in the background, which - currently - is a new
> thread each time bundles are installed or uninstalled.
This is where I was getting at. I was assuming that there was an
external process that started the whole thing and stopped it after
bundles are deployed. Apparently, there is only a single queueHandler
thread which handles the events. I must be missing something.
>> Also, could the more simple "visitor pattern"
>> (such as Peter Kriens's FileInstaller) be sufficient to detect and
>> process the assembly bundles?
> I do not quite understand that. AFAIK the FileInstaller sits and looks
at
> file system locations and installs bundles as they come and uninstalls
> them as the corresponding file goes away, right ? This is more or
less,
> what I do. I just add more fine grained control, in that I support
more
> conrol over the lifecycle of bundles contained in assemblies, like
> starting and stopping. It is the task of the background thread to
react to
> BundleEvents of the assembly bundles.
Right. I also do the same for bundles that we regard as plugins (based
on our definition) since we added more "phases" to the plugin's
lifecycle. My question is how does the installer handle direct and
indirect dependencies if those dependencies are also required to be
updated?
> Regards
> Felix
Thanks again.
Rick
Re: Leveraging OBR's generic dependency mechanism
Posted by Felix Meschberger <Fe...@day.com>.
Hi RIck,
Did you envision running the
> AssemblyManager constantly or is it "activated" as a one-time process
> and stopped after the process has accomplished its mission and repeated
> only when necessary?
The background thread is started and stopped by the bundle activator.
Normally, it just sits and waits for events coming in. The reason for using
a separate thread is, that (1) I do not want to block the Framework Event
Queue and (2) installation and deinstallation actions may be launched, which
might cause issues like deadlocks if ran synchronously.
And yes, the actual installation by the Installer retrieved from the
InstallerService runs in the background, which - currently - is a new thread
each time bundles are installed or uninstalled.
Also, could the more simple "visitor pattern"
> (such as Peter Kriens's FileInstaller) be sufficient to detect and
> process the assembly bundles?
I do not quite understand that. AFAIK the FileInstaller sits and looks at
file system locations and installs bundles as they come and uninstalls them
as the corresponding file goes away, right ? This is more or less, what I
do. I just add more fine grained control, in that I support more conrol over
the lifecycle of bundles contained in assemblies, like starting and
stopping. It is the task of the background thread to react to BundleEvents
of the assembly bundles.
Regards
Felix
RE: Leveraging OBR's generic dependency mechanism
Posted by Rick Litton <Ri...@ktd-kyocera.com>.
Hi Felix,
Thanks for the link and I'm very grateful for the precious insights
provided by your proposed contribution. In browsing through the code, I
noticed that you have decided to use background threads to process
bundle events from an internal queue. Did you envision running the
AssemblyManager constantly or is it "activated" as a one-time process
and stopped after the process has accomplished its mission and repeated
only when necessary? Also, could the more simple "visitor pattern"
(such as Peter Kriens's FileInstaller) be sufficient to detect and
process the assembly bundles?
Rick Litton
-----Original Message-----
From: fmeschbe@gmail.com [mailto:fmeschbe@gmail.com] On Behalf Of Felix
Meschberger
Sent: Tuesday, February 20, 2007 11:34 PM
To: felix-dev@incubator.apache.org
Subject: Re: Leveraging OBR's generic dependency mechanism
Hi,
I thought, it might be worth it to provide the Assembly support code I
talked about to the public:
https://issues.apache.org/jira/browse/FELIX-217
Comments welcome :-)
Regards
Felix
Re: Leveraging OBR's generic dependency mechanism
Posted by Felix Meschberger <Fe...@day.com>.
Hi,
I thought, it might be worth it to provide the Assembly support code I
talked about to the public:
https://issues.apache.org/jira/browse/FELIX-217
Comments welcome :-)
Regards
Felix
RE: Leveraging OBR's generic dependency mechanism
Posted by Rick Litton <Ri...@ktd-kyocera.com>.
Richard S. Hall wrote:
> 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.
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
order
> 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
moment.
> 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
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" <Fe...@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 <se...@panix.com> wrote:
>
>> Felix Meschberger <Fe...@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
>
>
>
Re: Leveraging OBR's generic dependency mechanism
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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" <Fe...@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 <se...@panix.com> wrote:
>
>> Felix Meschberger <Fe...@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
>
>
>