[
https://issues.apache.org/jira/browse/OAK-41?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13462643#comment-13462643
]
Marcel Reutegger edited comment on OAK-41 at 9/25/12 9:58 PM:
--------------------------------------------------------------
bq. lifecycle management up to a separate container
Agreed, and my patch also contains a TODO for that. Similar to all other
plugins, the life cycle hook should be pluggable in a sense that you can deploy
them e.g. in an OSGi container as a separate bundle. Instead of hardcoding the
hooks we could introduce a LifeCycleHookProvider similar to ValidatorProvider
we already have.
bq. Subject.doAs tricks
Good point. Though, we have to review that usage in general. I'll try the
approach you suggested.
was (Author: mreutegg):
.bq lifecycle management up to a separate container
Agreed, and my patch also contains a TODO for that. Similar to all other
plugins, the life cycle hook should be pluggable in a sense that you can deploy
them e.g. in an OSGi container as a separate bundle. Instead of hardcoding the
hooks we could introduce a LifeCycleHookProvider similar to ValidatorProvider
we already have.
.bq Subject.doAs tricks
Good point. Though, we have to review that usage in general. I'll try the
approach you suggested.
> 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
> Attachments: OAK-41-initial-proposal.patch
>
>
> 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
