Re: [osgi-dev] The whiteboard pattern for resource-only bundles?

[list+org.osgi]

Hello!

On 2017-04-10T08:58:45 +0100
Timothy Ward  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

Re: [osgi-dev] The whiteboard pattern for resource-only bundles?

[Timothy Ward]

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, list+org.o...@io7m.com wrote:
> 
> On 2017-04-08T18:28:07 +
> elias vasylenko  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
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev

___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] The whiteboard pattern for resource-only bundles?

[list+org . osgi]

On 2017-04-08T18:28:07 +
elias vasylenko  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?

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?

M


pgpN0fuO_7Ich.pgp
Description: OpenPGP digital signature
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] The whiteboard pattern for resource-only bundles?

[list+org . osgi]

On 2017-04-08T18:28:07 +
elias vasylenko  wrote:

> This is absolutely possible!
> 
> Look into the OSGi extender model for the general mechanisms.
> 

Interesting! I'll take a look at this. Thanks!

M


pgpgA3VI64gr_.pgp
Description: OpenPGP digital signature
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] The whiteboard pattern for resource-only bundles?

[elias vasylenko]

This is absolutely possible!

Look into the OSGi extender model for the general mechanisms.

It sounds like you want to create an extender which registers services on
behalf of your resource bundles. Resource bundles only have to have a
manifest entry advertising that they wish to be processed by your extender,
and the system will hand them to you for processing. You can then put your
resources in these bundles along with enough meta-data to describe how
those resources should be handled, then have the extender figure out what
to do with them.

For an example of an extender which performs a similar function you can
look at the enRoute web server extender, which automatically publishes
static resources as web resources with no code required.

On Sat, 8 Apr 2017 at 19:08  wrote:

> Hello.
>
> As I've previously explained, I'm developing a game and am using OSGi
> as the foundation. We want to encourage third-party additions to the
> game and are therefore publishing APIs and building the whole thing as
> a plugin/service-based architecture from the beginning.
>
> Some plugin bundles will contain executable code, but others may not
> contain any. Examples of bundles that probably won't contain code
> are bundles containing game data such as sets of audio files, sets
> of graphics files, level data, etc. Regardless of whether or not a
> bundle contains executable code, I want it to be able to participate in
> all of the things that make OSGi great: Proper versioning, dynamic
> loading/unloading, and so on. It's not clear to me how I can achieve
> this though; it seems like I'd need each bundle to unconditionally
> include some compiled code, the only purpose of which is to provide
> something that can register itself as a service in order to participate
> in something like the whiteboard pattern.
>
> Consider something like an audio "theme" for a user interface. The game
> might define an API like:
>
>   interface SoundThemeType
>   {
> AudioStream buttonClicked();
>
> AudioStream scrollUp();
>
> AudioStream scrollDown();
>
> AudioStream alert();
>   }
>
> A bundle that provided a set of sounds comprising a new theme for the
> user interface would then have to provide an implementation like:
>
>   @Component
>   public final class ExampleSoundTheme implements SoundThemeType
>   {
> public AudioStream buttonClicked()
> {
>   // Return an audio stream from the bundle's own resources...
> }
>
> ...
>   }
>
> No doubt the actual implementation of the ExampleSoundTheme type could
> be pushed up into an abstract superclass and provided by the game
> itself, so the implementation in the bundle would end up being
> something trivial like:
>
>   @Component
>   public final class ExampleSoundTheme extends AbstractSoundTheme
>   {
> public AudioStream buttonClicked()
> {
>   return super.sound("/button_clicked.wav");
> }
>
> ...
>   }
>
> However, as trivial as the above could be, it still requires an editing
> tool to compile some Java code and include it into a bundle. This means
> that non-technical users that just want to make a simple sound theme
> have to be exposed to code (even if just indirectly). It would be much
> nicer if those users could simply create a file, let's call it
> "theme.txt" that looked something like:
>
>   buttonClicked: /button_clicked.wav
>   scrollUp: /scroll_up.wav
>   scrollDown: /scroll_down.wav
>   alert: /boom.wav
>
> ... and the editing tool would insert information in the OSGi manifest
> that would, when the bundle is loaded into the game, result in an
> implementation of the SoundThemeType API being created and registered
> as a service using the given theme.txt file as a data source. To
> reiterate: The bundle just contains theme.txt, a few .wav files, and
> obviously an OSGi manifest. No compiled code.
>
> Is there some way I can achieve this pleasantly?
>
> M
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] The whiteboard pattern for resource-only bundles?

[list+org . osgi]

On 2017-04-08T18:07:59 +
list+org.o...@io7m.com wrote:
> 
> ... and the editing tool would insert information in the OSGi manifest
> that would, when the bundle is loaded into the game, result in an
> implementation of the SoundThemeType API being created and registered
> as a service using the given theme.txt file as a data source.

Sorry, that should have read "result in an implementation of the
SoundThemeType API being *instantiated*"... I realize that "created" in
this case could have several meanings.

M


pgpxMu6WiQFpV.pgp
Description: OpenPGP digital signature
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev