[jira] [Comment Edited] (OAK-7510) Run repository initializers with hooks

["Alex Deparvu (JIRA)" <ji...@apache.org>]

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

Alex Deparvu edited comment on OAK-7510 at 5/29/18 4:24 PM:
------------------------------------------------------------

Finally reached a consistent state with the patch, where is passes all the integration tests [0]
Changes so far:
* CugConfiguration no longer hardcodes editors
* InitialContent#INITIAL_CONTENT moved to a test class (InitialContentHelper), seems odd to have this static structure kept in memory on live systems anyway
* Oak now wires the security provider components lazy (during the repo construction) this helps with race conditions on repo initializers
* 'oak' namespace registered by default - this actually started as a bootstrapping issue between the editors and the repo initializers, still seems odd that 'oak' is not wired in with the other default namespaces 
* NamespaceEditor allows a single xml registration (not more), to me this seems safe, would love to have more thoughts here
* PrivilegeInitializer no longer creates jcr:system if it doesn't exist. this actually looks dangerous, depending on the other of init the other child nodes of jcr:system might not get created
* UserProvider creates malformed user entries (missing 'rep:principalName' which in only added by the UserManagerImpl) so I had to disable a few root.commit calls
* OpenAuthorizationConfiguration needs to create the missing node under jcr:system (rep:privileges) to make the entire structure valid
* a huge amount of tests updated to use the new InitialContentHelper#INITIAL_CONTENT

remaining work:
* did not touch the workspace initializers yet. this part should change in  a similar way
* I think calling "builder.child(JCR_SYSTEM)" inside any repo initializer is pretty dangerous, it might make sense to refactor out some of the calls. this seems pretty complex as we don't currently have a good way to order the initializers before applying them to the root node.
* how to make sure in an OSGi env that the expected providers are actually there (as a part of the hooks that run over the repo initializers)?

[~mreutegg], [~anchela] would appreciate some feedback!


[0] https://github.com/apache/jackrabbit-oak/compare/trunk...stillalex:initial-content-initializers




was (Author: alex.parvulescu):
Finally reached a consistent state with the patch, where is passes all the integration tests [0]
Changes so far:
* CugConfiguration no longer hardcodes editors
* InitialContent#INITIAL_CONTENT moved to a test class (InitialContentHelper), seems odd to have this static structure kept in memory on live systems anyway
* Oak now wires the security provider components lazy (during the repo construction) this helps with race conditions on repo initializers
* 'oak' namespace registered by default - this actually started as a bootstrapping issue between the editors and the repo initializers, still seems odd that 'oak' is not wired in with the other default namespaces 
* NamespaceEditor allows a single xml registration (not more), to me this seems safe, would love to have more thoughts here
* PrivilegeInitializer no longer creates jcr:system if it doesn't exist. this actually looks dangerous, depending on the other of init the other child nodes of jcr:system might not get created
* UserProvider creates malformed user entries (missing 'rep:principalName' which in only added by the UserManagerImpl) so I had to disable a few root.commit calls
* OpenAuthorizationConfiguration needs to create the missing node under jcr:system (rep:privileges) to make the entire structure valid
* a huge amount of tests updated to use the new InitialContentHelper#INITIAL_CONTENT

remaining work:
* did not touch the workspace initializers yet. this part should change in  a similar way
* I think calling "builder.child(JCR_SYSTEM)" inside any repo initializer is pretty dangerous, it might make sense to refactor out some of the calls. this seems pretty complex as we don't currently have a good way to order the initializers before applying them to the root node.

[~mreutegg], [~anchela] would appreciate some feedback!


[0] https://github.com/apache/jackrabbit-oak/compare/trunk...stillalex:initial-content-initializers



> Run repository initializers with hooks
> --------------------------------------
>
>                 Key: OAK-7510
>                 URL: https://issues.apache.org/jira/browse/OAK-7510
>             Project: Jackrabbit Oak
>          Issue Type: Improvement
>          Components: core
>            Reporter: Alex Deparvu
>            Assignee: Alex Deparvu
>            Priority: Major
>              Labels: modularization
>
> Currently the repository initializers (RepositoryInitializer and WorkspaceInitializer) run when the repo boots without any hooks [0] which means that current RepositoryInitializers need to setup custom Roots (roots with hardcoded editor providers like NamespaceEditorProvider and TypeEditorProvider) on top of the provided builders to be able to setup properly. I'm looking at the InitialContent [1] and the CugConfiguration [2] in the context of installing node types.
> I would like to look into removing the hardcoded providers and trying to run all existing editors over the content produced by the initializers.
> As an added benefit this will allow decoupling of hard dependencies between components (see for example OAK-7499)
> [0] https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/Oak.java#L687 
> [1] https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/InitialContent.java#L134
> [2] https://github.com/apache/jackrabbit-oak/blob/trunk/oak-authorization-cug/src/main/java/org/apache/jackrabbit/oak/spi/security/authorization/cug/impl/CugConfiguration.java#L162



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)