[
https://issues.apache.org/jira/browse/SLING-11504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17573836#comment-17573836
]
Konrad Windszus edited comment on SLING-11504 at 8/1/22 4:15 PM:
-----------------------------------------------------------------
[~michalcukierman] For the resource merger issue please create a dedicated
issue. The merging should really be based on {{Resource.getResourceType()}} and
not on a ValueMap property with name {{sling:resourceType}}!
was (Author: kwin):
[~michalcukierman] For the resource merger issue please create a dedicated
issue. The merging should really be based on `Resource.getResourceType()` and
not on a ValueMap property with name `sling:resourceType`!
> 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)
