[
https://issues.apache.org/jira/browse/SLING-11504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17574085#comment-17574085
]
Michal Cukierman commented on SLING-11504:
------------------------------------------
[~cziegeler]
* This change is an improvement, because it allows a user to create
BundleResource without sling:resourceType property. This is desired, because
the property should not be mandatory (Sling API does allow to have a resource
without the sling:resourceType property, so why to force to have it in a
particular implementation and limiting the possible usages).
* The possibility to have a resource without a sling:resourceType property is
desired, and is used by many APIs (till now I found three that relies on it -
ResourceMerger and AEM Component API [1], and WebSight Component API)
* Yes, I wish that BundleResource provides the same behavior like JcrResource,
but only because of the adoption of JCR Resources. FsResource or BundleResource
usage is often limited to serve a File, InputStream or to access it using
DefaultGetServlet. We started to use BundleResource as a replacement for
JcrResource, therefore I think it should be compatible with exiting API's.
Of course we can overcome the issue by always providing the explicit
sling:resourceType in every resource, but:
* It makes the platform inconvenient to use, and the code hard to maintain
* It forces the developer to know the details of the implementations of the
resource providers (we should rather work on making them consistent)
* If we agree that it's the right way to work with BundleResource, we cannot
use path based resource types like in [1]
* The resulting data/code may be inconsistent/confusing (i.e. component under
/apps/wcm/components/title, may have a sling:resourceType other than
wcm/component/title),
So it's not about fixing the exact issue, it's about working on common
abstraction for different resource implementations, and making it work with
higher level APIs.
[1]
[https://developer.adobe.com/experience-manager/reference-materials/6-4/javadoc/com/day/cq/wcm/api/components/Component.html#getResourceType--]
> 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)
