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