Hi everybody, I might have found a bug related to the changes of SLING-3848. Due to some requirements some properties of a resource had to be moved to a third location for the resources of one very specific contentbranch. Now I do have a ResourceProvider that does nothing more then creating a ResourceWrapper in the original location hiding the JCRNodeResource underneath. As proposed by Carsten in another thread (see [0]) I solve the problem of the locked JCRNodeResourceMetadata via creating a new Metadata object and setting the entries via putAll() in the constructor of the own Wrapper. At this point I get an exception caused by a node.getPrimaryItem() call in JCRNodeResourceMetadata ([1] Line 164).
--- org.apache.sling.jcr.resource.internal.helper.jcr.JcrNodeResource setMetaData: Problem extracting metadata information for /etc/mypath/jcr:content javax.jcr.ItemNotFoundException: No primary item present on node getPrimaryItem --- I verified that this happens on oak based and jcr 2 based instances. I don't know the exact mechanism of SLING-3848 [2], how that node is supposed to behave and what the goal of that codefragment exactly is, but I expect other consumers to fail as well since SuperImposingResource [3] actually is doing the same (although in an own resource not a ResourceWrapper, but that shouldn't be a difference in the constructor. Any ideas what's going on here? Best regards Dominik [0] http://markmail.org/thread/ortcft2vjjs2ukga [1] http://svn.apache.org/viewvc/sling/trunk/bundles/jcr/resource/src/main/java/org/apache/sling/jcr/resource/internal/helper/jcr/JcrNodeResourceMetadata.java [2] https://issues.apache.org/jira/browse/SLING-3848 [3] https://github.com/apache/sling/blob/trunk/contrib/extensions/superimposing/src/main/java/org/apache/sling/superimposing/impl/SuperimposingResource.java#L44
