On 05/11/15 18: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.
How about pouring that into a management agent specification?
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>
--
Ferry Huberts
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
