On 2017-04-10T08:58:45 +0100
Timothy Ward <tim.w...@paremus.com> wrote:

> Hi,
> I’ve answered your specific questions about BundleTracker inline, so feel 
> free to skip ahead, but it would also be perfectly possible to define a 
> reusable DS component (as described in your initial email) without requiring 
> code from the user.
> If the core game library contains a suitably written DS component that uses 
> its component properties to discover the resources (as declared by a 
> properties file) then you can get the behaviour that you want by having the 
> user write said properties file and include the DS component inside their 
> bundle. The DS component can be very simple:

Thanks, I'll keep this one in mind. Going to be writing a few
experiments over the next week or so, and this will be one of them.
I'm leaning on DS as heavily as possible in general, but I assumed that
I'd need to fall back to the OSGi APIs for this particular case.

> > 1. I can't be sure that my BundleTracker will be started up before any
> > resource bundles are loaded (because the order of bundle and service
> > startup is obviously undefined). What happens to those resource bundles
> > that happened to be loaded before the service that processes them has
> > started?  
> The extender isn’t a service (which has a specific meaning in an OSGi 
> system), but rather a bundle. When the extender bundle is started its 
> activator start method will be called (or its component activation method if 
> you choose to implement this using DS). At that point you create and start a 
> BundleTracker, which will immediately get a callback for every existing 
> bundle that is in an “interesting state” (as defined by the constructor args 
> of the BundleTracker). You will also get callbacks in the future for every 
> state change that moves a bundle into/out of an “interesting state”. Note 
> that these callbacks may occur on a different thread.

By service, I actually meant the bit of code that's responsible for
creating a BundleTracker. I assumed that the extender bundle would
register a service in the activator but I see now that it doesn't
actually need to, it just needs to open/close a tracker.

> > 2. What happens if the bundle containing the BundleTracker is
> > restarted/reinstalled? The BundleTrackerCustomizer interface only seems
> > to communicate state changes (bundle was added, bundle was modified,
> > bundle was removed). Will I be notified of bundles that are already
> > loaded and haven’t changed?  
> See above - the bundle tracker will tell you about the state of the universe 
> at the time it starts up, and then every subsequent change. This is why it’s 
> important to both close your bundle tracker when the bundle/component 
> stops/deactivates *and* to clean up in the removedBundle method. The 
> removedBundle method will get called for everything that you’re tracking when 
> the BundleTracker is closed, making it easy to clean up properly.

Ah, I see. If I understand correctly, I'll receive a "bundle added"
call for any bundles that are already loaded when the tracker starts up?
If so, that would seem to eliminate the race condition above (where a
bundle is loaded before the extender bundle has started up).


Attachment: pgpINljHZlZkd.pgp
Description: OpenPGP digital signature

OSGi Developer Mail List

Reply via email to