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
<<inline: graycol.gif>>
<<inline: ecblank.gif>>
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
