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 <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>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
