> > because services from lazy activated bundles are available prior
to being started
>
> Technically that is not true. Services from lazy activated bundles
> are available prior to being *activated* but the bundle must have
> been started. That is, not in RESOLVED state; STARTING or ACTIVE.
This is just me mixing up the bundle lifecycle terminology.
By "started" I meant "active" (i.e., the state that
comes after "starting"). I guess there is a different meaning
to the term "started" in OSGi that I wasn't aware of. Thanks
for clarifying.
> > Since the bundle providing the extension is STARTED at this point,
> > and all other lazy activated bundles are STARTING
>
> This sounds like a start ordering issue. Since extensions are active
> in the RESOLVED state, the system will need to be configured such
> that all bundles which will use extension to access services are
> started before they will ever attempt to access the service.
Extensions are present in the extension registry in
the RESOLVED state, but an executable extension will only start to use
services once it has been instantiated. I'm assuming that bundles are lazy-activated
here and at the time the extension class is instantiated the bundle is
active. In any case, there may indeed be lifecycle issues here but I think
I need to play around some more with combining extensions and DS to see
if there is a problem.