Richard,
Before posting an issue into osgi-dev about this subject, I would like
to check with you if it really makes sense to wait for the
PACKAGES_REFRESHED ...
Here is my use case:
* bundle B1 exports B1Service
* B2 imports and implements B1Service. When B2 starts: it registers
B1Service into the registry:
registerService(B1Service.class.getName(), this)
* B1 tracks B1Service from the OSGi registry.
* when B2 registers, then B1 catches the B1Service (implemented by
B2) and then invokes some methods on it
So, If I update B1, our "bundle installer" does the following:
* stop B1
* update B1
* refresh B1
* wait for PACKAGES_REFRESHED event
o This will ensure that B2 is fully RESTARTED
* I then restart B1
o At this point: I know that B2 has been restarted and has
already re-registered the new (updated) B1Service into the
OSGi registry
* So, when B1 starts, it finds the B1Service from the OSGi registry
and invokes some methods from it ...
So, as you see, if I don't wait for PACKAGES_REFRESHED event, then I can
run into unexpected ClassCastException, because when B1 is restarted, it
may discover from the registry an old version of the B1Service interface
(the old version before the update) ...
Am I correct ? If true, then I am wondering what does the FileInstall
tool, from Peter Kriens ?
Richard S. Hall wrote:
On 4/9/09 10:14 AM, Pierre De Rop wrote:
Hello everyone,
I just discovered that invoking Bundle.update() method may fire a
framework event PACKAGES_REFRESHED event.
In the trunk, I see, in Felix.java, line 1691, that the "update"
method may invoke the refreshPackage(null) method, which then fires
the event.
To be clear, it only invokes refreshPackages() on the bundle being
updated, not all bundles.
I understand this issue this causes for you, but I am not sure of a
solution. We could possibly add a configuration to turn off
auto-refreshing, but this would really just tie you to Felix since
other implementations may still auto-refresh.
What you really need is for the call to refreshPackages() to return
some sort of request ID so you can check for when your request is
finished.
-> richard
Is is a normal behavior ?
So far, I was fairly certain that this event was only fired after
invoking PackageAdmin.refreshPackages() methods.
Actually, we are using our own bundle installer, which
install/updates our bundles.
And our bundle installer does the following, when it updates a bundle:
class BundleInstaller implements FrameworkListener {
boolean refreshing = false;
void update(Bundle([] bundles) {
for (Bundle b : bundles) {
b.stop();
b.update(); // May fire a PACKAGES_REFRESHED event
}
synchronized (this) {
this.refreshing = true;
}
*packageAdmin.refresh(null); // asynchronous *
synchronized (this) {
*while (refreshing) wait(); *// ensure that all bundles are
refreshed before restarting updated bundles.
}
for (Bundle b : bundles) {
b.start();
}
}
// Here, I listen to the framework event "PACKAGES_REFRESHED"
void frameworkEvent(FrameworkEvent event) {
switch (event.getType()) {
case FrameworkEvent.PACKAGES_REFRESHED:
synchronized (this) {
this.refreshing = false;
notify();
}
}
}
}
The problem here, is that the first loop of my method "update"
invokes Bundle.update(), which may fire some unexpected
PACKAGES_REFRESHED events ...
I'm expecting only one, and my waiting loop exits after the first
event received.
So, what can I do in order to ensure that the
PackageAdmin.refreshPackages(null) method has completed ?
Thanks in advance;
/pierre
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
