Details
-
Type:
Improvement
-
Status:
Open
-
Priority:
Major
-
Resolution: Unresolved
-
Affects Version/s: 0.0.1
-
Fix Version/s: None
-
Component/s: Preferences Provider
-
Labels:None
Description
The Preferences based storage implementation can't handle unavailability of the Preferences service at startup. In addition I assume that when another higher ranking Preferences service came along the service would simple switch persistence store in the middle of operation.
I suggest using an adapter approach where a StorageProvider will be registered for either one or each
available Preferences service and let it bind to that service lifecycle. This makes things more robust as it wont fail when the Preferences service is registered at a later time or when multiple Preferences services are around.
My preference would be to adapt to each as it makes the least assumptions on the environment. I'll can work out a patch. WDYT?

Sounds good. I never got time to work more on the dynamic behaviour. Feel free to add what's missing