Started means Bundle.start was called. So the bundle may be STARTING or 
ACTIVE. If it is STOPPING, then Bundle.stop has been called and it will 
soon be RESOLVED.

If, during refresh, a started bundle is stopped but does not transition to 
RESOLVED (this could be due to an error in the activator because it 
hangs), this is a corner case. A case could be made that we fail the 
refresh. But I would say the bundle's activator is in error and that the 
refresh proceeds. This is like stopping a bundle. When Bundle.stop is 
called, errors in the activator do not prevent the framework from moving 
the bundle to the RESOLVED state.
-- 

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:   Ikuo Yamasaki <[email protected]>
To:     OSGi Developer Mail List <[email protected]>
Date:   2011/05/07 08:55
Subject:        Re: [osgi-dev] Re: Q on PackageAdmin#refreshPackages()
Sent by:        [email protected]



Hi BJ,

On Fri, 6 May 2011 22:31:46 -0400
BJ Hargrave <[email protected]> wrote:

BJ> Yes. Since PackageAdmin has been deprecated and replace by the Bundle 
BJ> Wiring API, we will not be updating PackageAdmin any more.

Got it.

BJ> You list 2 suggested changes below. The first one should be to replace 

BJ> ACTIVE with the more general term "started" which can include lazy 
BJ> activated bundles in the STARTING state. 

I'm confused a little bit .

For me, 
a. "started" means "in the state of ACTIVE". 
b. a lazy activated bundle can be in the STARTING state.

Therefore the following description covers all.

>> 2 Each bundle in the graph that is in the state of STARTING, ACTIVE
  or STOPPING will be stopped as described in the Bundle.stop method.

(I had miswritten "STARTING, ACTIVE or" instead of "STARTING, ACTIVE or
STOPPING")

BJ> The second one is incorrect: the 
BJ> remaining steps will not be ignored. That is why it is not a numbered 
list 
BJ> item.

That is different from what Richard wrote:
Richard> Either the refresh operation will end up waiting for B to become 
active 
Richard> before stopping it and refreshing it or the entire refresh 
operation 
Richard> will fail because B couldn't be stopped.

Which is expected ? or it might depend on the implementation because the
spec is ambiguous.

Best regards,

Ikuo


=======
Ikuo YAMASAKI


_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev

_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev

Reply via email to