Yes. Since PackageAdmin has been deprecated and replace by the Bundle Wiring API, we will not be updating PackageAdmin any more.
You list 2 suggested changes below. The first one should be to replace ACTIVE with the more general term "started" which can include lazy activated bundles in the STARTING state. The second one is incorrect: the remaining steps will not be ignored. That is why it is not a numbered list item. -- 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 From: Ikuo Yamasaki <[email protected]> To: OSGi Developer Mail List <[email protected]> Date: 2011/05/06 22:07 Subject: [osgi-dev] Re: Q on PackageAdmin#refreshPackages() Sent by: [email protected] Richard and BJ, Thank you for the reply. I got what both of you mean. Although, AFAIK, we have no chance to fix the description because org.osgi.service.packageadmin package is removed in R4.3 spec, "7.5.3.11 public void refreshPackages( Bundle[] bundles )" description should have been clafiried as follow: =================================== This method returns to the caller immediately and then performs the following steps on a separate thread: 1 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. The graph may contain UNINSTALLED bundles that are currently still exporting packages. 2 Each bundle in the graph that is in the ACTIVE state will be stopped as described in the Bundle.stop method. >> 2 Each bundle in the graph that is in the STARTING, ACTIVE, or state will be stopped as described in the Bundle.stop method. 3 Each bundle in the graph that is in the RESOLVED state is unresolved and thus moved to the INSTALLED state. The effect of this step is that bundles in the graph are no longer RESOLVED. 4 Each bundle in the graph that is in the UNINSTALLED state is removed from the graph and is now completely removed from the Framework. 5 Each bundle in the graph that was in the ACTIVE state prior to Step 2 is started as described in the Bundle.start method, causing all bundles required for the restart to be resolved. It is possible that, as a result of the previous steps, packages that were previously exported no longer are. Therefore, some bundles may be unresolvable until another bundle offering a compatible package for export has been installed in the Framework. 6 A framework event of type FrameworkEvent.PACKAGES_REFRESHED is fired. For any exceptions that are thrown during any of these steps, a FrameworkEvent of type ERROR is fired containing the exception. >> For any exceptions that are thrown during any of these steps, a FrameworkEvent of type ERROR is fired containing the exception and the remaining steps will be ignored. The source bundle for these events should be the specific bundle to which the exception is related. If no specific bundle can be associated with the exception then the System Bundle must be used as the source bundle for the event. =================================================== Do you agree (just for understanding the expected behaivior) ? Best regards, Ikuo On Fri, 6 May 2011 10:45:40 -0400 BJ Hargrave <[email protected]> wrote: BJ> B could be STARTING because of lazy activation. In that case, it can be BJ> quickly stopped for the refresh. BJ> BJ> But, as Richard notes, it is the wiring that is important. If B is wired BJ> to A and A is refreshed, then B must be refreshed. Since B is being BJ> refreshed, the framework will need to stop it if it is not in the RESOLVED BJ> state and then restart after refresh. BJ> -- BJ> BJ> BJ Hargrave BJ> Senior Technical Staff Member, IBM BJ> OSGi Fellow and CTO of the OSGi Alliance BJ> [email protected] BJ> BJ> office: +1 386 848 1781 BJ> mobile: +1 386 848 3788 BJ> BJ> BJ> BJ> BJ> BJ> From: "Richard S. Hall" <[email protected]> BJ> To: OSGi Developer Mail List <[email protected]> BJ> Date: 2011/05/06 10:09 BJ> Subject: Re: [osgi-dev] Q on PackageAdmin#refreshPackages() BJ> Sent by: [email protected] BJ> BJ> BJ> BJ> On 5/5/11 21:41, Ikuo Yamasaki wrote: BJ> > Hi OSGi Experts, BJ> > BJ> > I have a question(confirmation) on Package Admin Service Spec in R4.2 BJ> > Core Spec. BJ> > BJ> > ============================================== BJ> > [Precondition] BJ> > Bundle-A exports package p (version 1.0). BJ> > Bundle-B imports package p (version 1.0). BJ> > BJ> > [Then] BJ> > 1. Bundle-A is updated: exports package p (version 1.1). BJ> > 2. PackageAdmin#refreshPackages(new Bundle[]{Bundle-A})is called, while BJ> > Bundle-B is in the state of STARTING. BJ> > BJ> > [Expected behaivior] BJ> > Bundle-B will continue to import package p (version 1.0), BJ> > because section 7.5.3.11 does not mention about STARTING/STOPPING at BJ> all. BJ> > ============================================== BJ> > BJ> > Is my understanding correct ? BJ> BJ> No, I don't think so. BJ> BJ> If bundle B is wired to A, it will be pulled into the refresh operation. BJ> Either the refresh operation will end up waiting for B to become active BJ> before stopping it and refreshing it or the entire refresh operation BJ> will fail because B couldn't be stopped. BJ> BJ> -> richard BJ> BJ> > Best regards, BJ> > BJ> > --------------------- BJ> > NTT Cyber Solutions Laboratories BJ> > BJ> > Ikuo YAMASAKI BJ> > E-mail: [email protected] BJ> > TEL +81-46-859-8537 FAX +81-46-855-1282 BJ> > BJ> > BJ> > _______________________________________________ BJ> > OSGi Developer Mail List BJ> > [email protected] BJ> > https://mail.osgi.org/mailman/listinfo/osgi-dev BJ> _______________________________________________ BJ> OSGi Developer Mail List BJ> [email protected] BJ> https://mail.osgi.org/mailman/listinfo/osgi-dev BJ> ======= Ikuo YAMASAKI _______________________________________________ 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
