[
https://issues.apache.org/jira/browse/OAK-6312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16042522#comment-16042522
]
Chetan Mehrotra edited comment on OAK-6312 at 6/8/17 10:32 AM:
---------------------------------------------------------------
bq. Is there any additional documentation we can follow or we should just be
familiar with OAK-6210? Thanks!
[~arkadius] For now its just the code checked in under OAK-6210. Regarding this
issue having a concise config would be nice. Just sharing my thoughts regarding
this topic.
In JR2 we used to have a nice jackrabbit.xml which allows to provide the whole
repository setup in file. That worked fine for basic cases but starts posing
problem when you need to support extensions as it started becoming like a
static service registry.
With switch to OSGi this setup become lot more dynamic and role of
jackrabbit.xml was replaced with bunch of OSGi config and Declarative Services
(DS via Felix SCR). Now as you mentioned this posses some problem and make
setup bit fragile.
I faced similar issue when trying to support use of Oak outside of OSGi
container setups i.e. standalone java programs. This was solved to some extent
via oak-pojosr [1] which allowed to express all the config in a single json
file and used Felix Connect for setting up Oak without requiring the app to run
in OSGi container and this works nicely. For e.g. standalone example [2] uses
this approach to configure Oak in Spring Boot based application.
The approach used in OAK-6210 is very much limited as its only meant to
instantiate the objects required for tooling. So it does the whole setup
programatically. But that approach would not be good fit for case like full
application setup as lots of services in Oak are now instantiated via DS
One way out would be to have a component which consumes this file and then maps
it to OSGi config and creates the required config using ConfigurationAdmin API.
But then that would pose a problem of keeping the 2 in sync
[1] https://github.com/apache/jackrabbit-oak/tree/trunk/oak-pojosr
[2] https://github.com/apache/jackrabbit-oak/tree/trunk/oak-examples/standalone
was (Author: chetanm):
bq. Is there any additional documentation we can follow or we should just be
familiar with OAK-6210? Thanks!
[~arkadius] For now its just the code checked in under OAK-6210. Regarding this
issue having a concise config would be nice. Just sharing my thoughts regarding
this topic.
In JR2 we used to have a nice jackrabbit.xml which allows to provide the whole
repository setup in file. That worked fine for basic cases but starts posing
problem when you need to support extensions as it started becoming like a
static service registry.
With switch to OSGi this setup become lot more dynamic and role of
jackrabbit.xml was replaced with bunch of OSGi config and Declarative Services
(DS via Felix SCR). Now as you mentioned this posses some problem and make
setup bit fragile.
I faced similar issue when trying to support use of Oak outside of OSGi
container setups i.e. standalone java programs. This was solved to some extent
via oak-pojosr [1] which allowed to express all the config in a single json
file and used Felix Connect for setting up Oak without requiring the app to run
in OSGi container and this works nicely. For e.g. standalone example [2] uses
this approach to configure Oak in Spring Boot based application.
The approach used in OAK-6210 is very much limited as its only meant to
instantiate the objects required for tooling. So it does the whole setup
programatically. But that approach would not be good fit for case like full
application setup as lots of services in Oak are now instantiated via DS
[1] https://github.com/apache/jackrabbit-oak/tree/trunk/oak-pojosr
[2] https://github.com/apache/jackrabbit-oak/tree/trunk/oak-examples/standalone
> Unify NodeStore/DataStore configurations
> ----------------------------------------
>
> Key: OAK-6312
> URL: https://issues.apache.org/jira/browse/OAK-6312
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: blob, blob-plugins, composite, documentmk, rdbmk,
> segment-tar
> Reporter: Arek Kita
> Fix For: 1.8
>
>
> I've noticed recently that with many different NodeStore
> implementation (Segment, Document, Composite) but also DataStore
> implementation (File, S3, Azure) and some composite ones like
> (Hierarchical, Federated) it
> becomes more and more difficult to set up everything correctly and be
> able to know the current persistence state of repository (especially
> with pretty aged repos). The factory code/required options are more complex
> not only from user perspective but also from maintenance point.
> We should have the same means of *describing* layouts of Oak repository no
> matter if it is simple or more layered/composite instance.
> Some work has already been done in scope of OAK-6210 so I guess we have good
> foundations to continue working in that direction.
> /cc [~mattvryan], [~chetanm]
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
