felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Litton" <rl16...@sbcglobal.net>
Subject Re: Leveraging OBR's generic dependency mechanism
Date Sat, 03 Mar 2007 11:04:28 GMT
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" <Felix.Meschberger@day.com>
To: <felix-dev@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 <Rick.Litton@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 <rl16783@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
>> >
>> >
>> >
>>
> 



Mime
View raw message