[
https://issues.apache.org/jira/browse/SLING-6398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu updated SLING-6398:
-----------------------------------
Attachment: 0001-SLING-6368-Repoinit-should-not-attempt-to-create-acc.patch
[~bdelacretaz] - here's a patch that works for my scenario, with some tests
added.
I did not find a good way to test that the ACL is not set again, so I exposed
an utility method from AclUtil and tested that.
The log entries are similar to
{noformat}15.12.2016 11:50:21.463 *INFO* [Apache Sling Repository Startup
Thread] org.apache.sling.jcr.repoinit.impl.AclUtil Not adding
[LocalAccessControlEntry# principal
org.apache.jackrabbit.oak.security.user.SystemUserPrincipalImpl:sling-scripting,
privileges: [jcr:read], isAllow : true] to path /libs since an equivalent
access control entry already exists{noformat}
How does that look to you?
> Repoinit should not attempt to create access control entries when no changes
> are needed
> ---------------------------------------------------------------------------------------
>
> Key: SLING-6398
> URL: https://issues.apache.org/jira/browse/SLING-6398
> Project: Sling
> Issue Type: Improvement
> Components: Repoinit
> Reporter: Robert Munteanu
> Assignee: Robert Munteanu
> Fix For: Repoinit JCR 1.1.2
>
> Attachments:
> 0001-SLING-6368-Repoinit-should-not-attempt-to-create-acc.patch
>
>
> I have a more complex Sling setup based on the recent Oak multiplexing
> additions.
> The repository is split bewteen
> - /libs and /apps, read-only
> - the rest of the repository, read-write
> When the provisioning model contains ACL definitions, they are processed
> directly without checking if they exist. In turn, Oak updates the
> definitions, even if equivalent ones exist. This causes the repoinit part to
> fail if it refers to ACLs for the read-only part of the repository.
> I would propose that the repoinit statements check if the ACL really needs to
> be replaced or if it can be skipped. This also has the advantage of making it
> symmetric with the checks for service users and paths and also should
> slightly reduce provisioning time.
> [~bdelacretaz] - would that work for you?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
