Repository Initializers and Repository Initialization Language
The SlingRepositoryInitializer
mechanism allows for running code before the SlingRepository
service is registered.
This is useful for initialization and content migration purposes.
Please be aware of potential clustering and coordination issues when using this mechanism, if your environment lets several Sling instances access the same content repository you'll need to implement a synchronization mechanism for such operations.
SlingRepositoryInitializer¶
The SlingRepositoryInitializer
is a very simple service interface, available from version 2.4.0 of the org.apache.sling.jcr.api
and org.apache.sling.jcr.base
bundles.
public interface SlingRepositoryInitializer { public void processRepository(SlingRepository repo) throws Exception; }
Services that implement this interface are called when setting up the JCR-based SlingRepository
service, before registering it as an OSGi service.
They are called in increasing order of their service.ranking
service property, which needs to be an Integer
as usual.
If any of them throws an Exception, the SlingRepository
service is not registered.
The 'repoinit' Repository Initialization Language¶
The org.apache.sling.repoinit.parser
implements a mini-language meant to create paths, service users and Access Control Lists in a content repository, as
well as registering JCR namespaces and node types.
The language grammar is defined (using the JavaCC compiler-compiler, which has no runtime dependencies) in the RepoInitGrammar.jjt
file in that module, and the automated tests provide a number of test cases which demonstrate various features.
The companion org.apache.sling.jcr.repoinit
module implements those operations on an Oak JCR repository, using a SlingRepositoryInitializer
registered by default with a service ranking of 100. It also provides a JcrRepoInitOpsProcessor
service to explicitly apply the output
of the repoinit parser to a JCR repository.
Here's a current example from the test cases mentioned above, that uses all language features as of version 1.0.2 of the parser module.
The language is self-explaining but please refer to the actual test cases for details that are guaranteed to be up to date, assuming the tests pass.
create service user user1, u-ser_2 set ACL on /libs,/apps allow jcr:read for user1,u-ser_2 deny jcr:write for u-ser_2 deny jcr:lockManagement for user1 remove jcr:understand,some:other for u3 end create service user bob_the_service set ACL on /tmp allow some:otherPrivilege for bob_the_service end # Nodetypes inside the path apply to just that path element create path /content/example.com(sling:Folder) # Nodetypes and mixins applied to just a path element # Specifying mixins require # o.a.s.repoinit.parser 1.2.0 and # o.a.s.jcr.repoinit 1.2.0 create path /content/example.com(sling:Folder mixin mix:referenceable,mix:shareable) # Mixins applied to just a path element create path /content/example.com(mixin mix:referenceable) # A nodetype in front is used as the default for all path elements create path (nt:unstructured) /var set ACL for alice, bob,fred # remove is currently not supported by the jcr.repoinit module remove * on / allow jcr:read on /content,/var deny jcr:write on /content/example.com deny jcr:all on / nodetypes example:Page end set ACL for restrictions_examples deny jcr:modifyProperties on /apps, /content nodetypes sling:Folder, nt:unstructured restriction(rep:itemNames,prop1,prop2) allow jcr:addChildNodes on /apps restriction(rep:ntNames,sling:Folder,nt:unstructured) allow jcr:modifyProperties on /apps restriction(rep:ntNames,sling:Folder,nt:unstructured) restriction(rep:itemNames,prop1,prop2) allow jcr:addChildNodes on /apps,/content restriction(rep:glob,/cat/*,*/cat,*cat/*) end # Set repository level ACL # Setting repository level ACL require # o.a.s.repoinit.parser 1.2.0 and # o.a.s.jcr.repoinit 1.2.0 set repository ACL for alice,bob allow jcr:namespaceManagement,jcr:nodeTypeDefinitionManagement end # register namespace requires # o.a.s.repoinit.parser 1.0.4 # and o.a.s.jcr.repoinit 1.0.2 register namespace ( NSprefix ) uri:someURI/v1.42 # register nodetypes in CND format # (same bundle requirements as register namespaces) # # The optional << markers are used when embedding # this in a Sling provisioning model, to avoid syntax errors # # The CND instructions are passed as is to the JCR # modules, so the full CND syntax is supported. # register nodetypes <<=== << <slingevent='http://sling.apache.org/jcr/event/1.0'> << << [slingevent:Event] > nt:unstructured, nt:hierarchyNode << - slingevent:topic (string) << - slingevent:properties (binary) ===>> create user demoUser with password {SHA-256} dc460da4ad72c482231e28e688e01f2778a88ce31a08826899d54ef7183998b5 # disable service user create service user deprecated_service_user disable service user deprecated_service_user : "Disabled user to make an example" create service user the-last-one
Providing repoinit statements from the Sling provisioning model or other URLs¶
All bundles required for this feature need to be active before the SlingRepository
service starts.
From version 1.0.2 of the org.apache.sling.jcr.repoinit
bundle, the o.a.s.jcr.repoinit.RepositoryInitializer
component uses an OSGi
configuration as shown in this example to define where to read repoinit statements:
org.apache.sling.jcr.repoinit.impl.RepositoryInitializer references=["model:context:/resources/provisioning/model.txt","model@repoinitTwo:context:/resources/provisioning/model.txt"]
This example defines two references to URLs that supply repoinit statements. Their syntax is described below.
By default the RepositoryInitializer
uses the first URL shown in the above example, which points to the provisioning model that's embedded by default in the Sling Launchpad runnable jar.
Note that previous versions of the org.apache.sling.jcr.repoinit
bundle used different configuration parameters. From version 1.0.2 on, warnings are logged if those old parameters (text.url,text.format,model.section.name) are used.
References to Sling Provisioning Model additional sections¶
The slingstart-maven-plugin
, from V1.4.2 on, allows for embedding so-called "additional sections" in the Sling provisioning model by starting
their name with a colon.
At runtime this requires the org.apache.sling.provisioning.model
bundle, version 1.4.2 or later.
The o.a.s.jcr.repoinit
bundle can use this feature to execute repoinit
statements provided by Sling provisioning models, as in this
provisioning model example fragment:
[:repoinit] create path /repoinit/provisioningModelTest create service user provisioningModelUser
To read repoinit statements from such an additional provisioning model section, the RepositoryInitializer
configuration shown above uses references like
model@repoinitTwo:context:/resources/provisioning/model.txt
Where model means "use the provisioning model format", repoinitTwo is the name of the additional section to read statements from in the provisioning model (without the leading colon) and context:/resources/... is the URL to use to retrieve the provisioning model.
In this example the URL uses the context scheme defined by the Sling Launchpad, but any scheme can be used provided a suitable URL handler is active.
The section name in that reference is optional and defaults to repoinit. If it's not specified the @
should be omitted as well.
References to URLs providing raw repoinit statements¶
Using a RepositoryInitializer
reference like in this example, with the raw prefix, means that its content is passed as is to the repoinit parser:
raw:classpath://some-repoinit-file.txt
Which points to a classpath:
URL to provide the raw repoinit statements in this example, but again any valid URL scheme can be used.