Hello! 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). M
pgpINljHZlZkd.pgp
Description: OpenPGP digital signature
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
