[Oak origin/trunk] Apache Jackrabbit Oak matrix - Build # 1229 - Still Failing

[Apache Jenkins Server]

The Apache Jenkins build system has built Apache Jackrabbit Oak matrix (build 
#1229)

Status: Still Failing

Check console output at 
https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/1229/ to view 
the results.

Changes:
[frm] [maven-release-plugin] prepare release oak-segment-tar-0.0.16

[frm] [maven-release-plugin] prepare for next development iteration

[reschke] OAK-4964: UpdateOp.set("_id", ...) should do a sanity check on the id

[thomasm] OAK-4968 Query engine: sort order is calculated multiple times

[frm] OAK-4958 - Improve consistency of NetworkErrorProxy

[frm] OAK-4958 - Decrease the timeout when reading a segment on the primary

[tomekr] OAK-4970: Optimize the version copying performance during sidegrade

[mreutegg] OAK-4973: Speed up tests with MongoFixture

[mreutegg] OAK-4976: AcquireRecoveryLockTest fails occasionally

[tomekr] OAK-4970: Optimize the version copying performance during sidegrade

[chetanm] OAK-4977 - Add ProviderType annotation to MBean interfaces

[reschke] OAK-4964: UpdateOp.set("_id", ...) should do a sanity check on the id

 

Test results:
All tests passed

Re: segment-tar depending on oak-core

[Alex Parvulescu]

I fully agree with what Thomas is saying.
Being on the inside of the segment-tar release cycles I don't really see
the need or the advantages of a decoupled release, it seems it only managed
to separate us even more (we even have a different release email template,
if that was ever needed) without really providing any benefits: there is no
segment-tar without oak-*, no one would expect to be able to just drop in
the latest segment-tar bundle, everyone asks what the *oak* version is that
goes with each segment release, maybe this will change, maybe not, but
that's how it is now. So for me personally, the overhead of the separate
release greatly outweighs the benefits.

> The release process in Oak is a joke. Releasing every two weeks by
using version numbers as counters just for the sake of it is
embarrassing. I don't even know how many releases of our parent POM we
have, every one of them equal to the other, and this is nonsense.

There's a lot of misrepresentation packed into this. First it would be good
to maintain a respectful & objective attitude towards the list. Second, we
release every two weeks from a development branch to reduce the feedback
loop, if something breaks we can catch it early. Releases are unstable and
frequent, I saw no one else complain about this before.
Third, releases are generally cheap, why does it matter how often we
release the parent POM? Are you worried about disk space? Confused
customers? What part of this seems _nonsense_?

I'm all for going forward on the things that matter to the overall project,
but I'm not convinced separate release cycles for all modules is what was
keeping Oak from graduating from 'pet project' level to the big league. I
would rather keep this as simple as it can be for everyone, not just
segment-tar.

best,
alex


On Fri, Oct 21, 2016 at 4:22 PM, Julian Reschke 
wrote:

> On 2016-10-21 16:15, Thomas Mueller wrote:
>
>> Hi,
>>
>> You are sure using many emotional, judgmental words and sentences like
>> "joke", "embarrassing", "nonsense", "We shouldn't go backward, but
>> forward", "pet project", "admit", "level of complexity", "doesn't allow",
>> "dumping grounds". Your whole mail is very judgmental.
>>
>> OK, I see you would like to split everything into tiny, tiny modules.
>>
>> Right now we already have many modules, and using a different release
>> cycle for oak-segment-tar is not a problem.
>>
>> So your solution is to split things into even more modules. I see that, as
>> you seem to be very emotional about that.
>>
>> But I don't agree that's the best solution. I prefer simple solutions,
>> that don't require a lot of bureaucracy and overhead.
>>
>> I see no big value in "being able" to release things independently. In
>> fact I think it's added overhead, with no value.
>>
>> Regards,
>> Thomas
>>
>
> Big +1.
>
> Best regards, Julian
>
>

Re: [VOTE] Release Apache Jackrabbit Oak 1.4.9

[Alex Parvulescu]

 [X] +1 Release this package as Apache Jackrabbit Oak 1.4.9

On Fri, Oct 21, 2016 at 4:03 PM, Davide Giannella  wrote:

>
> A candidate for the Jackrabbit Oak 1.4.9 release is available at:
>
> https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.4.9/
>
> The release candidate is a zip archive of the sources in:
>
>
> https://svn.apache.org/repos/asf/jackrabbit/oak/tags/jackrabbit-oak-1.4.9/
>
> The SHA1 checksum of the archive is
> 3d94e4022d72543ca703295cf623bd97091f2d64.
>
> A staged Maven repository is available for review at:
>
> https://repository.apache.org/
>
> The command for running automated checks against this release candidate is:
>
> $ sh check-release.sh oak 1.4.9 3d94e4022d72543ca703295cf623bd
> 97091f2d64
>
> Please vote on releasing this package as Apache Jackrabbit Oak 1.4.9.
> The vote is open for the next 72 hours and passes if a majority of at
> least three +1 Jackrabbit PMC votes are cast.
>
> [ ] +1 Release this package as Apache Jackrabbit Oak 1.4.9
> [ ] -1 Do not release this package because...
>
> Davide
>

Re: [VOTE] Release Apache Jackrabbit Oak 1.4.9

[Marcel Reutegger]

Hi,

On 21/10/16 16:03, Davide Giannella wrote:

Please vote on releasing this package as Apache Jackrabbit Oak 1.4.9.
The vote is open for the next 72 hours and passes if a majority of at
least three +1 Jackrabbit PMC votes are cast.


All checks OK.

+1 Release this package as Apache Jackrabbit Oak 1.4.9

Regards
 Marcel

Re: [VOTE] Release Apache Jackrabbit Oak 1.4.9

[Julian Reschke]

On 2016-10-21 16:03, Davide Giannella wrote:

...


[X] +1 Release this package as Apache Jackrabbit Oak 1.4.9

Best regards, Julian

Re: segment-tar depending on oak-core

[Thomas Mueller]

>
>and using a different release
>cycle for oak-segment-tar is not a problem.

Sorry, I wanted to write "and using a different release cycle for
oak-segment-tar *created new problems*"

Re: segment-tar depending on oak-core

[Julian Reschke]

On 2016-10-21 16:15, Thomas Mueller wrote:

Hi,

You are sure using many emotional, judgmental words and sentences like
"joke", "embarrassing", "nonsense", "We shouldn't go backward, but
forward", "pet project", "admit", "level of complexity", "doesn't allow",
"dumping grounds". Your whole mail is very judgmental.

OK, I see you would like to split everything into tiny, tiny modules.

Right now we already have many modules, and using a different release
cycle for oak-segment-tar is not a problem.

So your solution is to split things into even more modules. I see that, as
you seem to be very emotional about that.

But I don't agree that's the best solution. I prefer simple solutions,
that don't require a lot of bureaucracy and overhead.

I see no big value in "being able" to release things independently. In
fact I think it's added overhead, with no value.

Regards,
Thomas


Big +1.

Best regards, Julian

Re: segment-tar depending on oak-core

[Thomas Mueller]

Hi,

You are sure using many emotional, judgmental words and sentences like
"joke", "embarrassing", "nonsense", "We shouldn't go backward, but
forward", "pet project", "admit", "level of complexity", "doesn't allow",
"dumping grounds". Your whole mail is very judgmental.

OK, I see you would like to split everything into tiny, tiny modules.

Right now we already have many modules, and using a different release
cycle for oak-segment-tar is not a problem.

So your solution is to split things into even more modules. I see that, as
you seem to be very emotional about that.

But I don't agree that's the best solution. I prefer simple solutions,
that don't require a lot of bureaucracy and overhead.

I see no big value in "being able" to release things independently. In
fact I think it's added overhead, with no value.

Regards,
Thomas


On 21/10/16 15:09, "Francesco Mari"  wrote:

>Luckily for us this is not a computer science problem but an easier
>software engineering concern.
>
>The release process in Oak is a joke. Releasing every two weeks by
>using version numbers as counters just for the sake of it is
>embarrassing. I don't even know how many releases of our parent POM we
>have, every one of them equal to the other, and this is nonsense.
>
>We shouldn't go backward, but forward. We need to extract APIs into
>their own independently released bundles. We should split oak-run in
>different CLI utility modules, so that every implementation can take
>better care of their own utilities. Oak is not a pet project and we
>have to admit that its current level of complexity doesn't allow us to
>use oak-core and oak-run as dumping grounds anymore.
>
>2016-10-21 14:08 GMT+02:00 Thomas Mueller :
>> Hi,
>>
>>> could adding an oak-core-api with independent lifecycle solve the
>>>situation?
>>
>> "All problems in computer science can be solved by another level of
>> indirection"
>>
>> I would prefer if we get oak-segment-tar in line with the rest of oak
>> (release it at the same time and so on). I understand, there are some
>> disadvantages. But I think all alternatives also have disadvantages.
>>
>> Regards,
>> Thomas
>>
>>
>>
>>
>> On 21/10/16 12:46, "Davide Giannella"  wrote:
>>
>>>Hello team,
>>>
>>>while integrating Oak with segment-tar in other products, I'm facing
>>>quite a struggle with a sort-of circular dependencies. We have
>>>segment-tar that depends on oak-core and then we have tools like oak-run
>>>or oak-upgrade which depends on both oak-core and segment-tar.
>>>
>>>this may not be an issue but in case of changes in the API, like for
>>>1.5.12 we have the following situation. 1.5.12 has been released with
>>>segment-tar 0.0.14 but this mix doesn't actually work on OSGi
>>>environment as of API changes. On the other hand, in order to release
>>>0.0.16 we need oak-core 1.5.12 with the changes.
>>>
>>>Now oak-run and other tools may fail, or at least be in an unknown
>>>situation.
>>>
>>>All of this is my understanding and I may be wrong, so please correct me
>>>if I'm wrong. I'm right, could adding an oak-core-api with independent
>>>lifecycle solve the situation?
>>>
>>>Davide
>>>
>>>
>>

Re: segment-tar depending on oak-core

[Thomas Mueller]

Hi,

>The release process in Oak is a joke.

I don't think it's a joke.

> Releasing every two weeks by
>using version numbers as counters just for the sake of it is
>embarrassing.

Why? It's simple.

> I don't even know how many releases of our parent POM we
>have, every one of them equal to the other, and this is nonsense.

"Nonsense"... again a word without explanation.

>We shouldn't go backward, but forward.

It depends on what "backward is". I would prefer if we make things
"simpler".

> We need to extract APIs into
>their own independently released bundles.

I don't think we need to do that. The "release everything at once" sounds
good to me.

> We should split oak-run in
>different CLI utility modules

Split, split, and again split. Why? What is the advantage?

>, so that every implementation can take
>better care of their own utilities.

It's the Oak utilities. I think the current organization is just fine.

>Oak is not a pet project

Again, you are using strong words ("pet"), but without real explanation...
How is it that your definition of "pet" is the only valid one?

>and we
>have to admit that its current level of complexity doesn't allow us to
>use oak-core and oak-run as dumping grounds anymore.

Again a strong word... "dump".

I just don't see how making tiny "ravioli" modules makes things any
better. It surely makes things more complex, as we see with
oak-segment-tar: it forces to add even more and more modules, to be able
to deal with the consequences of adding modules.

Regards,
Thomas

[VOTE] Release Apache Jackrabbit Oak 1.4.9

[Davide Giannella]

A candidate for the Jackrabbit Oak 1.4.9 release is available at:

https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.4.9/

The release candidate is a zip archive of the sources in:

   
https://svn.apache.org/repos/asf/jackrabbit/oak/tags/jackrabbit-oak-1.4.9/

The SHA1 checksum of the archive is
3d94e4022d72543ca703295cf623bd97091f2d64.

A staged Maven repository is available for review at:

https://repository.apache.org/

The command for running automated checks against this release candidate is:

$ sh check-release.sh oak 1.4.9 3d94e4022d72543ca703295cf623bd97091f2d64

Please vote on releasing this package as Apache Jackrabbit Oak 1.4.9.
The vote is open for the next 72 hours and passes if a majority of at
least three +1 Jackrabbit PMC votes are cast.

[ ] +1 Release this package as Apache Jackrabbit Oak 1.4.9
[ ] -1 Do not release this package because...

Davide

Re: segment-tar depending on oak-core

[Francesco Mari]

Luckily for us this is not a computer science problem but an easier
software engineering concern.

The release process in Oak is a joke. Releasing every two weeks by
using version numbers as counters just for the sake of it is
embarrassing. I don't even know how many releases of our parent POM we
have, every one of them equal to the other, and this is nonsense.

We shouldn't go backward, but forward. We need to extract APIs into
their own independently released bundles. We should split oak-run in
different CLI utility modules, so that every implementation can take
better care of their own utilities. Oak is not a pet project and we
have to admit that its current level of complexity doesn't allow us to
use oak-core and oak-run as dumping grounds anymore.

2016-10-21 14:08 GMT+02:00 Thomas Mueller :
> Hi,
>
>> could adding an oak-core-api with independent lifecycle solve the
>>situation?
>
> "All problems in computer science can be solved by another level of
> indirection"
>
> I would prefer if we get oak-segment-tar in line with the rest of oak
> (release it at the same time and so on). I understand, there are some
> disadvantages. But I think all alternatives also have disadvantages.
>
> Regards,
> Thomas
>
>
>
>
> On 21/10/16 12:46, "Davide Giannella"  wrote:
>
>>Hello team,
>>
>>while integrating Oak with segment-tar in other products, I'm facing
>>quite a struggle with a sort-of circular dependencies. We have
>>segment-tar that depends on oak-core and then we have tools like oak-run
>>or oak-upgrade which depends on both oak-core and segment-tar.
>>
>>this may not be an issue but in case of changes in the API, like for
>>1.5.12 we have the following situation. 1.5.12 has been released with
>>segment-tar 0.0.14 but this mix doesn't actually work on OSGi
>>environment as of API changes. On the other hand, in order to release
>>0.0.16 we need oak-core 1.5.12 with the changes.
>>
>>Now oak-run and other tools may fail, or at least be in an unknown
>>situation.
>>
>>All of this is my understanding and I may be wrong, so please correct me
>>if I'm wrong. I'm right, could adding an oak-core-api with independent
>>lifecycle solve the situation?
>>
>>Davide
>>
>>
>

Re: svn commit: r1765583 - in /jackrabbit/oak/trunk: oak-core/src/main/java/org/apache/jackrabbit/oak/api/jmx/ oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/index/property/strategy/ oak-cor

[Julian Sedding]

Thanks Chetan!

On Fri, Oct 21, 2016 at 2:59 PM, Chetan Mehrotra
 wrote:
> On Thu, Oct 20, 2016 at 6:08 PM, Julian Sedding  wrote:
>> I think we could get away with increasing this to 4.1.0 if we can
>> annotate QueryEngineSettingsMBean with @ProviderType.
>
> Makes sense. Opened OAK-4977 for that
>
> Chetan Mehrotra

Re: segment-tar depending on oak-core

[Julian Sedding]

> All of this is my understanding and I may be wrong, so please correct me
> if I'm wrong. I'm right, could adding an oak-core-api with independent
> lifecycle solve the situation?

While this may be possible, an arguably simpler solution would be to
give oak-run and oak-upgrade a separate lifecycle. They are consumers
of both segment-tar and oak-core (+ other bundles with same release
cycle). Hence they require interoperable releases of both *before*
they themselves can be released.

The other alternative, as Thomas mentioned, is to release everything
at once, including segment-tar.

Regards
Julian


On Fri, Oct 21, 2016 at 12:46 PM, Davide Giannella  wrote:
> Hello team,
>
> while integrating Oak with segment-tar in other products, I'm facing
> quite a struggle with a sort-of circular dependencies. We have
> segment-tar that depends on oak-core and then we have tools like oak-run
> or oak-upgrade which depends on both oak-core and segment-tar.
>
> this may not be an issue but in case of changes in the API, like for
> 1.5.12 we have the following situation. 1.5.12 has been released with
> segment-tar 0.0.14 but this mix doesn't actually work on OSGi
> environment as of API changes. On the other hand, in order to release
> 0.0.16 we need oak-core 1.5.12 with the changes.
>
> Now oak-run and other tools may fail, or at least be in an unknown
> situation.
>
> All of this is my understanding and I may be wrong, so please correct me
> if I'm wrong. I'm right, could adding an oak-core-api with independent
> lifecycle solve the situation?
>
> Davide
>
>

Re: svn commit: r1765583 - in /jackrabbit/oak/trunk: oak-core/src/main/java/org/apache/jackrabbit/oak/api/jmx/ oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/index/property/strategy/ oak-cor

[Chetan Mehrotra]

On Thu, Oct 20, 2016 at 6:08 PM, Julian Sedding  wrote:
> I think we could get away with increasing this to 4.1.0 if we can
> annotate QueryEngineSettingsMBean with @ProviderType.

Makes sense. Opened OAK-4977 for that

Chetan Mehrotra

Re: [REVIEW] Configuration required for node bundling config for DocumentNodeStore - OAK-1312

[Julian Sedding]

+1 for initializing the default config unconditionally

Regards
Julian

On Fri, Oct 21, 2016 at 12:14 PM, Chetan Mehrotra
 wrote:
> Opened OAK-4975 for query around default config handling.
> Chetan Mehrotra
>
>
> On Fri, Oct 21, 2016 at 2:14 PM, Davide Giannella  wrote:
>> On 21/10/2016 08:23, Michael Marth wrote:
>>> Hi Chetan,
>>>
>>> Re “Should we ship with a default config”:
>>>
>>> I vote for a small default config:
>>> - default because: if the feature is always-on in trunk we will get better 
>>> insights in day-to-day work (as opposed to switching it on only 
>>> occasionally)
>>> - small because: the optimal bundling is probably very specific to the 
>>> application and its read-write patterns. Your suggestion to include nt:file 
>>> (and maybe rep:AccessControllable) looks reasonable to me, though.
>>>
>> +1 but I would not do it that DocumentNS has to actively register it. I
>> would have a plain RepositoryInitialiser always on beside the
>> InitialContent. So that it's clear it's somewhat different. In the end
>> as far as I understood it doesn't matter if we're running segment, tar
>> or Document. The config will affect only Document.
>>
>> Davide
>>
>>

Re: segment-tar depending on oak-core

[Thomas Mueller]

Hi,

> could adding an oak-core-api with independent lifecycle solve the
>situation?

"All problems in computer science can be solved by another level of
indirection"

I would prefer if we get oak-segment-tar in line with the rest of oak
(release it at the same time and so on). I understand, there are some
disadvantages. But I think all alternatives also have disadvantages.

Regards,
Thomas




On 21/10/16 12:46, "Davide Giannella"  wrote:

>Hello team,
>
>while integrating Oak with segment-tar in other products, I'm facing
>quite a struggle with a sort-of circular dependencies. We have
>segment-tar that depends on oak-core and then we have tools like oak-run
>or oak-upgrade which depends on both oak-core and segment-tar.
>
>this may not be an issue but in case of changes in the API, like for
>1.5.12 we have the following situation. 1.5.12 has been released with
>segment-tar 0.0.14 but this mix doesn't actually work on OSGi
>environment as of API changes. On the other hand, in order to release
>0.0.16 we need oak-core 1.5.12 with the changes.
>
>Now oak-run and other tools may fail, or at least be in an unknown
>situation.
>
>All of this is my understanding and I may be wrong, so please correct me
>if I'm wrong. I'm right, could adding an oak-core-api with independent
>lifecycle solve the situation?
>
>Davide
>
>

segment-tar depending on oak-core

[Davide Giannella]

Hello team,

while integrating Oak with segment-tar in other products, I'm facing
quite a struggle with a sort-of circular dependencies. We have
segment-tar that depends on oak-core and then we have tools like oak-run
or oak-upgrade which depends on both oak-core and segment-tar.

this may not be an issue but in case of changes in the API, like for
1.5.12 we have the following situation. 1.5.12 has been released with
segment-tar 0.0.14 but this mix doesn't actually work on OSGi
environment as of API changes. On the other hand, in order to release
0.0.16 we need oak-core 1.5.12 with the changes.

Now oak-run and other tools may fail, or at least be in an unknown
situation.

All of this is my understanding and I may be wrong, so please correct me
if I'm wrong. I'm right, could adding an oak-core-api with independent
lifecycle solve the situation?

Davide

Re: [REVIEW] Configuration required for node bundling config for DocumentNodeStore - OAK-1312

[Chetan Mehrotra]

Opened OAK-4975 for query around default config handling.
Chetan Mehrotra


On Fri, Oct 21, 2016 at 2:14 PM, Davide Giannella  wrote:
> On 21/10/2016 08:23, Michael Marth wrote:
>> Hi Chetan,
>>
>> Re “Should we ship with a default config”:
>>
>> I vote for a small default config:
>> - default because: if the feature is always-on in trunk we will get better 
>> insights in day-to-day work (as opposed to switching it on only occasionally)
>> - small because: the optimal bundling is probably very specific to the 
>> application and its read-write patterns. Your suggestion to include nt:file 
>> (and maybe rep:AccessControllable) looks reasonable to me, though.
>>
> +1 but I would not do it that DocumentNS has to actively register it. I
> would have a plain RepositoryInitialiser always on beside the
> InitialContent. So that it's clear it's somewhat different. In the end
> as far as I understood it doesn't matter if we're running segment, tar
> or Document. The config will affect only Document.
>
> Davide
>
>

Re: [REVIEW] Configuration required for node bundling config for DocumentNodeStore - OAK-1312

[Davide Giannella]

On 21/10/2016 08:23, Michael Marth wrote:
> Hi Chetan,
>
> Re “Should we ship with a default config”:
>
> I vote for a small default config:
> - default because: if the feature is always-on in trunk we will get better 
> insights in day-to-day work (as opposed to switching it on only occasionally)
> - small because: the optimal bundling is probably very specific to the 
> application and its read-write patterns. Your suggestion to include nt:file 
> (and maybe rep:AccessControllable) looks reasonable to me, though.
>
+1 but I would not do it that DocumentNS has to actively register it. I
would have a plain RepositoryInitialiser always on beside the
InitialContent. So that it's clear it's somewhat different. In the end
as far as I understood it doesn't matter if we're running segment, tar
or Document. The config will affect only Document.

Davide

Re: [REVIEW] Configuration required for node bundling config for DocumentNodeStore - OAK-1312

[Michael Marth]

Hi Chetan,

Re “Should we ship with a default config”:

I vote for a small default config:
- default because: if the feature is always-on in trunk we will get better 
insights in day-to-day work (as opposed to switching it on only occasionally)
- small because: the optimal bundling is probably very specific to the 
application and its read-write patterns. Your suggestion to include nt:file 
(and maybe rep:AccessControllable) looks reasonable to me, though.

Cheers
Michael



On 21/10/16 08:31, "Chetan Mehrotra"  wrote:

>Hi Team,
>
>Work for OAK-1312 is now in trunk. To enable this feature user has to
>provision some config as content in repository. The config needs to be
>created under '/jcr:system/rep:documentStore/bundlor' [1]
>
>Example
>-
>jcr:system
>  rep:documentStore
>bundlor
>  app:Asset{pattern = [jcr:content/metadata, jcr:content/renditions,
>  jcr:content/renditions/**, jcr:content]}
>  nt:file{pattern = [jcr:content]}
>-
>
>Key points
>
>
>* This config is only required when system is using DocumentNodeStore
>* Any change here would be picked via Observation
>* Config is supposed to be changed only by system admin. So needs to
>be secured (OAK-4959)
>* Config can be changed anytime and would impact only newly created nodes.
>
>Open Questions
>
>
>Bootstrap default config
>---
>
>Should we ship with a default config for nt:file (may be other like
>rep:AccessControllable). If yes then how to do that. One way can be to
>introduce a new 'WhiteboardRepositoryInitializer' and then
>DocumentNodeStore can register one which bootstraps a default config
>
>Chetan Mehrotra
>[1] 
>https://issues.apache.org/jira/browse/OAK-1312?focusedCommentId=15387241=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15387241

[REVIEW] Configuration required for node bundling config for DocumentNodeStore - OAK-1312

[Chetan Mehrotra]

Hi Team,

Work for OAK-1312 is now in trunk. To enable this feature user has to
provision some config as content in repository. The config needs to be
created under '/jcr:system/rep:documentStore/bundlor' [1]

Example
-
jcr:system
  rep:documentStore
bundlor
  app:Asset{pattern = [jcr:content/metadata, jcr:content/renditions,
  jcr:content/renditions/**, jcr:content]}
  nt:file{pattern = [jcr:content]}
-

Key points


* This config is only required when system is using DocumentNodeStore
* Any change here would be picked via Observation
* Config is supposed to be changed only by system admin. So needs to
be secured (OAK-4959)
* Config can be changed anytime and would impact only newly created nodes.

Open Questions


Bootstrap default config
---

Should we ship with a default config for nt:file (may be other like
rep:AccessControllable). If yes then how to do that. One way can be to
introduce a new 'WhiteboardRepositoryInitializer' and then
DocumentNodeStore can register one which bootstraps a default config

Chetan Mehrotra
[1] 
https://issues.apache.org/jira/browse/OAK-1312?focusedCommentId=15387241=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15387241