You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-dev@jackrabbit.apache.org by Matt Ryan <os...@mvryan.org> on 2017/10/03 22:34:31 UTC

[CompositeDataStore] Configuration format for delegate data stores

Hi,

I’d be interested in ideas on how we should define configuration for
delegate data stores for the CompositeDataStore.

One idea was proposed on-list earlier in [0].  I like this idea, but it is
a unified node-store/data-store configuration concept that might take a bit
longer to support than we want to handle right now, and may be a bit more
invasive than we want to tackle at this stage in the release.

For my POC I did a really simple configuration format, like this:

datastore.1=dataStoreName:FileDataStore,className:org.apache.jackrabbit.oak.plugins.blob.datastore.OakCachingFDS,bundleName:org.apache.jackrabbit.oak-core,path:/Users/maryan/POCs/content_backflow_poc/ds_testing
datastore.2=dataStoreName:FileDataStore,className:org.apache.jackrabbit.oak.plugins.blob.datastore.OakCachingFDS,bundleName:org.apache.jackrabbit.oak-core,path:/Users/maryan/POCs/content_backflow_poc/ds_production,readOnly:true

I admit this is kinda ugly.  Delegates are identified by starting with
“datastore” - the rest of this part of the line is not super relevant other
than to make each key different.  Everything on the right of the “=“ is the
value which gets passed to the service.  The service or the data store
itself has to parse the rest of the string.

The rest of the string is key/value pairs, each pair separated by “,", each
key separated from the value by “:”.  Mostly I’m just indicating the
delegate type, class path (so it can be created by reflection), and bundle
name (so when the bundle changes state we know to take some action).  Note
that this relates to the earlier thread [1] regarding how delegates get
created.

The remainder gets passed to the delegate as configuration options.

This approach isn’t super flexible and is hard to edit and read.  Open to
other ideas.

Thoughts?


[0] - http://oak.markmail.org/thread/zhnntcdxe5jj2rg2
[1] - http://oak.markmail.org/thread/4ouvpitv5zrypiqg


-MR

Re: [CompositeDataStore] Configuration format for delegate data stores

Posted by Robert Munteanu <ro...@apache.org>.
Hi Matt,

On Tue, 2017-10-03 at 18:34 -0400, Matt Ryan wrote:
> Hi,
> 
> I’d be interested in ideas on how we should define configuration for
> delegate data stores for the CompositeDataStore.
> 
> One idea was proposed on-list earlier in [0].  I like this idea, but
> it is
> a unified node-store/data-store configuration concept that might take
> a bit
> longer to support than we want to handle right now, and may be a bit
> more
> invasive than we want to tackle at this stage in the release.
> 
> For my POC I did a really simple configuration format, like this:
> 
> datastore.1=dataStoreName:FileDataStore,className:org.apache.jackrabb
> it.oak.plugins.blob.datastore.OakCachingFDS,bundleName:org.apache.jac
> krabbit.oak-
> core,path:/Users/maryan/POCs/content_backflow_poc/ds_testing
> datastore.2=dataStoreName:FileDataStore,className:org.apache.jackrabb
> it.oak.plugins.blob.datastore.OakCachingFDS,bundleName:org.apache.jac
> krabbit.oak-
> core,path:/Users/maryan/POCs/content_backflow_poc/ds_production,readO
> nly:true

Not a direct comment on the format, but I would advise against passing
class names around, if at all possible. It's prone to class loading
errors, especially in OSGi environments. You would need to get the
right class loader from the originating bundle to make sure everything
aligns correctly. 

I would suggest registering the DataStore instances as OSGi services
with component properties and then looking them up using the Whiteboard
abstraction.

Robert