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?
----- 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.
