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:[EMAIL PROTECTED]
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"
<[EMAIL PROTECTED]>
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"
<[EMAIL PROTECTED]>
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)"
<[EMAIL PROTECTED]>
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.
