Thanks, BJ ! On Tue, 21 Jun 2011 03:30:12 -0400 BJ Hargrave <[email protected]> wrote:
BJ> Yes. If the state change lock acquire times out, then the state cant be BJ> changes and the bundle will not have been uninstalled. 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: Ikuo Yamasaki <[email protected]> BJ> To: OSGi Developer Mail List <[email protected]> BJ> Date: 2011/06/21 03:10 BJ> Subject: Re: [osgi-dev] Q on Bundle#uninstall() BJ> Sent by: [email protected] BJ> BJ> BJ> BJ> Hi BJ, BJ> BJ> If Bundle.uninstall fails to obtain the state change lock, BJ> what will happen ? BJ> BJ> What I understand is BJ> - BundleException will be thrown and the bundle state will not be BJ> UNINSTALLED. BJ> BJ> Is it correct ? BJ> BJ> Best regards, BJ> BJ> Ikuo BJ> BJ> p.s. In R4.3 Core Spec, "9.1.5.37 public void uninstall( )" says BJ> ---- BJ> BundleException If the uninstall failed. This can occur if another BJ> thread is attempting to change this bundle’s state and does not BJ> complete in a timely manner. BundleException types thrown by this method BJ> include: BundleException.STATECHANGE_ERROR BJ> ---- BJ> BJ> On Fri, 27 May 2011 11:54:10 +0900 BJ> Ikuo Yamasaki <[email protected]> wrote: BJ> BJ> Ikuo> BJ, BJ> Ikuo> BJ> Ikuo> I got what you mean. Thanks as always! BJ> Ikuo> BJ> Ikuo> Ikuo BJ> Ikuo> BJ> Ikuo> On Thu, 26 May 2011 22:24:46 -0400 BJ> Ikuo> BJ Hargrave <[email protected]> wrote: BJ> Ikuo> BJ> Ikuo> BJ> Bundle.uninstall does not call Bundle.stop. It just says it BJ> stops the BJ> Ikuo> BJ> bundle as described in Bundle.stop. First Bundle.uninstall must BJ> obtain the BJ> Ikuo> BJ> state change lock. Once this occurs, the bundle can be stopped. BJ> Any BJ> Ikuo> BJ> exception thrown by BundleActivator.stop is published as a BJ> FrameworkEvent, BJ> Ikuo> BJ> but uninstall still completes normally. Only if the state change BJ> lock BJ> Ikuo> BJ> cannot be obtained in a reasonable time, will uninstall BJ> terminate with an BJ> Ikuo> BJ> exception. BJ> Ikuo> BJ> BJ> Ikuo> BJ> So case 1 never happens during uninstall since uninstall does BJ> not call BJ> Ikuo> BJ> stop. BJ> Ikuo> BJ> -- BJ> Ikuo> BJ> BJ> Ikuo> BJ> BJ Hargrave BJ> Ikuo> BJ> Senior Technical Staff Member, IBM BJ> Ikuo> BJ> OSGi Fellow and CTO of the OSGi Alliance BJ> Ikuo> BJ> [email protected] BJ> Ikuo> BJ> BJ> Ikuo> BJ> office: +1 386 848 1781 BJ> Ikuo> BJ> mobile: +1 386 848 3788 BJ> Ikuo> BJ> BJ> Ikuo> BJ> BJ> Ikuo> BJ> BJ> Ikuo> BJ> BJ> Ikuo> BJ> BJ> Ikuo> BJ> From: Ikuo Yamasaki <[email protected]> BJ> Ikuo> BJ> To: OSGi Developer Mail List <[email protected]> BJ> Ikuo> BJ> Date: 2011/05/26 20:53 BJ> Ikuo> BJ> Subject: Re: [osgi-dev] Q on Bundle#uninstall() BJ> Ikuo> BJ> Sent by: [email protected] BJ> Ikuo> BJ> BJ> Ikuo> BJ> BJ> Ikuo> BJ> BJ> Ikuo> BJ> Hi BJ, BJ> Ikuo> BJ> BJ> Ikuo> BJ> On Thu, 26 May 2011 18:46:25 -0400 BJ> Ikuo> BJ> BJ Hargrave <[email protected]> wrote: BJ> Ikuo> BJ> BJ> Ikuo> BJ> BJ> No. If stop completes with an exception, uninstall can still BJ> proceed. BJ> Ikuo> BJ> BJ> Uninstall can fail if the state change lock is held by BJ> another thread BJ> Ikuo> BJ> and BJ> Ikuo> BJ> BJ> that thread does not release the lock in some reasonable BJ> time. BJ> Ikuo> BJ> BJ> Ikuo> BJ> Spec says: BJ> Ikuo> BJ> -- quote ------------------------------------------------------- BJ> Ikuo> BJ> public void stop( int options ) throws BundleException BJ> Ikuo> BJ> BJ> Ikuo> BJ> 2 If this bundle is in the process of being activated or BJ> deactivated then BJ> Ikuo> BJ> this BJ> Ikuo> BJ> method must wait for activation or deactivation to complete BJ> before BJ> Ikuo> BJ> continuing. BJ> Ikuo> BJ> If this does not occur in a reasonable time, a BundleException BJ> is BJ> Ikuo> BJ> thrown to indicate this bundle was unable to be stopped. BJ> Ikuo> BJ> BJ> Ikuo> BJ> -- quote ------------------------------------------------------- BJ> Ikuo> BJ> BJ> Ikuo> BJ> It seems to me there exists two cases: BJ> Ikuo> BJ> BJ> Ikuo> BJ> Case1: Bundle.stop() throws BundleException due to the above BJ> reason. BJ> Ikuo> BJ> (Bundle#uninstall() does not throw BundleException) BJ> Ikuo> BJ> BJ> Ikuo> BJ> Case2: the state change lock is held by another thread and BJ> Ikuo> BJ> that thread does not release the lock in some reasonable BJ> time. BJ> Ikuo> BJ> (Bundle#uninstall() throws BundleException) BJ> Ikuo> BJ> BJ> Ikuo> BJ> Q1. Does Case2 include Case1 or not ? BJ> Ikuo> BJ> BJ> Ikuo> BJ> For me, yes. BJ> Ikuo> BJ> BJ> Ikuo> BJ> Q2. when should those check for Case2 be done in the following BJ> steps BJ> Ikuo> BJ> described in "6.1.4.35 public void uninstall( )" BJ> Ikuo> BJ> BJ> Ikuo> BJ> --begin quote--- BJ> Ikuo> BJ> The following steps are required to uninstall a bundle: BJ> Ikuo> BJ> 1 If this bundle’s state is UNINSTALLED then an BJ> IllegalStateException is BJ> Ikuo> BJ> thrown. BJ> Ikuo> BJ> 2 If this bundle’s state is ACTIVE, STARTING or STOPPING, this BJ> bundle is BJ> Ikuo> BJ> stopped as described in the Bundle.stop method. If Bundle.stop BJ> throws BJ> Ikuo> BJ> an exception, a Framework event of type FrameworkEvent.ERROR is BJ> Ikuo> BJ> fired containing the exception. BJ> Ikuo> BJ> 3 This bundle’s state is set to UNINSTALLED. BJ> Ikuo> BJ> 4 A bundle event of type BundleEvent.UNINSTALLED is fired. BJ> Ikuo> BJ> 5 This bundle and any persistent storage area provided for this BJ> bundle by BJ> Ikuo> BJ> the Framework are removed. BJ> Ikuo> BJ> --end quote--- BJ> Ikuo> BJ> BJ> Ikuo> BJ> Q3. Even in Case2, step 3-5 should be done. Is my understanding BJ> correct ? BJ> Ikuo> BJ> BJ> Ikuo> BJ> ======= BJ> Ikuo> BJ> Ikuo YAMASAKI BJ> Ikuo> BJ> BJ> Ikuo> BJ> BJ> Ikuo> BJ> _______________________________________________ BJ> Ikuo> BJ> OSGi Developer Mail List BJ> Ikuo> BJ> [email protected] BJ> Ikuo> BJ> https://mail.osgi.org/mailman/listinfo/osgi-dev BJ> Ikuo> BJ> BJ> Ikuo> BJ> Ikuo> ======= BJ> Ikuo> Ikuo YAMASAKI BJ> Ikuo> BJ> Ikuo> BJ> Ikuo> _______________________________________________ BJ> Ikuo> OSGi Developer Mail List BJ> Ikuo> [email protected] BJ> Ikuo> https://mail.osgi.org/mailman/listinfo/osgi-dev BJ> Ikuo> BJ> Ikuo> BJ> BJ> ======= BJ> Ikuo YAMASAKI BJ> 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
