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:
@Component( properties=“theme.txt”)
public final class ExampleSoundTheme extends AbstractSoundTheme implements
SoundThemeType
{
@interface Config {
String buttonClicked();
String scrollUp();
String scrollDown();
String alert();
}
private Config config;
@Activate
public void start(Config config) {
this.config = config;
}
public AudioStream buttonClicked()
{
return super.sound(config.buttonClicked());
}
...
}
Users can simply include this component (using Private-Package) and name their
properties file appropriately (theme.txt). Job done!
Regards,
Tim
> On 10 Apr 2017, at 08:07, [email protected] wrote:
>
> On 2017-04-08T18:28:07 +0000
> elias vasylenko <[email protected]> wrote:
>
>> This is absolutely possible!
>>
>> Look into the OSGi extender model for the general mechanisms.
>>
>
> Couple of small things with this:
>
> Everything I've read suggests that I need to use the standard
> BundleTracker:
>
> https://osgi.org/javadoc/r6/core/org/osgi/util/tracker/BundleTracker.html
>
> 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.
>
> 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.
Regards,
Tim
>
> M
> _______________________________________________
> OSGi Developer Mail List
> [email protected]
> https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
