design
design copied to clipboard
osgi
rfc-183 Cloud Scope for preferences
Comment author: @juergen-albert
In a cluster/cloud globally available preferences become necessary. These can be used to e.g. configure database connections that are available to everybody in the cloud.
It might also be nice to provide a kind of filter mechanisms, so I can add a property and make sure, that is only visible to nodes with a certain tag. This can e.g. be useful if we have a cluster providing services to different tenets. So you can make sure, that the preferences are only available on nodes, the tenet is allowed to use and don't and on the node used by somebody else.
Comment author: @tverbele
It actually is possible to attach other, custom properties to a NodeStatus service, however currently only by creating your own NodeStatus provider implementation that has those properties.
Question is whether we need a mechanism that any bundle can add properties to a NodeStatus service, or whether this bundle just needs to publish his own NodeStatus service with the (extra) properties he wants to publish?
Filtering is hard - if not impossible? - to include in the spec. You can probably provide your own filtering mechanism using service hooks that hide certain NodeStatus services for other tenants.
Comment author: @maho7791
This bug is related to the PreferenceService. There are currently two scopes defined, system and user. I think what Juergen meant, was to introduce another scope 'cloud', two store cloud related preferences.
This could also mean to have a different storage for these kinds of preferences.
Comment author: @juergen-albert
As discussed: We have to take a closer look in the OSGi Preferences Service. We obviously messed this up with the Eclipse Preferences Service. Thus a Cloud Preference Service appears to be an RFP in and of itself.
Comment author: Castro B <[email protected]>
Hi Jürgen Albert is this issue has been solve already? about the SYSTEM and user.
Castro B, http://webtrafficgeeks.org
Comment author: @juergen-albert
@ Castor B No, we never took a deeper look into this topic.