[
https://issues.apache.org/jira/browse/SLING-11504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17574094#comment-17574094
]
Carsten Ziegeler commented on SLING-11504:
------------------------------------------
[~michalcukierman] As you say, the only contract we have is that
getResourceType() returns the resource type. The existence or non-existence of
a property with the name sling:resourceType might be an indication for the
resource type, but there is no guarantee.
Therefore, any code checking for this property and thinking that it contains
the resource type is wrong and needs to be fixed. For example it is completely
neglecting that the resource might be decorated and therefore returns a
completely different resource type.
If we work on that assumption, I think this fix is not needed.
Granted, such a solution requires changes across projects and is not that
easily achievable, and it might cause regressions as out of a sudden the code
is working correct but different.
As pointed out above, this is a change in behaviour, so as Konrad suggests
having a switch to opt-in sounds logical. However, that makes the whole code
more complicated than it should be.
Long story short, if that solves the issue, I'm not totally opposed to do it
this way. But, we should still look at the resourcemerger and eventually fix
that.
> 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)
