Hi Tomek (and/or whoever else), I’ve put a PR together at [0]. This includes changes defined in another PR [1] which is still awaiting review. The new PR covers the implementation of the CompositeDataStoreService etc. All it is doing at this point is responding to service and delegate activations and mapping the delegates into the CompositeDataStore itself. It isn’t actually behaving as a data store yet.
Please let me know if this is heading the direction you recommended and what changes need to be made. [0] - https://github.com/apache/jackrabbit-oak/pull/74 [1] - https://github.com/apache/jackrabbit-oak/pull/71 -MR On October 26, 2017 at 5:39:29 AM, Tomek Rekawek ([email protected]) wrote: Hi Matt, > On 24 Oct 2017, at 21:54, Matt Ryan <[email protected]> wrote: > It is still unclear to me how this works in terms of configuration files, > and how this would work for the CompositeDataStore. This is how I believe > it would work for two FileDataStores in the composite: > > FDS config 1: > > path=datastore/ds1 > role=local1 > > FDS config 2: > > path=datastore/ds2 > role=local2 > > CompositeDataStore config: > > local1:readOnly=false > local2:readOnly=true > > Something like that anyway. Yes, I’d see something like this too. > My questions then are: How do we store both FileDataStore configuration > files when both have the same PID? What is the file name for each one? > And how to do they associate with the FileDataStoreFactory? For the factory services we use suffixes for the config files: org.apache.jackrabbit.oak.plugins.blob.datastore.FileDataStoreFactory-local1.cfg org.apache.jackrabbit.oak.plugins.blob.datastore.FileDataStoreFactory-local2.cfg org.apache.jackrabbit.oak.plugins.blob.datastore.FileDataStoreFactory-other.cfg OSGi knows that the […].FileDataStoreFactory is a factory and creates as many instances as needed, binding the provided configurations. Regards, Tomek -- Tomek Rękawek | Adobe Research | www.adobe.com [email protected]
