Re: Why Bundle.update() method fires a PACKAGES_REFRESHED event ?

[Richard S. Hall]

On 4/10/09 1:40 AM, Pierre De Rop 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) ...

Your bundle will not see services is it not class cast compatible with.

-> richard

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

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org