felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <he...@ungoverned.org>
Subject Re: [jira] Commented: (FELIX-285) Make resolver more robust
Date Sat, 19 May 2007 20:34:44 GMT

Rick Litton wrote:
> This is an important issue but it's difficult to find a solution that 
> can apply to everyone.  In my case however, I perform an update 
> whenever a newer version is available from the repository.  However, 
> it's not as easy as it sounds.  The "update" caches a newer version 
> but the old version still lurks in the cache until 
> PackageAdmin.refreshPackages() is called.  Unfortunately, this last 
> action I believe stops the framework (in Felix) or doesn't work very 
> well from experience.

It doesn't stop the framework, it simply creates a transitive closure of 
all bundles with dependencies on the bundles being refreshed and then 
stops and restarts them all. This is the proper behavior as described by 
the spec. Of course, if there are bugs in this process, please report them.

-> richard

> At any rate, my workaround was to simply to start the new bundle and 
> undeploy the old one. This sequence may not be exactly correct as I 
> don't have the code in front of me.  The other issue I have was the 
> re-ordering of the bundle-id's after bundles have been removed. But 
> this perhaps requires another discussion thread...
> Rick Litton
> ----- Original Message ----- From: "Richard S. Hall (JIRA)" 
> <jira@apache.org>
> To: <dev@felix.apache.org>
> Sent: Saturday, May 19, 2007 11:38 AM
> Subject: [jira] Commented: (FELIX-285) Make resolver more robust
>>    [ 
>> https://issues.apache.org/jira/browse/FELIX-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12497174

>> ]
>> Richard S. Hall commented on FELIX-285:
>> ---------------------------------------
>> One thing I was thinking about with respect to this patch was that 
>> issue (2) listed above now changes the resolver so that it always 
>> performs an update if one is possible, correct? Ultimately, this is a 
>> policy decision that does not minimize the amount of work that OBR 
>> performs. In the old version of the algorithm, the algorithm 
>> minimized the work that it performed and it took a conscious decision 
>> to perform an update (unless dependencies could not be satisfied with 
>> local resources). I am not sure which is the best approach in this 
>> scenario.
>>> Make resolver more robust
>>> -------------------------
>>>                 Key: FELIX-285
>>>                 URL: https://issues.apache.org/jira/browse/FELIX-285
>>>             Project: Felix
>>>          Issue Type: Improvement
>>>          Components: Bundle Repository (OBR)
>>>    Affects Versions: 1.0.0
>>>            Reporter: Bart Elen
>>>         Assigned To: Richard S. Hall
>>>             Fix For: 1.0.0
>>>         Attachments: ResolverImpl.java
>>> There are two issues with the resolver of the current OBR 
>>> implementation:
>>> 1) It does not try each possible composition
>>> Suppose we want to install bundle A, and A has a requirement which 
>>> can be fulfilled by bundle B or C. B itself has a requirement which 
>>> can be fulfilled by bundle X and bundle C has a requirement which 
>>> can be fulfilled by bundle Y.
>>> A-B-X
>>> A-C-Y
>>> Suppose now that bundle X is not available (or can not be installed 
>>> on the local platform)
>>> A-B-
>>> A-C-Y
>>> composition A-C-Y is now a correct composition, but the current 
>>> implementation will notice that bundle B can not be resolved and 
>>> will then stop. OBR will not always detect the correct composition.
>>> 2) Bundles are not always updated
>>> Suppose we want to install bundle A which has a requirement which 
>>> can be fulfilled by bundle B.
>>> A-B
>>> An old version of bundle B is already locally installed on the 
>>> platform but a newer version is available on the repository server. 
>>> The current OBR implementation will detect that the requirement of A 
>>> can be met by the locally installed old version of B and it will not 
>>> check for a newer version on the repository server.
>>> I attached a fixed version of ResolverImpl.java in which the 
>>> described issues are fixed.
>>> This is my first issue submit ever. Feedback to make it better is 
>>> appreciated.
>> -- 
>> This message is automatically generated by JIRA.
>> -
>> You can reply to this email to add a comment to the issue online.

View raw message