You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Lucas Galfaso <lg...@gmail.com> on 2008/06/16 20:47:43 UTC
Bundle update not following the spec?
Hi All,
I find myself many times checking the spec on how a Bundle.update()
should behave so I end up reading Felix code. The spec is not very
clear (and a lot of times it is asking for the proper definition of
what Felix call IModule.)
Anyhow I find the following inconsistencies that I think are based
on discussions of the spec that I did not read.
The spec reads
<quote>
6.1.4.32 public void update( ) throws BundleException
[...]
If this bundle has exported any packages, these packages must not be
updated. Instead, the previous package version must remain exported
until the PackageAdmin.refreshPackages method has been has been called
or the Framework is relaunched.
</quote>
now this is consistent with
http://cwiki.apache.org/FELIX/apache-felix-osgi-faq.html#ApacheFelixOSGiFAQ-ApacheFelixOSGiFrequentlyAskedQuestions
This is, existing modules wired to the old module of the bundle that
was just updated, should remain wired with the old module. Right?
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.
The standard implies that if a package this module exports is used by
any other bundle, then the old package must remain available for
future resolves. This is how Felix behaves even when the wiki reads
something slightly different.
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.
?
I would say "no" as
Felix._updateBundle(FelixBundle bundle, InputStream is)
reads (this action is performed if the new module is loaded properly)
// Mark previous the bundle's old module for removal since
// it can no longer be used to resolve other modules per the spec.
((ModuleImpl) info.getModules()[info.getModules().length -
2]).setRemovalPending(true);
If the answer to the question is "no" then I am not sure how to make
sense of the following sentence
"Otherwise, all old exports must remain available for existing bundles
_and_future_resolves_ until the refreshPackages method is called
or the Framework is restarted."
Help clarifying this issue would be appreciated.
Regards,
Lucas
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Bundle update not following the spec?
Posted by Lucas Galfaso <lg...@gmail.com>.
Well, before my original message I was unsure about some subtleties so
I checked the standard and the answers were not there or it was not
100% clear, I checked Felix FAQ and was somehow more confuse so I
checked Felix code and the comment in the original message just
disconcert me.
Now, I just read Felix FAQ and said "Ahh, this is what the standard
is trying to say!!!!".
Once again, thanks!
On Tue, Jun 24, 2008 at 5:39 PM, Richard S. Hall <he...@ungoverned.org> wrote:
> Lucas Galfaso wrote:
>>
>> Thanks Richard. It is perfect!
>>
>
> Wow, "perfect"...I have outdone myself... ;-)
>
> -> richard
>
>> On Tue, Jun 24, 2008 at 5:25 PM, Richard S. Hall <he...@ungoverned.org>
>> wrote:
>>
>>>
>>> Lucas,
>>>
>>> I updated the FAQ, does it make more sense now?
>>>
>>>
>>> http://cwiki.apache.org/confluence/display/FELIX/Apache+Felix+OSGi+FAQ#ApacheFelixOSGiFAQ-WhenIupdatemybundle%2Cwhyaremybundle%27soldclassesstillbeingused%3F
>>>
>>> -> richard
>>>
>>> Lucas Galfaso wrote:
>>>
>>>>
>>>> Hi,
>>>>
>>>>
>>>>
>>>>
>>>>>>
>>>>>> 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.
>>>>
>>>> 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.
>>>>
>>>> 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.
>>>>
>>>>
>>>>
>>>>
>>>>>>
>>>>>> 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: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Bundle update not following the spec?
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Lucas Galfaso wrote:
> Thanks Richard. It is perfect!
>
Wow, "perfect"...I have outdone myself... ;-)
-> richard
> On Tue, Jun 24, 2008 at 5:25 PM, Richard S. Hall <he...@ungoverned.org> wrote:
>
>> Lucas,
>>
>> I updated the FAQ, does it make more sense now?
>>
>> http://cwiki.apache.org/confluence/display/FELIX/Apache+Felix+OSGi+FAQ#ApacheFelixOSGiFAQ-WhenIupdatemybundle%2Cwhyaremybundle%27soldclassesstillbeingused%3F
>>
>> -> richard
>>
>> Lucas Galfaso wrote:
>>
>>> Hi,
>>>
>>>
>>>
>>>
>>>>> 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.
>>>
>>> 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.
>>>
>>> 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.
>>>
>>>
>>>
>>>
>>>>> 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: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Bundle update not following the spec?
Posted by Lucas Galfaso <lg...@gmail.com>.
Thanks Richard. It is perfect!
On Tue, Jun 24, 2008 at 5:25 PM, Richard S. Hall <he...@ungoverned.org> wrote:
> Lucas,
>
> I updated the FAQ, does it make more sense now?
>
> http://cwiki.apache.org/confluence/display/FELIX/Apache+Felix+OSGi+FAQ#ApacheFelixOSGiFAQ-WhenIupdatemybundle%2Cwhyaremybundle%27soldclassesstillbeingused%3F
>
> -> richard
>
> Lucas Galfaso wrote:
>>
>> Hi,
>>
>>
>>
>>>>
>>>> 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.
>>
>> 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.
>>
>> 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.
>>
>>
>>
>>>>
>>>> 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: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Bundle update not following the spec?
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Lucas,
I updated the FAQ, does it make more sense now?
http://cwiki.apache.org/confluence/display/FELIX/Apache+Felix+OSGi+FAQ#ApacheFelixOSGiFAQ-WhenIupdatemybundle%2Cwhyaremybundle%27soldclassesstillbeingused%3F
-> richard
Lucas Galfaso wrote:
> Hi,
>
>
>
>>> 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.
>
> 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.
>
> 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.
>
>
>
>>> 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: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Bundle update not following the spec?
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Bundle update not following the spec?
Posted by Lucas Galfaso <lg...@gmail.com>.
Hi,
>> 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.
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.
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.
>> 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: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Bundle update not following the spec?
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Karl Pauls wrote:
> On Mon, Jun 16, 2008 at 8:47 PM, Lucas Galfaso <lg...@gmail.com> wrote:
>
>> Hi All,
>> I find myself many times checking the spec on how a Bundle.update()
>> should behave so I end up reading Felix code. The spec is not very
>> clear (and a lot of times it is asking for the proper definition of
>> what Felix call IModule.)
>> Anyhow I find the following inconsistencies that I think are based
>> on discussions of the spec that I did not read.
>>
>> The spec reads
>> <quote>
>> 6.1.4.32 public void update( ) throws BundleException
>> [...]
>> If this bundle has exported any packages, these packages must not be
>> updated. Instead, the previous package version must remain exported
>> until the PackageAdmin.refreshPackages method has been has been called
>> or the Framework is relaunched.
>> </quote>
>>
>> now this is consistent with
>> http://cwiki.apache.org/FELIX/apache-felix-osgi-faq.html#ApacheFelixOSGiFAQ-ApacheFelixOSGiFrequentlyAskedQuestions
>>
>> This is, existing modules wired to the old module of the bundle that
>> was just updated, should remain wired with the old module. Right?
>>
>
> Correct.
>
>
>> 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 standard implies that if a package this module exports is used by
>> any other bundle, then the old package must remain available for
>> future resolves. This is how Felix behaves even when the wiki reads
>> something slightly different.
>>
>
> Where does it read differently?
>
>
>> 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.
>
>
>> I would say "no" as
>>
>> Felix._updateBundle(FelixBundle bundle, InputStream is)
>> reads (this action is performed if the new module is loaded properly)
>> // Mark previous the bundle's old module for removal since
>> // it can no longer be used to resolve other modules per the spec.
>> ((ModuleImpl) info.getModules()[info.getModules().length -
>> 2]).setRemovalPending(true);
>>
>
> This internal comment might be out of date (there has been a
> clarification of the spec a while ago). If an export is used it
> remains available for existing bundles and future resolves until a
> refresh.
>
Yes, the comment it out of date. As Karl says, this was clarified in the
spec.
-> richard
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Bundle update not following the spec?
Posted by Karl Pauls <ka...@gmail.com>.
On Mon, Jun 16, 2008 at 8:47 PM, Lucas Galfaso <lg...@gmail.com> wrote:
> Hi All,
> I find myself many times checking the spec on how a Bundle.update()
> should behave so I end up reading Felix code. The spec is not very
> clear (and a lot of times it is asking for the proper definition of
> what Felix call IModule.)
> Anyhow I find the following inconsistencies that I think are based
> on discussions of the spec that I did not read.
>
> The spec reads
> <quote>
> 6.1.4.32 public void update( ) throws BundleException
> [...]
> If this bundle has exported any packages, these packages must not be
> updated. Instead, the previous package version must remain exported
> until the PackageAdmin.refreshPackages method has been has been called
> or the Framework is relaunched.
> </quote>
>
> now this is consistent with
> http://cwiki.apache.org/FELIX/apache-felix-osgi-faq.html#ApacheFelixOSGiFAQ-ApacheFelixOSGiFrequentlyAskedQuestions
>
> This is, existing modules wired to the old module of the bundle that
> was just updated, should remain wired with the old module. Right?
Correct.
> 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 standard implies that if a package this module exports is used by
> any other bundle, then the old package must remain available for
> future resolves. This is how Felix behaves even when the wiki reads
> something slightly different.
Where does it read differently?
> 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.
> I would say "no" as
>
> Felix._updateBundle(FelixBundle bundle, InputStream is)
> reads (this action is performed if the new module is loaded properly)
> // Mark previous the bundle's old module for removal since
> // it can no longer be used to resolve other modules per the spec.
> ((ModuleImpl) info.getModules()[info.getModules().length -
> 2]).setRemovalPending(true);
This internal comment might be out of date (there has been a
clarification of the spec a while ago). If an export is used it
remains available for existing bundles and future resolves until a
refresh.
> If the answer to the question is "no" then I am not sure how to make
> sense of the following sentence
> "Otherwise, all old exports must remain available for existing bundles
> _and_future_resolves_ until the refreshPackages method is called
> or the Framework is restarted."
>
> Help clarifying this issue would be appreciated.
Hope this helps.
regards,
Karl
> Regards,
> Lucas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
Karl Pauls
karlpauls@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org