Mailing-List: contact dev-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@felix.apache.org
Received-SPF: neutral (herse.apache.org: local policy)
Message-ID: <464F65B2.5030707@ungoverned.org>
Date: Sat, 19 May 2007 17:01:38 -0400
From: "Richard S. Hall" <heavy@ungoverned.org>
User-Agent: Thunderbird 2.0.0.0 (X11/20070419)
MIME-Version: 1.0
To: dev@felix.apache.org
Subject: Re: [jira] Commented: (FELIX-285) Make resolver more robust
References: <21549877.1179599896133.JavaMail.jira@brutus>
 <00da01c79a52$c0a36d00$6501a8c0@Gemini> <464F5F64.6050106@ungoverned.org>
 <00ef01c79a57$480f6830$6501a8c0@Gemini>
In-Reply-To: <00ef01c79a57$480f6830$6501a8c0@Gemini>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Rick Litton wrote:
> Richard Hall wrote:
>
>> 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.
>
> If I recall correctly, it stopped all the bundles hence, my impression 
> it stopped the framework.  I think this action is also valid after 
> reading the specs.  However, I will try to reproduce it...
>
> P.S.  Any solution to re-ordering of the bundle ids?

I am not sure what you are talking about.

-> richard
>
> Thanks.
>
> Rick Litton
>
> ----- Original Message ----- From: "Richard S. Hall" 
> <heavy@ungoverned.org>
> To: <dev@felix.apache.org>
> Sent: Saturday, May 19, 2007 1:34 PM
> Subject: Re: [jira] Commented: (FELIX-285) Make resolver more robust
>
>
>>
>>
>> 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.
>>>>
>>>>
>>>
>>>
>>
>
>