Why not split this in 2 trackers? One for the start/stop and one for the Extender?
<soapbox>
The start/stop state of a bundle is singleton, you can only use it once. These
methods are uniquely reserved for the management agent (MA). Once you get in
scenarios where the start/stop is abused by others than the central singleton
management agent you create a hard to manage system since now the start/stop
state of a bundle gets different meanings. To keep things simple, the MA
controls start/stop, an extender ONLY reacts on ACTIVE bundles. E.g. in your
case you indicate that you're interested only in bundles with a given header.
By using the start/stop method you make it impossible for anybody else to use
start/stop reliably because it will interfere with these 'special' bundles.
I know how attractive it is to abuse the start/stop methods but every time I've
used it or seen it used people regret it because it is a singleton and later
find out their way is not compatible with other people's way. Look at the awful
model Eclipse has with not starting their bundles. You just create self
inflicted pain.
KISS!
</soapbox>
Kind regards,
Peter Kriens
On 1 okt. 2014, at 02:24, Tim Diekmann <[email protected]> wrote:
> Hi,
>
> I’m looking for a solution, but cannot come up with one. Here is the scenario:
>
> I have a BundleTracker to track bundles with a certain header, i.e.
> implementing an extender. The extender is interested in
> RESOLVED|STARTING|ACTIVE|STOPPING.
>
> When a bundle is installed, but not started, the addingBundle() is called and
> the extender processes the bundle. Now, I want to start the bundle based on
> whether it is configured to be started or not, i.e. I am looking at CM
> configuration to determine whether to start the bundle or not.
>
> Now, here’s the problem: You cannot start the bundle in the callback of
> BundleTrackerCustomizer.addingBundle().
> If you do, the bundle will start, but your Tracker will not receive any
> events for the Bundle, since it hasn’t returned yet from the addingBundle()
> callback to indicate interest in the Bundle.
> What I need here is to be able to return from the addingBundle() callback to
> indicate interest and then trigger the start of the Bundle.
>
> How do I do that?
>
> This is event driven. The callback to addingBundle() is the main event. Now,
> I need another event that the bundle is tracked in order to trigger the start
> such that the same extender BundleTrackerCustomizer starts receiving the
> events for the start of the Bundle.
>
> Any ideas, anyone?
>
> Thanks,
>
> Tim.
>
> P.S: I doubt that setting the start level would help here. Since the
> BundleTrackerCustomizer.addingBundle() call hasn’t returned yet, it will not
> receive any events for the Bundle. Even if the start level is changed by
> another thread, there is no guarantee that the BundleTracker returns before
> the start level thread starts the bundle.
> _______________________________________________
> OSGi Developer Mail List
> [email protected]
> https://mail.osgi.org/mailman/listinfo/osgi-dev
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
