felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <he...@ungoverned.org>
Subject Re: Uninstalled API bundle, yet implementation still resolves and starts
Date Thu, 05 Nov 2015 18:46:00 GMT

On 11/5/15 12:26 , Neil Bartlett wrote:
> Thanks Richard, that’s very clear.
> It almost makes me think that, if we were designing the OSGi APIs all over again, management
agents should be required to open a batch operation in order to do any install/update/uninstall.
The operations in the batch would not take effect in the framework until it was committed,
which would be equivalent to a refresh.

Yes, Tom Watson and I discussed this very thing some time ago...we both 
agreed that would make much more sense and would technically be nicer too.

-> richard

p.s. Sorry for the mistakes in my original response. For clarification, 
"installing to stale packages" should have been "wiring to stale 
packages" and "this top" should have been "this topic".

> Neil
>> On 5 Nov 2015, at 14:31, Richard S. Hall <heavy@ungoverned.org> wrote:
>> On 11/5/15 05:04 , Neil Bartlett wrote:
>>> Hi Richard,
>>> I agree with you, and I understand why the existing active bundles remain wired
to the uninstalled bundle until refresh. However it sounded like the newly installed bundle
was wiring to the uninstalled bundle. This doesn’t sound right… the framework shouldn’t
create new wires into uninstalled bundles, should it?
>> It depends, but it is certainly not wrong to do so, since clearly the packages are
still available to the system.
>> I have made an argument before that installing to stale packages is reasonable because
it results in fewer class spaces if the framework is not refreshed. I still think this argument
is valid, although I admit that you could differentiate between stale packages from an updated
bundle versus stale packages from an uninstalled bundle. However, I'm not sure it is worthwhile
to draw that distinction, since if you are uninstalling, you should do a refresh. Period.
>> Peter has argued before on this top that any update/uninstall should *always* be
followed by a refresh, which I don't completely agree with but I do think that in general
it is the right thing to do and only people who know what they are doing shouldn't refresh.
>> For example, if you have an bundle that exports some package and you make changes
that only impact internal packages and you really don't want to bring down the entire system
(potentially losing state, etc.), then it is possible to update that bundle and not refresh
so the system can continue to use the stale packages.
>> Of course, this would only work if the bundle in question was importing what it exported.
Assuming it was, then the resolver is free to wire it to its own stale packages.
>> As you can see, though, this is only for people who really know what they are doing,
which is why 99% of the time I agree with Peter on this subject that you should refresh.
>> -> richard
>>> This assumes I have correctly understood the scenario as described by Maurice.
>>> Neil
>>>> On 4 Nov 2015, at 13:31, Richard S. Hall <heavy@ungoverned.org <mailto:heavy@ungoverned.org>>
>>>> On 11/4/15 06:52 , info@cuhka.com <mailto:info@cuhka.com> <mailto:info@cuhka.com
<mailto:info@cuhka.com>> wrote:
>>>>> I 'solved' it by restarting the device. I rather don't, as I like solution
where I can upgrade functionality without shutting down.
>>>> You don't need to shut down, you just need to refresh the framework. If you
update A and S, the old version of A is still hanging around because X1 is using it. So, you
have your framework state in somewhat of an "in between" stage. Refreshing things gets everything
back in shape. There are very few rare instances where you would not want to refresh after
an update or an uninstall...99% of the time, you should refresh after either of those operations.
>>>> -> richard
>>>>> Basically my structure is as follows:
>>>>> Bundle A: API
>>>>> Bundle S: Service (uses and provides some API implementation from A)
>>>>> Bundle X1..N: Provide functionality for S using the extender pattern,
use and provide some API implementation from A)
>>>>> I updated A and S. For the X bundles the API change wasn't important,
but for S it was. Somehow S still picked up old-A, while I had uninstalled old-A (and old-S).
I have updated my tooling from 'THE OSGi plugin' from Gradle to use 'the bnd OSGi plugin'.
I noticed that the old plugin would automatically add A's package as Export-Bundle, while
with bnd's plugin I had to do that myself. Maybe that caused the problem.
>>>>> Maurice.
>>>>> Citeren Neil Bartlett <njbartlett@gmail.com>:
>>>>>>> On 4 Nov 2015, at 11:07, Robert Onslow <robert.onslow@gmail.com>
>>>>>>> Delete the directory called felix-cache??
>>>>>> No, in his second email he says that other bundles are still running
that use the old API. So we’re talking about a series of changes made in a running OSGi
Framework, and it wouldn’t be a good idea to delete the storage directory underneath a running
>>>>>> These changes *should* work. Best guess is that the implementation
bundle ships its own copy of the API bundle.
>>>>>> As a general rule, you should do a refresh after a series of changes
to bundle states (installs, uninstalls or updates). You can do this simply with the “refresh”
command in the Gogo shell. In this scenario, a refresh would cause all the bundles that import
from the API bundle to stop and revert to INSTALLED state.
>>>>>> Regards,
>>>>>> Neil
>>>>> ---------------------------------------------------------------------
>>>>> 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 <mailto:users-unsubscribe@felix.apache.org>
<mailto:users-unsubscribe@felix.apache.org <mailto:users-unsubscribe@felix.apache.org>>
>>>> For additional commands, e-mail: users-help@felix.apache.org <mailto:users-help@felix.apache.org>
<mailto:users-help@felix.apache.org <mailto:users-help@felix.apache.org>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org <mailto:users-unsubscribe@felix.apache.org>
>> For additional commands, e-mail: users-help@felix.apache.org <mailto:users-help@felix.apache.org>

To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org

View raw message