[
https://issues.apache.org/jira/browse/OAK-10335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17742306#comment-17742306
]
Angela Schreiber commented on OAK-10335:
----------------------------------------
[~madamcin], you are right that {{TypeEditor}} has most likely issue. However,
any tool operating on the jcr repository should make sure that the content it
creates is meaningful. since this is not the adobe jira you don't have to
provide details about a closed source application, but i would strongly
recommend that the team responsible for this tool, works on it's stability. if
it by-passes JCR API and direct operates on a lower API level, it needs to make
sure that the content written is consistent and correct.
i checked where the {{TypeEditorProvider}} is used in oak with 'strict' mode
being set to false:
- oak-upgrade as 'copy' (Copies the full content from the source to the target
repository.)
- oak-upgrade as RepositorySidegrade for migrateWithoutCheckpoints
both don't seem to be prone to the problem you are describing.... so it might
be caused by the tool you are mentioning.
i am therefore reducing the priority of this bug.
> TypeEditor misapplies default primary type of child node to its parent when
> the child primary type is not set
> --------------------------------------------------------------------------------------------------------------
>
> Key: OAK-10335
> URL: https://issues.apache.org/jira/browse/OAK-10335
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
> Affects Versions: 1.52.0
> Reporter: Mark Adamcin
> Priority: Critical
>
> h2. Preconditions
> * Child node's "after" state does not have a jcr:primaryType property
> * TypeEditorProvider is created with strict=false to suppress the
> ConstraintViolationException for the missing jcr:primaryType property
> * Parent node's effective type specifies a default type for the child's node
> name
> h2. Summary
> This issue ultimately presented in an AEM author environment as a Sling
> Repository Initializer exception:
>
> {code:java}
> Exception in a SlingRepositoryInitializer, SlingRepository service
> registration aborted throwable : javax.jcr.RepositoryException: Applying
> repoinit operation failed despite retry; set loglevel to DEBUG to see all
> exceptions. Last exception message was: Session.save failed:
> javax.jcr.nodetype.ConstraintViolationException: OakConstraint0001:
> /conf/rep:policy[[rep:GrantACE]]: No matching definition found for child node
> deny90 with effective type [rep:DenyACE]_ {code}
> somehow the jcr:primaryType values for each segment of the relative path
> under /conf, rep:policy/allow78/rep:restrictions, had been saved to its
> parent. What should have been:
> *rep:policy(rep:ACL)/allow78(rep:GrantACE)/rep:restrictions(rep:Restrictions)*
> had been committed as
> *rep:policy(rep:GrantACE)/allow78(rep:Restrictions)/rep:restrictions(<not
> set>)*
> Additionally, the jcr:primaryType properties for rep:policy and allow78 HAD
> been set correctly in previous commit roots, but had been changed incorrectly
> in the same commit that created the rep:restrictions node. The same commit
> had also included changes to a list of linked principal names that could not
> be correlated with any artifact in the custom code or installed filevault
> packages.
>
> After changing the jcr:primaryType properties directly in the mongodb
> database to allow the repository to complete its startup, further
> investigation determined that a Content Transfer Tool import had been
> executed just prior to the first appearance of this error in the server logs.
> The fact that the rep:restrictions node had been persisted without a
> jcr:primaryType property strongly suggested that the corrupting change had
> not been made through the JCR API.
> The other important detail is that the rep:glob property was properly saved
> to the rep:restrictions node as part of the same commit, which implies that
> the jcr:primaryType property is subject to some special treatment in this
> situation.
> These details led me to suspect that the TypeEditor is the source of this
> behavior.
> The TypeEditor normally rejects a commit with a ConstraintViolationException
> when an "after" node state lacks a jcr:primaryType property, but it will
> instead only log this condition if the TypeEditorProvider is created with
> strict=false. I've confirmed that this is how the Content Transfer Tool
> importer constructs its root type editor.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
