You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-issues@jackrabbit.apache.org by "Mark Adamcin (Jira)" <ji...@apache.org> on 2023/07/02 21:36:00 UTC

[jira] [Created] (OAK-10335) TypeEditor misapplies default primary type of child node to its parent when the child primary type is not set

Mark Adamcin created OAK-10335:
----------------------------------

             Summary: 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


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.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)