jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (OAK-41) Initial repository setup
Date Thu, 20 Sep 2012 09:31:07 GMT

    [ https://issues.apache.org/jira/browse/OAK-41?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13459483#comment-13459483
] 

Jukka Zitting commented on OAK-41:
----------------------------------

I'd rather leave lifecycle management up to a separate container (OSGi or otherwise), and
avoid such explicit initialization steps in oak-core or oak-jcr.

Instead I'd push such default content and other initialization work all the way down to when
the underlying MicroKernel repository gets installed (Repository.init in the default MK).
If in there an initializer needs access to higher-level functionality (like the registerNodeTypes
method), it can construct and use a temporary JCR Repository instance using classes from oak-core
and oak-jcr for that. And since such a MicroKernel initializer is in full control of the repository,
it can simply omit all access control checks and thus avoid any Subject.doAs tricks.
                
> 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

Mime
View raw message