[
https://issues.apache.org/jira/browse/OAK-640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13581351#comment-13581351
]
angela commented on OAK-640:
----------------------------
let me try... :-)
the sequence for the RepositoryInitializer(s) and the calling OakInitializer
currently is as follows
(taking the example of the UserInitializer):
{code}
// OakInitializer calls UserInitialier
[...]
branch.setRoot(initializer.initialize(before));
[...]
// the user initializer hard-codes the p2indexhockprovider and the
p2indexprovider
NodeStoreBranch branch = store.branch();
branch.setRoot(state);
// calls branch.merge for the hardcoded indexhook provider
try {
branch.merge(IndexHookManager.of(new Property2IndexHookProvider()));
} catch (CommitFailedException e) {
throw new RuntimeException(e);
}
Root root = new RootImpl(store, new Property2IndexProvider());
[...]
// back in the OakInitializer: the configured indexHook is used to
// call branch.merge again.
try {
branch.merge(IndexHookManager.of(indexHook));
} catch (CommitFailedException e) {
throw new RuntimeException(e);
}
{code}
so... i got confused by the fact that the indexhook is merged twice. it just
looked odd to me but i admit that i didn't investigate :-)
with the patch that hardcoded index-stuff is gone. while i am confident
that getting rid of the hardcoded stuff is preferrable, i am not sure if in this
case the duplicate merge call was still needed and if not where the merge
needs to go. since i ignore the details of the index code base and of your
recent modifications in that area, i would appreciate if you could take a look.
> 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
