Hi,
we are having Repository Initializer from Sling to perform some initial setup of eg paths and permissions:
This is how I have
{
"scripts": [
"create path (sling:Folder) /content/dam/brands/ceccatocluster",
"create path (nt:unstructured) /content/dam/brands/ceccatocluster/jcr:content",
"create path (cq:Page) /content/brands/ceccatocluster",
"create path (nt:unstructured) /content/brands/ceccatocluster/jcr:content",
"create group CeccatoCluster-template with path /home/groups/brandsv2",
"set ACL for CeccatoCluster-template \r\n allow jcr:all on /conf/brandsv2/ceccatocluster \r\nend",
"add CeccatoCluster-template to group template-authors",
"create group CeccatoCluster-content with path /home/groups/brandsv2",
"set ACL for CeccatoCluster-content \r\n allow jcr:all on /content/brands/ceccatocluster \r\nend",
"set ACL for CeccatoCluster-content \r\n allow jcr:all on /content/dam/brands/ceccatocluster \r\nend",
"add CeccatoCluster-content to group contributor",
"add CeccatoCluster-content to group workflow-users",
"set properties on /content/brands/ceccatocluster/jcr:content \r\n set cq:allowedTemplates{String[]} to \"/conf/brandsv2/ceccatocluster/settings/wcm/templates/(?!xf-).*\" \r\n set cq:conf{String} to /conf/brandsv2/ceccatocluster \r\n set cq:deviceGroups{String[]} to /etc/mobile/groups/archetype \r\n set cq:redirectTarget{String} to /content/brands/ceccatocluster/en \r\n set cq:template{String} to /conf/brandsv2/ceccatocluster/settings/wcm/templates/content-page \r\n set jcr:title{String} to \"Ceccato Cluster\" \r\n set scene7Enabled{Boolean} to true \r\n set sling:configRef{String} to /conf/brandsv2/ceccatocluster \r\n set sling:redirect{Boolean} to true \r\n set sling:redirectStatus{Long} to 302 \r\n set sling:resourceType{String} to brandsv2/components/structure/page \r\nend"
]
}
what happens if in case some repository paths are missing, in case some of the properties already have some value (single value / multi value), etc.
is there anyway to check if the property has this value set this, if the path is missing what to do in order to not effect repositoy initializer.
Please share some inputs how we can improve the config files.
Thanks,
Vani.
Solved! Go to Solution.
Views
Replies
Total Likes
Hi @Vani1012 ,
The repo-init runs before the SlingRepository service is registered, which briefly means that it will run before your code runs and usually, it is used as an "initial" setup for your code to work properly.
According to the official documentation, these are the preferred scenarios for the usage of repo-init:
Create/delete/disable service users
Create/delete groups
Create/delete users
Add ACLs
There is a a big NOTE also, You must create the path statements you will be using in your repoinit configurations, because they won't be available at the time the config runs.
You could also test what happen with your repoinit configurations by adding a custom logger and check how these will affect your repository. Add an INFO logger for the packages:
Here are good resources to deep dive into the understanding of how and when to use the repo init:
Hi @Vani1012 ,
The repo-init runs before the SlingRepository service is registered, which briefly means that it will run before your code runs and usually, it is used as an "initial" setup for your code to work properly.
According to the official documentation, these are the preferred scenarios for the usage of repo-init:
Create/delete/disable service users
Create/delete groups
Create/delete users
Add ACLs
There is a a big NOTE also, You must create the path statements you will be using in your repoinit configurations, because they won't be available at the time the config runs.
You could also test what happen with your repoinit configurations by adding a custom logger and check how these will affect your repository. Add an INFO logger for the packages:
Here are good resources to deep dive into the understanding of how and when to use the repo init:
Hello @Vani1012
The entire concept of repo-init fits the concept of mutable and immutable area.
This is generally used in context of AEM as a Cloud Service (AaaCS).
For ACLs defined for nodes underneath /apps
or /libs
the repoinit
, execution starts on a blank repository. The packages are installed after repoinit
so statements cannot rely on anything defined in the packages but must define the preconditions like the parent structures underneath.
In AaaCS, since the repoinit works on a blank repository, you don't have conflicts around arrays. However, the situation changes in case of AEM 6.5.
- All paths, code and content already exists.
So, when repo-init runs on start up we see issues related to arrays.
This would have been resolved if we were able to enforce arrays. Currently, it is only working for multiple values. Example following is documented on https://sling.apache.org/documentation/bundles/repository-initialization.html
set properties on /forcedMultiValue
set singleMultiValue{String[]} to "single"
set emptyMultiValue{String[]} to
set singleLongMultiValue{Long[]} to 1243
set emptyLongMultiValue{Long[]} to
end
Requesting you to please raise 2 support tickets for following:
For more debugging, @EstebanBustamante has shared more info with us
should I raise daycare for support ticket,
also what about that acl permission issue if path doesnt exist, how to make this not to throw exception
Please raise a support ticket to report about multi-field.
For ACLs, it is an expected behaviour:
- We cannot add ACL (rep:policy node) without having the parent, which is a resource
- Also we need to assure that we are using the correct jcr:primaryType while creating structures. I guess these cannot be changed later (unless we replace via a deployment).
Until array related issues are resolved for 6.5, May be use:
@aanchal-sikka as we see if path not exist assigning permissions to it throwing exceptions, also for multi-valued property assigning single value also throwing exceptions and it failed the script
How we can make the current repo init scripts more robust so they are not failing as often
For future development, we need some guidelines or best practices to apply
Can you share your inputs
Hello @Vani1012
Please refer to this video https://www.youtube.com/watch?v=wWoKO8l1ClA
They have explained concepts around repo-init.
I couldn't find a proper documentation around best practices
Now to the questions:
1. Paths do not exist: All paths where you face this exception, paths should be created by repo-init and then ACLs should be set. So, in same configuration file, first create path, next set ACL
2. Multi-fields: If you can set multiple values in repo-init, you would be able to create multi-field type property like String[]. If only one value is passed, it creates String.
3. For single -> multiple-values properties: For such scenarios, prefer to skip repo-init. Set these properties by content packages or ui.content, by using mode filter judiciously.
@Vani1012 Do you find the suggestions from users useful? Please let us know if more information is required. Otherwise, please mark the answer as correct for posterity.
Views
Replies
Total Likes
you have an issue with the jcr:content node types
please correct the types of all the nodes otherwise there will be violation of the node definition rule..