[
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)
