Well step 5 should just be refresh of the daemon bundle. This will discard the class loader for the daemon bundle and create a new one with "fresh" wires.
I assume the daemon bundle did not change, so an update is not necessary. -- BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [EMAIL PROTECTED] office: +1 386 848 1781 mobile: +1 386 848 3788 "Pernet, Olivier" <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 2007-06-11 08:17 Please respond to OSGi Developer Mail List <[email protected]> To "OSGi Developer Mail List" <[email protected]> cc Subject RE: [osgi-dev] Semantics of the refresh operation & uninstall andwires Thanks ! Things are making more sense now, but I probably need some more advice. I'm working on integrating an HP open-source project (www.smartfrog.org) with OSGi. In a nutshell, it's a distributed application deployment and configuration framework, where you have a daemon running on each machine in the system that takes care of user-written system description and components. The existing codebase uses Class.forName to load user components, so as a first step I've used DynamicImport-Package: * in the daemon bundle, and exported the package that has user components in my test user bundle. I know this is not ideal, and a redesign of how user components are exposed to the daemon is being envisioned. But right now I'd like the current approach to work, and here is my problem : 1. I install the daemon bundle. 2. I submit a system description to be deployed, that involves installing a new bundle from a given URL. 3. The new bundle is installed, and user component classes are loaded from it. Because of the DynamicImport-Package directive, a wire is created from the daemon bundle to the user bundle. 4. I now ask for the system description to be undeployed, and as a result the user bundle is uninstalled. 5. I update the daemon bundle. The wire to the uninstalled user bundle still exists. 6. I ask for the same system description to be deployed. It fails with a ClassCastException. However, if I refresh the packages between 5 and 6, things work fine. Any idea about what I'm doing wrongly ? Cheers, Olivier From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Felix Meschberger Sent: 11 June 2007 13:03 To: OSGi Developer Mail List Subject: Re: [osgi-dev] Semantics of the refresh operation & uninstall andwires Hi Olivier, While I am not fluent with the history of OSGi, I try to answer from the point of view of a user of R4.... - I don't understand why an "update" does not trigger a "refresh" of the targeted bundle. Update is an operation on a bundle. Refresh is part of the Package Admin Service. When a bundle is updated, new wires will not be added to the old version of the bundle but to the new. But, old wirings to the old bundle remain intact. In fact, the existing bundles generally are not touched by a bundle update itself. Only when the Package Admin Service is refreshing the packages, which means cuttin wires to unsinstalled bundles and old versions of updated bundles and rewiring to current bundles, is the rest of the system touched. Refreshing is a potentially expensive operation, as all the package imports and exports have to be rewired for the bundles, which are refreshed. Therefore it makes sens IMHO to not refresh on a bundle update. Additionally, you might want to update multiple bundles and install and uninstall even more bundles before actually refreshing to the packages: to save time and probably and because there may new dependencies of updated bundles, which may only be met by updating other bundles. - I can't find where in the specification the semantics of "refresh" are defined. It's mentionned a few times but it doesn't seem to have a devoted section. As I said, package refresh is part of the Package Admin Service specification as the PackageAdmin.refreshPackages method. Also, why does a wire still exist after one of its ends has been uninstalled ? Uninstalled bundles remain in the system until the packages are refreshed or the system is re-started. Hope this helps. Regards Felix_______________________________________________ OSGi Developer Mail List [email protected] http://www2.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List [email protected] http://www2.osgi.org/mailman/listinfo/osgi-dev
