felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Litton" <Rick.Lit...@ktd-kyocera.com>
Subject RE: [jira] Commented: (FELIX-285) Make resolver more robust
Date Mon, 21 May 2007 22:35:19 GMT

Or override the ps command with an ss command that does what you
mentioned below but I think that won't go down well with another crowd.
;)  Yes, I'll put my thinking hat on and share it before proceeding.
Meanwhile, I'll try to appease those pesky... who was it who said 'they
are the gods of the network universe' (could be me).  

Rick Litton

-----Original Message-----
From: Richard S. Hall [mailto:heavy@ungoverned.org] 
Sent: Monday, May 21, 2007 3:14 PM
To: dev@felix.apache.org
Subject: Re: [jira] Commented: (FELIX-285) Make resolver more robust

On May 21, 2007, at 6:04 PM, Rick Litton wrote:

>
> Yes, they should be "deft enough" but system admins can be a curious
> bunch (no offense...I used to be one). ;)  I'm  merely using shell.tui
> so probably just need to modify it a little bit or may be create a
> custom command.  Thanks for the suggestion.

Yes, that would be another approach, but it really depends on what you 
want to do whether or not it will be that simple. If you just want to 
have a 'ps' command that shows installed bundles, then it might work. 
But if you expect them to be able to take some action based on that 
alias, then you would probably need to create a whole new set of 
commands that understood your "aliasing" system.

For example, if your "ps" command showed "5" for a bundle whose ID was 
"134", then when the system admin typed "stop 5", the stop command 
would have to be able to do the mapping to "134".

This could also be problematic given concurrent modification, e.g., 
someone uninstalls an alias at the same time someone tried to stop it. 
If you automatically slid all aliases down on an uninstall, then 
ordering becomes an issue.

A simpler approach is to switch to the GUI and just let them 
point-and-click. :-)

Feel free to post your thoughts on a solution for input...pesky system 
admins...

-> richard


>
>
> -----Original Message-----
> From: Richard S. Hall [mailto:heavy@ungoverned.org]
> Sent: Monday, May 21, 2007 2:56 PM
> To: dev@felix.apache.org
> Subject: Re: [jira] Commented: (FELIX-285) Make resolver more robust
>
> On May 21, 2007, at 5:50 PM, Rick Litton wrote:
>
>> Richard S. Hall wrote:
>>
>>> But, ultimately, there is no way to avoid holes.
>>
>> That's unfortunate. I know it shouldn't bother me but my concern is
>> that
>> once we get into the high 2-digit and even triple-digit numbers it
> will
>> become too noticeable to ignore. By then people might start to wonder
>> why their systems appeared incomplete.  I wonder if anyone has found
a
>> workaround to this restriction. I realize too that it is a "ui thing"
>> which certainly can be masked...or nothing that creating a new
profile
>> will not solve.
>
> The bundle ID is a framework assigned identifier which is really not
> intended for human consumption. If you want to assign nice numbers in
> your GUI then just getBundles() and loop through showing the user your
> loop variable. Or better yet, show the name and bundle description,
> which are intended for humans.
>
> Showing the user the bundle ID is nearly equivalent to showing them
> pointer values...on the other hand, if your users are deft enough to
> understand these values, then they are probably deft enough to accept
> that they have holes, no?
>
> -> richard
>
>
>>
>> Rick Litton
>>
>>
>> -----Original Message-----
>> From: Richard S. Hall [mailto:heavy@ungoverned.org]
>> Sent: Saturday, May 19, 2007 3:47 PM
>> To: dev@felix.apache.org
>> Subject: Re: [jira] Commented: (FELIX-285) Make resolver more robust
>>
>> Rick Litton wrote:
>>> Here's an actual example:
>>>
>>> -> ps
>>> START LEVEL 1
>>> ...
>>> [  14] [Active     ] [    1] Framework Manager (1.1.0)
>>> [  16] [Active     ] [    1] Framework Upgrade (1.1.0)
>>> [  17] [Active     ] [    1] Framework Messaging (1.1.1)
>>>
>>> Bundle 15 was uninstalled previously.  Is there an easier way to
>>> renumber the sequence so that "holes" do not appear apart from
>>> resetting all the bundle ids programmatically?
>>
>> The spec specifically says that bundle IDs should not be re-used, I
>> believe...in truth, Felix doesn't strictly obey this, because Felix
>> starts from the highest bundle ID discovered on framework startup.
So,
>> if you delete the highest bundle, then shutdown and restart, Felix
> will
>> re-use that bundle ID.
>>
>> But, ultimately, there is no way to avoid holes.
>>
>> -> richard
>>
>>>
>>>
>>> ----- Original Message ----- From: "Richard S. Hall"
>>> <heavy@ungoverned.org>
>>> To: <dev@felix.apache.org>
>>> Sent: Saturday, May 19, 2007 2:01 PM
>>> Subject: Re: [jira] Commented: (FELIX-285) Make resolver more robust
>>>
>>>
>>>> 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.
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>


Mime
View raw message