[
https://issues.apache.org/jira/browse/OAK-41?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13458776#comment-13458776
]
Marcel Reutegger commented on OAK-41:
-------------------------------------
While working on OAK-315 I tried to move the built-in node type registration to
oak-jcr, but then quickly found out it's not that easy. Subject.doAs() also
does not look that promising because you need a principal oak-core trusts, but
it cannot be in oak-jcr nor can it be public in oak-core, otherwise any code
could use it and execute with elevated privileges. As a side note, this means
we will have to make AdminPrincipal non-public at some point.
We could still use Subject.doAs() to execute some kind of privileged action,
but it must be invoked by oak-core with an internal principal on code it
trusts. We already have trusted code in oak-core, which isn't actually part of
oak-core in a strict sense. The plugin mechanism with {{CommitHook}},
{{Observer} and {{Validator}} implementations go into that category.
What I propose is to extend this plugin mechanism with an interface that allows
you to hook into the life-cycle of a {{ContentRepository}}. The various plugins
we already have could then perform initial setup when the {{ContentRepository}}
is constructed and oak-core would make sure the code is executed as a
privileged action with Subject.doAs().
> Initial repository setup
> ------------------------
>
> Key: OAK-41
> URL: https://issues.apache.org/jira/browse/OAK-41
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: core
> Reporter: angela
>
> upon the initial creation of a JCR repository the associated SPI layer
> (oak-core) should
> take care of setting up the corresponding MK-instance. this includes
> (incomplete list):
> - create the jcr repo (not sure what that means in terms of mk-implementation)
> - create the jcr:system node (unique for the repository, across workspaces)
> - create the default workspace (-> name from config)
> - create the root node of the default workspace
> in addition the repository would need to have access to the following
> information (maybe also mk-nodes underneath jcr:system ??)
> - built-in node types
> - built-in namespace
> - built-in privileges
> - built-in permissions
> - repository configuration (can that be stored in the mk?)
> as far as the workspace is concerned a functional repository would in
> addition need to have:
> - build-in users (based on some sort of configuration)
> - workspace configuration
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
