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.
Neil > On 5 Nov 2015, at 14:31, Richard S. Hall <he...@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 <he...@ungoverned.org >>> <mailto:he...@ungoverned.org>> wrote: >>> >>> >>> On 11/4/15 06:52 , i...@cuhka.com <mailto:i...@cuhka.com> >>> <mailto:i...@cuhka.com <mailto:i...@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 <njbartl...@gmail.com>: >>>> >>>>>> On 4 Nov 2015, at 11:07, Robert Onslow <robert.ons...@gmail.com> wrote: >>>>>> >>>>>> 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 framework. >>>>> >>>>> 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-unsubscr...@felix.apache.org >>>> For additional commands, e-mail: users-h...@felix.apache.org >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org >>> <mailto:users-unsubscr...@felix.apache.org> >>> <mailto:users-unsubscr...@felix.apache.org >>> <mailto:users-unsubscr...@felix.apache.org>> >>> For additional commands, e-mail: users-h...@felix.apache.org >>> <mailto:users-h...@felix.apache.org> <mailto:users-h...@felix.apache.org >>> <mailto:users-h...@felix.apache.org>> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org > <mailto:users-unsubscr...@felix.apache.org> > For additional commands, e-mail: users-h...@felix.apache.org > <mailto:users-h...@felix.apache.org>
