[
https://issues.apache.org/jira/browse/OAK-640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13581383#comment-13581383
]
Alex Parvulescu commented on OAK-640:
-------------------------------------
First the OakInitializer creates one branch to aggregate all the repo
initializers under one merge.
Second, the hardcoded stuff was there to circumvent the fact that the
userinitializer was creating a root without any notion of indexes, and some
queries failed because of that.
Now as you very well point out the hardcoded part is gone, which is nice, and
we're left with an extra merge on our hands which is not too optimal.
As I see it, this branch/merge should only involve a limited amount of content
(new/change stuff on the branch), not the entire repository. If that is not the
case, we'll need to take another look.
Also +1 on the patch :)
> Add WorkspaceInitializer
> ------------------------
>
> Key: OAK-640
> URL: https://issues.apache.org/jira/browse/OAK-640
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: core
> Reporter: angela
> Attachments: OAK-640.patch
>
>
> i had another look at various RepositoryInializer and in particular at
> the way the UserInitializer is created to ensure proper indexing coming
> to the conclusion that the latter isn't an actual RepositoryInitializer
> as it will only work properly in a context where the basic repository
> setup is already available (commit hooks, index configuration, node types,
> security configuration etc). furthermore the current default implementation
> is intended to keep user information on a workspace level.
> so, what while we try to do everything with the RepositoryInitializer
> we are actually missing another level of init and i'd suggest to add
> another interface to the spi.lifecycle package that covers initialization
> of what can be considered "workspace" information. that separate initializers
> would only be called after the global repo setup is being completed and
> would already be aware of the individual configuration settings like
> indexes, commit hooks and so forth.
> since we don't have support for multiple workspaces right now we can
> keep our single workspace setup along with the OAK#createContentRepository
> call such that we can still move it to the proper location that was
> responsible of initializing a new workspace upon creation.
> i will take another look and provide an initial draft for further
> discussions. the overall goal was to ensure proper "workspace" setup
> without hardcoding the indexprovider, security setup and the commit hooks
> in the userinitializer.
--
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
