Lucas Galfaso wrote:
The standard also reads
<quote>
4.3.10 Updating Bundles
[...]
The update process supports migration from one version of a bundle to
a newer version of the same bundle. The exports of an updated bundle
must be immediately available to the Framework. If none of the old
exports are used, then the old exports must be removed. Otherwise, all
old exports must remain available for existing bundles and future
resolves until the refreshPackages method is called or the Framework
is restarted.
</quote>
Now, this is somehow different from what
http://cwiki.apache.org/FELIX/apache-felix-osgi-faq.html#ApacheFelixOSGiFAQ-ApacheFelixOSGiFrequentlyAskedQuestions
reads, this may not be too bad as you may say that the wiki is just
slightly incomplete. Just as I said, not Not too bad.
Why is it incomplete?
The wiki reads (cut some cut&paste to make it clearer)
1. Your bundle does not export any packages.
- The updated classes should become available immediately.
2. Your bundle exports some packages, but does not import those same packages.
- The updated classes should become available immediately.
- However other bundles using the exported packages from the
updated bundle will not start using the new classes until
PackageAdmin.refreshPackages() is called (this can be invoked in the
Felix shell using the refresh command).
3. Your bundle exports some packages and also imports those same
packages (see the importing and exporting FAQ below).
- Neither the updated bundle nor any bundles importing packages
from the updated bundle will see any updated classes until the
packages are refreshed.
1. If no bundle is wired to the old module by the use of an import or
dynamic import.*
- The updated classes should become available immediately.
- The old module will be removed and cannot be used to resolve a bundle.
* Note: If your bundle does not export, then no bundle can create a wire to it.
The wiki should probably say "if the bundle does not export any packages
or no exported packages are in use".
2. There is a bundle wired to old module by the use of an import or
dynamic import (this bundle may be the same bundle being updated).
- Existing wires to this bundle will not start using the new
classes until PackageAdmin.refreshPackages() is called.
- The old module will remain and may be used to resolve a bundle
until PackageAdmin.refreshPackages() is called.
- New bundles and bundles that are updated may use the new or old
module of the updated bundle.
- All bundles using dynamic import may pick the new or old module
of the updated bundle when creating a new wire.
A bundle that imports its own package is not considered to be "wired" to
that package.
There are still the three distinct cases as mentioned in the FAQ.
Is the above right? Even if the above is right, I think that using a
simpler wording is better as a simplified interpretation of the FAQ
may be "after you update a bundle, execute a refresh" and this is what
90% of the users want to know.
I am not sure what you mean. Are you saying that the entire FAQ answer
should simply say, "do a refresh after updating your bundle"? If so, I
disagree, I think it is better to explain why. However, that doesn't
mean that the currently wording cannot be improved.
Maybe I will try to take a crack at it tomorrow...
-> richard
Now, the issue is that using the Felix IModule naming, would it be
correct to say that the spec implies that:
- If we have a module X that is being updated, and there is another
module Y that is wired to X, then X must remain available to future
resolves. This future resolves includes new bundles.
?
Yes.
Ok
Hope this helps.
It helped a lot, huge thanks.
Regards,
Lucas
regards,
Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
