All right, I will try to import what I export.
Thanks for your suggestion;
/pierre
Karl Pauls wrote:
No. You don't need to worry about ClassCastExceptions as your bundle
will be wired to the old revision of the bundle. Unless you don't
import what you export :-) See
http://felix.apache.org/site/apache-felix-osgi-faq.html for more on
the why.
regards,
Karl
On Fri, Apr 10, 2009 at 7:40 AM, Pierre De Rop
<pierre.de_...@alcatel-lucent.fr> wrote:
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
