[
https://issues.apache.org/jira/browse/SLING-11504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17574067#comment-17574067
]
Carsten Ziegeler commented on SLING-11504:
------------------------------------------
Please note, that whether the value map should contain the sling:resourceType
property or not, is not the heart of this issue.
If you are outputting the value map of a resource it is very helpful if it also
shows the resource type, otherwise just having the value map does not give you
all the info about the resource. That's why 10 years ago or so, some effort was
made to have the resource type in the value map for the resources.
For the JCR resource, you either have that property or the primary node type
which is equivalent. Of course, that is not very consistent and leaks
implementation. But still looking at the value map allows you to see the
resource type. And the same is true for the FileResource. I'm not saying this
is great, I'm also not saying that this is something we really need to worry
about. I was just trying to explain why for the BundleResource the
sling:resourceType property is set.
> BundleResource fallback sling:resourceType should be consistent with
> JcrNodeResource
> ------------------------------------------------------------------------------------
>
> Key: SLING-11504
> URL: https://issues.apache.org/jira/browse/SLING-11504
> Project: Sling
> Issue Type: Improvement
> Affects Versions: Bundle Resource 2.3.4
> Reporter: Michal Cukierman
> Priority: Minor
> Attachments: Screenshot 2022-07-29 at 17.35.04.png,
> image-2022-07-29-16-47-41-320.png
>
>
> *Background:*
> We work on Sling based CMS -
> [https://www.websight.io|https://www.websight.io/] . One of our current goals
> is to move /apps and /libs folders into bundle resources and get rid of JCR
> based sling scripting and configurations (JCR Installer). This is an
> alternative approach to CompositeNodeStore usage in order to support
> containerized environments, blue-green deployments, and separation of code,
> configuration, and data.
> To achieve this, we move components (and dialogs) definitions from JCR into
> bundles and make them work with the same APIs (like Sling Resource Merger).
>
> *The problem:*
> JcrNodeResource and BundleResource use different mechanisms for calculating
> fallback sling:resourceType
> * In JCR, Resource.getResourceType method is used to calculate resourceType
> if no explicit property is found in the repository. See
> [https://github.com/apache/sling-org-apache-sling-jcr-resource/blob/72c105d67adc58ef1f4d43de78815fdcebb290b5/src/main/java/org/apache/sling/jcr/resource/internal/helper/jcr/JcrItemResource.java#L120]]
> * In Bundles, sling:resourceType is always set in the constructor and later
> overwritten by the JSON properties, if available. See:
> |[https://github.com/apache/sling-org-apache-sling-bundleresource-impl/blob/master/src/main/java/org/apache/sling/bundleresource/impl/BundleResource.java#L91]
> It results in a different contract, in particular, it’s impossible to declare
> BundleResource with no sling:resorurceType property. The result can be
> observed in the following Groovy Script execution, where both nodes have no
> sling:resourceTypes declared:
> !image-2022-07-29-16-47-41-320.png|width=751,height=545!
> Incompatible BundleResource and JCRNodeResource contracts requires
> workarounds in multiple APIs (our internal APIs / SlingResource Merger API)
> or to do workarounds at the data level.
>
> *Proposed solution:*
> I can reimplement BundleResource, so that sling:resourceType is calculated in
> the getter. This will result in a valid getResourceType() method contract
> with the possibility of having null sling:resourceType resource property.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
