[ 
https://issues.apache.org/jira/browse/OAK-4959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15827662#comment-15827662
 ] 

Chetan Mehrotra commented on OAK-4959:
--------------------------------------

bq. does it need to be stored under jcr:system/rep:documentStore/bundlor? and 
if yes, why?

It needs to be stored as content like we store index definitions. From various 
discussion on [oak-dev|http://markmail.org/thread/xzjnzdqqki7girza] it was 
concluded that we should use this path

bq. why does it need to be writeable using JCR API?

Its expected that users can provide there own bundling pattern for there 
nodetype. So they can use the JCR API to add new patterns

bq. is there a reason for not making this an OSGi configuration?

The config is bit complex and hence cannot be easily captured as OSGi config 
(key=value pair). Note that going forward more options would be added and 
having then captured as content provides a good match. This is similar to how 
we define indexing config as repository content. Further its required that 
config is consistently seen on all cluster nodes which cannot be guranteed with 
OSGi config (which can differ between cluster nodes. 

> Review the security aspect of bundling configuration
> ----------------------------------------------------
>
>                 Key: OAK-4959
>                 URL: https://issues.apache.org/jira/browse/OAK-4959
>             Project: Jackrabbit Oak
>          Issue Type: Task
>          Components: documentmk
>            Reporter: Chetan Mehrotra
>            Assignee: Chetan Mehrotra
>              Labels: bundling
>             Fix For: 1.5.18, 1.6
>
>         Attachments: OAK-4959-v1.patch
>
>
> The config for node bundling feature in DocumentNodeStore is currently stored 
> under {{jcr:system/rep:documentStore/bundlor}}. This task is meant to 
> * Review the access control aspect - This config should be only updatetable 
> by system admin
> * Config under here should be writeable via JCR api



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to