[ 
https://issues.apache.org/jira/browse/SLING-11504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michal Cukierman updated SLING-11504:
-------------------------------------
    Description: 
*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|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 an empty sling:resourceType resource property.

  was:
*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:[ 
getter|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:[ 
constructor|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:

!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 an empty sling:resourceType resource property.


> 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: 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|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 an empty sling:resourceType resource property.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to