BJ,

I got what you mean. Thanks as always!

Ikuo

On Thu, 26 May 2011 22:24:46 -0400
BJ Hargrave <[email protected]> wrote:

BJ> Bundle.uninstall does not call Bundle.stop. It just says it stops the 
BJ> bundle as described in Bundle.stop. First Bundle.uninstall must obtain the 
BJ> state change lock. Once this occurs, the bundle can be stopped. Any 
BJ> exception thrown by BundleActivator.stop is published as a FrameworkEvent, 
BJ> but uninstall still completes normally. Only if the state change lock 
BJ> cannot be obtained in a reasonable time, will uninstall terminate with an 
BJ> exception.
BJ> 
BJ> So case 1 never happens during uninstall since uninstall does not call 
BJ> stop.
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/05/26 20:53
BJ> Subject:        Re: [osgi-dev] Q on Bundle#uninstall()
BJ> Sent by:        [email protected]
BJ> 
BJ> 
BJ> 
BJ> Hi BJ,
BJ> 
BJ> On Thu, 26 May 2011 18:46:25 -0400
BJ> BJ Hargrave <[email protected]> wrote:
BJ> 
BJ> BJ> No. If stop completes with an exception, uninstall can still proceed. 
BJ> BJ> Uninstall can fail if the state change lock is held by another thread 
BJ> and 
BJ> BJ> that thread does not release the lock in some reasonable time.
BJ> 
BJ> Spec says:
BJ> -- quote -------------------------------------------------------
BJ> public void stop( int options ) throws BundleException
BJ> 
BJ> 2 If this bundle is in the process of being activated or deactivated then 
BJ> this
BJ> method must wait for activation or deactivation to complete before 
BJ> continuing.
BJ> If this does not occur in a reasonable time, a BundleException is
BJ> thrown to indicate this bundle was unable to be stopped.
BJ> 
BJ> -- quote -------------------------------------------------------
BJ> 
BJ> It seems to me there exists two cases:
BJ> 
BJ> Case1: Bundle.stop() throws BundleException due to the above reason.
BJ>       (Bundle#uninstall() does not throw BundleException)
BJ> 
BJ> Case2: the state change lock is held by another thread and 
BJ>       that thread does not release the lock in some reasonable time. 
BJ>       (Bundle#uninstall() throws BundleException)
BJ> 
BJ> Q1. Does Case2 include Case1 or not ?
BJ> 
BJ> For me, yes.
BJ> 
BJ> Q2. when should those check for Case2 be done in the following steps
BJ> described in "6.1.4.35 public void uninstall( )"
BJ> 
BJ> --begin quote---
BJ> The following steps are required to uninstall a bundle:
BJ> 1 If this bundle’s state is UNINSTALLED then an IllegalStateException is
BJ> thrown.
BJ> 2 If this bundle’s state is ACTIVE, STARTING or STOPPING, this bundle is
BJ> stopped as described in the Bundle.stop method. If Bundle.stop throws
BJ> an exception, a Framework event of type FrameworkEvent.ERROR is
BJ> fired containing the exception.
BJ> 3 This bundle’s state is set to UNINSTALLED.
BJ> 4 A bundle event of type BundleEvent.UNINSTALLED is fired.
BJ> 5 This bundle and any persistent storage area provided for this bundle by
BJ> the Framework are removed.
BJ> --end quote---
BJ> 
BJ> Q3. Even in Case2, step 3-5 should be done. Is my understanding correct ?
BJ> 
BJ> =======
BJ> Ikuo YAMASAKI
BJ> 
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

Reply via email to