Details
-
Improvement
-
Status: Open
-
Major
-
Resolution: Unresolved
-
Resource Merger 1.4.0
-
None
-
None
Description
In this constructor, I see the following logic:
1. Try to find the sling:resourceType property, set in any of the resources
2. If that property could not be found, try using the relative path
Then, even if a proper sling:resourceType property was found, it will overwrite that value with the result of Resource#getResourceType if it is not null, of the last resource that defines one. This could be entirely right (maybe this done because some people use wrappers, that override the getResourceType-method?).
However, in the JCR implementation of Resource (JcrNodeResource/JcrItemResource), it is rare for getResourceType to return null, because:
1. Try to return the defined sling:resourceType's value
2. If not found, try to return the value of jcr:primaryType
Generally, any node has a jcr:primaryType defined and thus returns it.
When the overridden resource does not mention a resource type, this effectively makes getResourceType of the merged resource return the node type of the overridden resource (in our case: nt:unstructured).
Easy case to reproduce:
/libs/test (@jcr:primaryType: nt:unstructured, @sling:resourceType=website/component, @prop=test)
/apps/test (@jcr:primaryType: nt:unstructured, @prop=test-overridden)
->
resource.getResourceType(): nt:unstructured
resource.getResourceSuperType(): website/component
resource.getValueMap().get("prop"): test-overridden
resource.getValueMap().get("sling:resourceType"): website/component
(Marked in the bold, the values I think are not correct in this case.)