Hi BJ,
Thank you for your correction. My description is not correct. Bundle.uninstall from the current thread: --> The operation should be failure. Bundle.uninstall from the another thread: 1. When the status of the bundle which is called Bundle.uninstall is changed in reasonable waiting time. --> The operation will succeed. 2. When the status of the bundle which is called Bundle.uninstall is NOT changed (remaining in STARTING) in reasonable waiting time. --> The operation should be failure. Best regards, Shigekuni Kondo On Mon, 9 Jul 2012 08:26:10 -0400 BJ Hargrave <[email protected]> wrote: > It is certainly a failure from the current thread (that is, the thread > which is activating the bundle). It can succeed from another thread if the > framework impl is willing to wait a while to see if the current state > change operation completes. > > -- > > 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: Shigekuni Kondo <[email protected]> > To: OSGi Developer Mail List <[email protected]>, > Date: 2012/07/08 21:04 > Subject: Re[2]: [osgi-dev] Q of Bundle.start(int) process > Sent by: [email protected] > > > > Hi Tom, > > > Thank you very much for your replying. > I'm sorry my reply is late. > # I took holidays in the last week. > > I got it. > I think that the operation in your reply makes sense. > > The Bundle.uninstall for the bundle whose state is STARTING > should be failure (thrown BundleException) regardless of whether > the caller thread is same thread or another. > > > Best regards, > > Shigekuni Kondo > > > > On Fri, 29 Jun 2012 07:58:47 -0500 > Thomas Watson <[email protected]> wrote: > > > > > I'm not sure how other frameworks behave, but Equinox will not allow a > > bundle to uninstall itself while the framework is calling the > > BundleActivator.start. A BundleException of type STATECHANGE_ERROR > would > > be thrown from Bundle.uninstall and the state of the bundle would remain > in > > the STARTING state. If the exception was caught and ignored by the > > BundleActivator.start method then the bundle activation would success > and > > the state would transition to ACTIVE. If the exception was not caught > then > > the start would fail and the state would transition to > STOPPING->RESOLVED. > > > > I don't think this is spelled out clearly in the specification, but I > think > > it is reasonable given the fact that the state transition lock for the > > bundle cannot be successfully obtained in order to proceed with the > > uninstall operation. > > > > Tom > > > > > > > > > > > > From: Shigekuni Kondo <[email protected]> > > > > To: OSGi Developer Mail List <[email protected]>, > > > > > Date: 06/29/2012 01:55 AM > > > > Subject: [osgi-dev] Q of Bundle.start(int) process > > > > > > > > > > > > > > Hi OSGi Experts, > > > > > > I have a question of Bundle.start(int) process. > > > > [Condition] > > BundleA: > > Bundle.uninstall() for own bundle is called in BundleActiovator.start > > (context). > > ------------ > > public class Activator implements BundleActivator { > > public void start(BundleContext context) throws Exception { > > context.getBundle().uninstall(); > > } > > ... > > } > > ------------- > > # I know that this bundle has no meaning... > > > > > > [Question] > > When Bundle.start() for BundleA is called, how should > > the framework handle it? > > > > > > As far as I checked the core spec (R4.3), my understanding is as below. > > --- > > 0. The BundleA's state is INSTALLED. > > 1. BundleA.start() is called. > > 2. The state of BundleA is set to RESOLVED (and BundleEvent.RESOLVED > > is fired). > > # In this case, BundleA can be resolved. > > 3. The state of BundleA is set to STARTING (and BundleEvent.STARTING > > is fired). > > 4. BundleA.uninstall() is called in BundleActiovator.start(context). > > 5. The framework tries to stop BundleA, but it fails (throws an > > exception) because BundleA's state is kept STARTING. > > 6. The framework fires FrameworkEvent.ERROR, however it doesn't throw > > BundleException. > > 7. The state of BundleA is set to UNINSTALLED (and > BundleEvent.UNINSTALLED > > is fired). > > 8. BundleA.uninstall() is returned. > > 9. BundleException is thrown because BundleA was uninstalled while > > the BundleActivator.start() was running. > > 10.BundleA.start() fails. > > --- > > > > In the above case, the BundleA's state is changed STARTING to > > UNINSTALLED in process of BundleA.start(). > > However, OSGi core spec doesn't permit such status change > > (4.4.2 Bundle State). > > > > > > Best regards, > > > > Shigekuni Kondo > > > > _____________________________________________ > > > > Shigekuni Kondo > > > > Promotion Project 1 > > NTT Cyber Solutions Laboratories > > NIPPON TELEGRAPH AND TELEPHONE CORPORATION > > > > 1-1 Hikarinooka Yokosuka > > Kanagawa 239-0847 Japan > > TEL:+81-46-859-3444 > > FAX:+81-46-855-1282 > > E-mail:[email protected] > > _____________________________________________ > > > > > > > > _______________________________________________ > > OSGi Developer Mail List > > [email protected] > > https://mail.osgi.org/mailman/listinfo/osgi-dev > > > > > > _____________________________________________ > > Shigekuni Kondo > > Promotion Project 1 > NTT Cyber Solutions Laboratories > NIPPON TELEGRAPH AND TELEPHONE CORPORATION > > 1-1 Hikarinooka Yokosuka > Kanagawa 239-0847 Japan > TEL:+81-46-859-3444 > FAX:+81-46-855-1282 > E-mail:[email protected] > _____________________________________________ > > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > > _____________________________________________ Shigekuni Kondo Promotion Project 1 NTT Cyber Solutions Laboratories NIPPON TELEGRAPH AND TELEPHONE CORPORATION 1-1 Hikarinooka Yokosuka Kanagawa 239-0847 Japan TEL:+81-46-859-3444 FAX:+81-46-855-1282 E-mail:[email protected] _____________________________________________ _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
