[ https://issues.apache.org/jira/browse/SLING-11504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17574203#comment-17574203 ]
Michal Cukierman commented on SLING-11504: ------------------------------------------ To wrap up: BundleResource always have sling:resourceType property which is valid from the contract/Sling API point of view, but makes it impossible to seamlessly replace JcrResources with BundleResources. We may: # Update the BundleResource and make sling:resourceType optional (by default) # Update the BundleResource and make sling:resourceType optional (configured by the manifest header config) # Update the org.apache.sling.bundleresource.impl version to 3.0.0 and start to add new features there # Create a fork of org.apache.sling.bundleresource.impl resulting in new Sling module # Create an internal fork of org.apache.sling.bundleresource.impl We plan to work on this module and possibly adding new features to it (support for .content.json files, maybe mapping of prefixes like _{_}cq{_}_dialog to be mapped to cq:dialog etc.) The question is: which option from 1-5 is acceptable for you? > 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)