On Tue, Jul 29, 2008 at 3:43 PM, Thomas Watson <[EMAIL PROTECTED]> wrote: > In this case I would say that the Knopflerfish behavior is the most correct > behavior followed by Equinox. There was a clarification to the specification > recently that mandated that when resolving a bundle the Framework must not > allow a bundle to get wired to a package which is exported from an > uninstalled bundle. It sounds like Felix still allows bundles to resolve to > packages exported by uninstalled bundles.
Can you point me to this clarification? Was on th email list or a registered bug? > > Technically Equinox does not break the contract of the specification because > the refreshPackages method allows for a great range of freedom when it comes > to deciding which bundles belong to the graph of bundles that get refreshed. I do not know about that as section 7.4.3.11 says that: "Compute a graph of bundles starting with the specified bundles. If no bundles are specified, compute a graph of bundles starting with bundle updated or uninstalled since the last call to this method. Add to the graph any bundle that is wired to a package that is currently exported by a bundle in the graph. The graph is fully constructed when there is no bundle outside the graph that is wired to a bundle in the graph." So in my example when refreshing B only B is in the graph as there is no bundle wired to the exported packages of bundle B. So, if we follow the statement above Felix is correct and the Equinox/Knopflerfish are not. > Note that one acceptable implementation is to restart the Framework which > would essentially restart all bundles. In the Equinox case a call to > refreshPackages pulls in any uninstalled bundles that are removal pending > state, in this case Bundle A. This forces both Bundle B and Bundle C to be > refreshed and unresolved. I know that one solution will be framework restart but I do not think that is the case here. Or is it for Equinox? > > Tom > > > > "Alin Dreghiciu" ---07/29/2008 03:35:25 AM---Hi guys, I stumbled yesterday > on different behavior while refreshing packages > > > From: > "Alin Dreghiciu" <[EMAIL PROTECTED]> > To: > "OSGi Alliance - General" <[email protected]> > Date: > 07/29/2008 03:35 AM > Subject: > [osgi-dev] Refresh package behavior > ________________________________ > > > Hi guys, > > I stumbled yesterday on different behavior while refreshing packages > on the 3 OS framework implementations Felix/Equinox/Knopflerfish and > I'm wondering which one do you think is according to the specs. > So, I have: > 1. bundle A exporting packages P1 and P2 > 2. Bundle B importing package P1 > 3. Bundle C importing package P2 > 4. Bundles A,B,C are started (so resolved) > > Then I uninstall bundle A. As I expected bundle B and C remain started > so packages P1 and P2 are resolved and wired to bundle A. > Then I do a refresh on bundle B. After this the state of the bundles B > and C is different on the 3 implementations: > Felix: bundle B and C will still be resolved and started. > Equinox: both bundles B and C will be in installed state and cannot be > resolved (missing imports for P1 and P2) > Knopflerfish: bundle B will in installed state and cannot be resolved > (missing import for P1) and bundle B will be in started state (so it > is resolved) > > So, which one is the correct behavior. Note that I used the shell > command (refresh) available in all of this implementations not the > package admin refresh packages so it can be that the refresh command > did different things not only call the package admin refreshPackages. > This fact I did not check. > > Regards, > -- > Alin Dreghiciu > http://www.ops4j.org - New Energy for OSS Communities - Open > Participation Software. > http://www.qi4j.org - New Energy for Java - Domain Driven Development. > http://malaysia.jayway.net > - New Energy for Projects - Great People > working on Great Projects at Great Places > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > > > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > -- Alin Dreghiciu http://www.ops4j.org - New Energy for OSS Communities - Open Participation Software. http://www.qi4j.org - New Energy for Java - Domain Driven Development. http://malaysia.jayway.net - New Energy for Projects - Great People working on Great Projects at Great Places _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
