Hi BJ, On Mon, 9 May 2011 08:27:16 -0400 BJ Hargrave <[email protected]> wrote:
BJ> This is a moot discussion since PackageAdmin is deprecated and we will not BJ> be changing it. So I don't see a lot of value in continuing to discuss BJ> potential changes to a spec we are not going to change. I got it. BJ> BJ> > BJ> If it is STOPPING, then Bundle.stop has been called and it will BJ> > BJ> soon be RESOLVED. BJ> > BJ> > Regarding STOPPING, there is no guarantee that Bundle.stop() returns BJ> BEFORE BJ> > Step3. If not , the state is still STOPPING in Step3 and it will be out BJ> > of scope for the refresh operation. BJ> BJ> Framework's generally maintain "state change" locks on bundles. A bundle BJ> in STOPPING state is changing state and the framework will then hold the BJ> state change lock. So the refresh thread will need to obtain that lock and BJ> will wait for the stop to complete. I understand. BJ> > Therefore, even if STOPPING, Bundle.stop() should be called explicitly BJ> > and if the Exception thrown FrameworkEvent should be fired. BJ> > BJ> > ----------------------- BJ> > >> 2 Each bundle in the graph that is in the STARTING, ACTIVE, or BJ> > STOPPING state will be stopped as described in the Bundle.stop BJ> > method. BJ> > BJ> > 3 Each bundle in the graph that is in the RESOLVED state is unresolved BJ> > and thus moved to the INSTALLED state. The effect of this step is that BJ> > bundles in the graph are no longer RESOLVED. BJ> > ----------------------- BJ> > BJ> > BJ> BJ> > BJ> If, during refresh, a started bundle is stopped but does not BJ> > transition to BJ> > BJ> RESOLVED (this could be due to an error in the activator because it BJ> > BJ> hangs), this is a corner case. A case could be made that we fail the BJ> BJ> > BJ> refresh. But I would say the bundle's activator is in error and that BJ> the BJ> > BJ> refresh proceeds. This is like stopping a bundle. When Bundle.stop BJ> is BJ> > BJ> called, errors in the activator do not prevent the framework from BJ> moving BJ> > BJ> the bundle to the RESOLVED state. BJ> > BJ> > So I would say: BJ> > BJ> > ------- BJ> > For any exceptions that are thrown during any of these steps, a BJ> > FrameworkEvent of type ERROR is fired containing the exception. BJ> > BJ> > >> For any exceptions that are thrown during any of these steps, a BJ> > FrameworkEvent of type ERROR is fired containing the exception after BJ> > completion of the remaining steps. BJ> > ------- BJ> BJ> Why does the event have to fired at the end? It could be fired BJ> immediately. I understand. Thank you for your help indeed. ======= Ikuo YAMASAKI _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
