Hi Tomek, Thanks for the feedback. I hadn’t thought about it this way, so I’ll consider it further.
Some concerns listed below. On October 3, 2017 at 12:35:32 AM, Tomek Rekawek ([email protected]) wrote: Hello Matt, I don’t think we should rely on the bundle activation / deactivation, but rather on the service registration / reregistration. OSGi allows to use MANDATORY_MULTIPLE cardinality for a @Reference - in this case, the service consumer will be informed every time there is a new service implementing given interface. Then, if the CompositeDataStoreService thinks that all the required partial data stores are there, it can register itself as a BlobStore, using BundleContext#registerService. Also, we probably need some kind of differentiation between “partial” and the “final” datastore (so the node store won’t pick the first one). For the node stores, we introduced a new property “role”. If the node store service is configured with this property in place, it registers a NodeStoreProvider rather than NodeStore (so we are sure the partial node store is not used directly). So, my idea is as follows: 1. Create new BlobStoreProvider interface, with just one method: getBlobStore(). 2. Modify all the existing blob store services adding them an optional “role” property (any string). One concern I have with this approach is that if we want a data store to be usable as a CompositeDataStore delegate, that data store has to make specific provisions to do this. My thinking was that it would be preferable to have the CompositeDataStore contain as much of the logic as possible. Ideally a data store should work as a delegate without having to make any changes to the data store itself. (Not sure if we can achieve this, but…) 3. If the data store service is configured with this role, it should register the BlobStoreProvider service rather than a normal BlobStore. 4. The CompositeDataStoreService should be configured with a list of blob store roles it should wait for. 5. The CompositeDataStoreService has a MANDATORY_MULTIPLE @Reference of type BlobStoreProvider. 6. Once (a) the CompositeDataStoreService is activated and (b) all the blob store providers are there, it’ll register a BlobStore service, which will be picked up by the node store. I have concerns about this part also. Which blob store providers should the CompositeDataStoreService wait for? For example, should it wait for S3DataStore? If yes, and if the installation doesn’t use the S3 connector, that provider will never show up, and therefore the CompositeDataStoreService would never get registered. If it doesn’t wait for S3DataStore but the installation does use S3DataStore, what happens if that bundle is unloaded? Wouldn’t this approach require that every possible data store that can be a blob store provider for the composite be included in each installation that wants to use the CompositeDataStore? Regards, -MR
