On Sat, 7 May 2011 09:25:07 -0400
BJ Hargrave <[email protected]> wrote:
BJ> Started means Bundle.start was called. So the bundle may be STARTING or
BJ> ACTIVE.
I understand the meaning of "started".
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.
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.
-------
Best regards,
=======
Ikuo YAMASAKI
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
