> Agreed, but how about this tangent : Allow extenders to hook into
> the Bundle.adapt(Class) method to expose extend state which then may
> expose extender information related to the bundle ?
>
> (Yes this is still requirements gathering, but I had to write down
> this idea flying through my head ;-) )
>
> This is precisely why I was against the adapt() method ever being
> added to the spec in the first place since it creates a secondary
> registry of service-like objects. Why not just have an extender
> register a service that has a getMoreInfo(Bundle) method on it? :-)
>
> -> richard
Nobody gets to "hook" into adapt. That is for the framework only. Bundles
can provide services. That is what service are for.
This thread needs to stop proposing design ideas and back up to
requirements. And not requirements which are design choices ("framework
must allow hooking into bundle life cycle").
As has been pointed out, we cannot change the state diagram of bundles. We
are talking about things (e.g. components) whose life cycle is contained
within a bundle's life cycle and managed by extender bundles.
So having a standard service that extenders provide that can be used to
interrogate the status of any entities in a bundle managed by the extender
could be useful. (It is not clear that all extender models can be
supported by a single service design given the many extenders and their
varying features.)
--
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
